lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: JCC CompileError -- incorrect generic parameter detection
Date Fri, 29 Jul 2011 15:09:40 GMT

  Hi Lukasz,

Thank you very much for the detailed bug report and fix.
If the gentyref library has Apache compatible licensing, I could use it for 
JCC. If the bug can be worked around without introducing this dependency, 
that would be even better.

For example, is there a piece of gentyref code that I could 'borrow' (with 
attribution of course) and include that in the JCC sources to fix this 
particular problem ?
This code could be written in Java (and wrapped by JCC for itself) or ported 
to Python if it can be expressed in terms of existing Java reflection calls.

I need to take a closer look at the bug (and reproduce it) and at the 
gentyref library before I can have a more informed opinion but if you have 
answers to these questions, that'd be helpful.

Thanks !


On Fri, 29 Jul 2011, ?ukasz Jancewicz wrote:

> I encountered an error while trying to create a JCC wrapper for Apache
> Tika. In particular, the problematic interface was
> org.apache.poi.poifs.filesystem.DirectoryEntry. It's a rather unusual,
> but simple, interface, defined as:
> public interface DirectoryEntry extends Entry, Iterable<Entry> {
>  // some method declarations, unimportant
> }
> In fact, creating a simple project with only two files:
> (defined as above) and (public
> interface Entry {}) causes JCC to fail in the following way:
> build\_failing\__wrap__.cpp(972) : error C2039: 'parameters' : is not
> a member of 'p::t_DirectoryEntry'
>        c:\temp\jcc_trunk\failtest\build\_failing\p/DirectoryEntry.h(45)
> : see declaration of 'p::t_DirectoryEntry'
> Traceback (most recent call last):
>  [...edited...]
>  File "C:\Python26\lib\distutils\", line 533, in compile
>    raise CompileError(msg)
> distutils.errors.CompileError: command '"c:\Program Files\Microsoft
> Visual Studio 9.0\VC\BIN\cl.exe"' failed with exit status 2
> This is because the C++ file generated by JCC references a
> "parameters" variable not declared in the appropriate .h file. And
> this, in turn, is caused by an incorrect result from
> getGenericReturnType() in
> def call(...):
>    returnType = method.getReturnType()
>    if generics:
>        genericRT = method.getGenericReturnType() # line 340 (rev
> 1149172): this method returns incorrect results
>        genericParams = method.getGenericParameterTypes()
>        typeParams = set()
> method.getGenericReturnType() returns java.util.Iterator<T> for
> DirectoryEntry.iterator method. It should be
> java.util.Iterator<Entry>. From the discussions on the Internet, it
> seems that it's a known issue of Java reflection. Someone created a
> small Java library to enhance its reflection algorithms, gentyref
> (, Apache License). I managed to
> substitute the incorrect line with:
>        genericRT = GenericTypeReflector.getExactReturnType(method, cls)
> GenericTypeReflector is a class from gentyref. It worked and compiled
> Tika correctly. I also modified JCC build scripts to include gentyref
> in the distribution.
> So basically my problem was solved, but there is a bug in JCC on this
> simple example. I don't know what your policy is regarding inclusion
> of third-party libraries into the project, but maybe you'll be
> interested in the patch I created?
> Best Regards,
> -- 
> ?ukasz Jancewicz

View raw message