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 !
Andi..
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:
DirectoryEntry.java (defined as above) and Entry.java (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\msvc9compiler.py", 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 python.py:
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
(http://code.google.com/p/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
