Community
Participate
Working Groups
Build 20050509 In some situations when 2 source files are compiled at once, a @Deprecated annotation isn't resolved soon enough for it to be used appropriately. Test case: compile simultaneously // X.java public class X extends p.OldStuff { } // p/OldStuff.java package p; @Deprecated public class OldStuff { } If X gets compiled before OldStuff, then the latter only gets requested as a supertype, and didn't yet fault-in its method/field which are triggering the annotation resolution (to find out it is deprecated). See senders of SourceTypeBinding#getAnnotationTagBits(). The difficulty is that when annotations are resolved, it may refer to many other types, and should be done once reasonable state got achieved. Added AnnotationTest#test143. Other case is ReconcileTests#testSuppressWarning1 where the /** @deprecated */ is replaced with @Deprecated.
Made ReconcilerTest#testSuppressWarning1 use @Deprecated, and turned it off for now. It is exhibiting a slightly different code path than AnnotationTest#test143. Inclination would be to resolve portions of type annotations right after type hierarchy if possible... values may require field constants or methods, but the type reference shouldn't. @MyAnnotation(....) ^^^^ this portion could be resolved earlier
*** Bug 98088 has been marked as a duplicate of this bug. ***
Dani - would you vote to fix this for RC3 ?
+1
+1 for RC3
We cannot resolve the Deprecated annotation 'normally' until the imports have been faulted in, which happens in CompilationUnitScope.faultInTypes()... called from Compiler.process(). What's special about the Deprecated annotation? If it just looks like @Deprecated, then why can we not pick it up in parser? Or do a special walk over a type's annotations to see if it exists?
I can define my own @interface Deprecated which would hide the one from java.lang.
I have tried adding an extra step between imports & hierarchy resolution, but its causing a ton of errors trying to resolve fields/methods in some annotations. Unlikely we'll have a fix for this one.
Another symptom of this problem is shown by following test case: p2/I.java package p2; /** @deprecated */ interface I {} p1/X.java package p1; public class X { @Deprecated class Y implements p2.I {} } I expected not to have any warning but got one in X.java saying that p2.I is deprecated... Note that replacing @Deprecated annotation by /** @deprecated */ javadoc tag fixes the problem: p2/I.java /** @deprecated */ interface I {} p1/X.java package p1; public class X { /** deprecated */ class Y implements p2.I {} }
Original problem came from unresolved annotation at the time the check is performed. Interestingly, a change made for bug 76266 did trigger resolution of the annotations, and thus address this bug in appearance. Now, it also caused regressions such as bug 124119. Implemented instead fix for bug 124148, and ensures the introduced API is invoked in ASTNode#isTypeUseDeprecated(...). Enabled AnnotationTest#test143
*** Bug 124148 has been marked as a duplicate of this bug. ***
Frederic - pls check your scenario, and fork it into a separate bug if still reproduceable in HEAD. Fixed
*** Bug 124119 has been marked as a duplicate of this bug. ***
*** Bug 124301 has been marked as a duplicate of this bug. ***
Also re-enabled ReconcilerTest#testSuppressWarning1
Comment 9 sample is not fixed with HEAD contents => I'll open a new for this specific issue...
Open bug 124436 to address comment 9 issue...
Verified for 3.2 M5 using build I20060215-0010
