Community
Participate
Working Groups
Types which appear as values in annotation elements within binary types are surfacing as unresolved bindings, even after they have otherwise been resolved. That is, if an annotation like @Anno(IFoo.class) shows up on a type in a jar file, when APT tries to read the annotation value it gets a TypeBinding that is internally represented with an UnresolvedReferenceBinding and therefore gives wrong answers to questions like isInterface() or getQualifiedName(). The attached repro case consists of the following: 1. annoval-binary.jar contains an interface definition, an annotation definition with an element of type Class, and some base classes A and B which are annotated with the annotation. 2. anno-val.zip, which is a plug-in project that creates an annotation processor. 3. anno-val-target.zip, which is a Java project that declares a class C that extends B and that is annotated. This project needs annoval-binary.jar to be on its classpath. To reproduce the problem, import the anno-val project into a host workspace. Then debug the resulting plug-in as an Eclipse application. In the debug Eclipse instance, import the anno-val-target project and ensure that annoval-binary is on its classpath (may require editing the path). Watch the console output in the host workspace, as the target workspace is built. You will see output like this: source.C.f(): val = intf.IFoo.IBar binary.B.f(): val = intf.IFoo$IBar binary.A.f(): val = intf.IFoo$IBar Note that the output for classes B and A shows the IBar interface delimited with a '$' rather than a '.'; this is because the getQualifiedName() API returned the wrong thing, which is one sign of the unresolved reference. But note also that the value was resolved correctly for class C, which got evaluated first. If there's something that APT is doing wrong under the covers in getting these declarations, please let me know. The creation of the parser is done in BaseProcessorEnv.createASTs(), with the following code: ASTParser p = ASTParser.newParser( AST.JLS3 ); p.setResolveBindings( true ); p.setProject( javaProject ); p.setKind( ASTParser.K_COMPILATION_UNIT ); p.createASTs( parseUnits, keys, requestor, null);
Created attachment 48644 [details] jar file with binary types and anno def
Created attachment 48645 [details] processor plug-in project
Created attachment 48646 [details] debug target project
Added regression test org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0227 in HEAD. The test is disabled for now.
Maxime, Please give it a try? Kent can help you in case of problems.
Created attachment 49405 [details] Tentative patch
Released for 3.3 M2 (May have minimized the changes, but I really wanted to clarify the situation around createUnresolvedAnnotation.) Verifier please use the original test case, or else ASTConverter15Test#test0227.
Thanks! Much appreciated. I'm traveling today, won't be able to verify until this Friday but will do it then. Am I correct that this fix would also work for 3.2? We'd like to get it applied there as well, at least for 3.2.2 if it is too late for 3.2.1.
This isn't planned for 3.2.1 (too late and too risky). We can consider backporting it post 3.2.1, and posting a patch. Then maybe it makes it into 3.2.2
I'm still seeing the behavior in I20060906-1200. But maybe it didn't make it in time for that build? I'm downloading N20060908-0010 right now, will try it there.
Verified in v3.3 N20060908-0010. Thanks, Maxime! I would appreciate it if we could include this in 3.2.2, as well.
(In reply to comment #11) > Verified in v3.3 N20060908-0010. Thanks, Maxime! You're welcome. > I would appreciate it if we could include this in 3.2.2, as well. Philippe's call. I'll wait until 3.2.1 is declared anyway.
+1 for 3.2.2, BUT we may want a reduced fix for 3.2.2 (i.e. just the one change to address the bug, vs. the bigger change made for 3.3 stream). Need to interact with Kent to narrow the change to reasonable subset.
Reopening for 3.2.2
Created attachment 51753 [details] Reduced fix for the 3.2 maintenance branch, plus test cases. I believe this fix is narrowly focused on the problem at hand. Kent please let me know if you disagree.
Released for 3.2.2.
Verified for 3.2.2 using build M20070112-1200