Hi Lukasz,
On Sun, 31 Jul 2011, ?ukasz Jancewicz wrote:
On Fri, Jul 29, 2011 at 17:09, Andi Vajda <va...@apache.org> wrote:
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 ?
If you look at this file:
http://code.google.com/p/gentyref/source/browse/src/main/java/com/googlecode/gentyref/GenericTypeReflector.java
you'll see that it's completely independent from the rest of gentyref
library, so I guess that, technically, you could just copy & paste it
to JCC.
Not really, no. It depends on the whole thing but that's no big deal. The
licensing is also compatible since it's Apache 2.0 licensed (like you said
originally but I missed that, sorry). So it's probably ok to use/include it.
I don't know much about Apache licensing, so I can't tell you
if it's legal/appropriate to do so. But the technical possibility
obviously exists. The advantage of including the library as a whole is
that any future Java changes (Java 7, etc.) and bugs can be
potentially taken care of by developers of gentyref.
This code could be written in Java (and wrapped by JCC for itself)
That's what I did in my patch. I included gentyref.jar in the
classpath and generated JCC wrappers for it.
So I did a custom build of JCC with that gentyref class wrapped and it does
fix the problem you encountered but it then no longer compiles Lucene :-(
I get this detailed error message from gentyref:
jcc.cpp.JavaError: com.googlecode.gentyref.UnresolvedTypeVariableException:
An exact type is requested, but the type contains a type variable that
cannot be resolved.
Variable: A from public org.apache.lucene.util.Attribute
org.apache.lucene.util.AttributeSource.addAttribute(java.lang.Class)
Hint: This is usually caused by trying to get an exact type when a
generic method who's type parameters are not given is involved.
Hacking it a bit, I catch the error and use the original reflection code
when gentyref fails to see how far I get and I get a bit further but I hit
more problems with too-specific types being resolved (like array of bool
into [B). I could probably fix this too but I'm not yet convinced that
gentyref is actually needed to solve the original problem. It feels like
gentyref, cool as it is, is actually doing too much.
Clearly, I see the bug you reported but I'm not sure where it is yet. Is it
in the java.lang.reflect code or is it in jcc itself ? For example, the same
problem happens if you just define DirectoryEntry as:
public interface DirectoryEntry extends Entry, Iterable {
}
But not when I define it thus:
import java.util.Iterator;
public interface DirectoryEntry extends Entry, Iterable {
Iterator iterator();
}
Or thus:
import java.util.Iterator;
public interface DirectoryEntry extends Entry, Iterable<Entry> {
Iterator<Entry> iterator();
}
It looks like the absence of an iterator() method definition triggers this.
Maybe all I need to do is make the iterator method code generation a bit
smarter, like not generate it if it's inherited from above anyway ?
Or see if it's inherited and its return type is overriden by the extends ?
I'm not quite sure yet what to do about this bug...
Andi..
