On Wed, Jun 29, 2011 at 2:58 PM, BobV <[email protected]> wrote:
> On Wed, Jun 29, 2011 at 8:46 AM, <[email protected]> wrote:
>> Still having stackoverflows when enabling the annotation processor in
>> Eclipse. The error I got the last time I tried had a very similar
>> stacktrace (see below).
>
> Do you have any self-parameterized types? Foo<Q extends Foo<Q>> kind
> of things going on? I'd assumed from your original report of stack
> exhaustion that it was the eager examination of types. This looks
> like a standard recursion break-condition bug.
I rebuilt the requestfactory-apt.jar with some logging in the
TransportableTypeVisitor#visitTypeVariable and it gave me the culprit:
interface BreadCrumbItemProxy<T extends Enum<T> & FieldEnum<T>>
My logging code was:
state.messager.printMessage(javax.tools.Diagnostic.Kind.NOTE,
String.format("Scanning TypeVariable %s (%s; upper bound: %s)", t,
((javax.lang.model.element.TypeParameterElement)
t.asElement()).getGenericElement(), t.getUpperBound()));
and printed tons of:
Scanning typeVariable T (xxx.xxx.BreadCrumbItemProxy; upper bound: T)
in the error log before giving up (a bit while later) with the
StackOverflowException.
The same pattern is used in a few other places in our app, and fixing
one made the other fail the build similarly.
In all cases, these are base interfaces (that are never directly used
anywhere in services or proxy properties) so I changed them slightly:
either made them no longer extend ValueProxy, pushing this down to the
subinterfaces (note that the methods making use of the 'T' type are
all overridden in subinterfaces with the specific enum type, this is
required IIRC for the deferred-binding generator), or simply removed
the generics (at least as a temporary measure).
Running 'apt' with the same patched requestfactory-apt.jar shows only a few:
Scanning typeVariable T (xxx.xxx.BreadCrumbItemProxy; upper bound:
java.lang.Enum&xxx.xxx.FieldEnum)
which would explain why it doesn't fail.
I still don't understand the stacktrace though, because the code I
read for Eclipe's TypeVariableImpl was always creating a new type, and
in this case would have (a priori) created a new DeclaredType, so
calling visit() on it should have called visitDeclared(), not
visitTypeVariable. And even though it clearly looks like a bug in
Eclipse JDT/APT (can't find anything in their bugzilla though), it
should be easy to workaround: in this case,
t.equals(t.getUpperBound()) is true.
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
