Bugzilla – Full Text Bug Listing
| Summary: | [9] org.eclipse.jdt.internal.compiler.classfmt.AnnotationInfo doesn't handle Java 9 Deprecated annotation properly | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Keith W. Campbell <keithc> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | stephan.herrmann |
| Version: | 4.8 | ||
| Target Milestone: | BETA J9 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
(In reply to Keith W. Campbell from comment #0) > The code has special handling for java.lang.Deprecated. In Java 9, that > annotation has two attributes which are not scanned, thus returning the > wrong offset for any following annotations. > > Consider this method in java.lang.SecurityManager: > @Deprecated(since="1.8", forRemoval=true) > @CallerSensitive > public void checkMemberAccess(Class<?> clazz, int which) {...} > > This is manifested in troubles indexing such a class file or compiling to > its API. Which version / variant did you test this on? The beta feature for Java 9 *should* correctly handle enhanced deprecation. Any other version cannot support (the yet unreleased) Java 9. I believe I was using oxygen with the Java 9 support patch applied, but even earlier versions (e.g. neon, mars) should handle such annotations properly and not make the assumption that Deprecated has no attributes. I misspoke: I was using base oxygen. This seems to be a duplicate of 497218. It would be helpful if this were fixed in older streams too. *** This bug has been marked as a duplicate of bug 497218 *** (In reply to Keith W. Campbell from comment #3) > I misspoke: I was using base oxygen. This seems to be a duplicate of 497218. thanks > It would be helpful if this were fixed in older streams too. @Jay, the fix in bug 497218 looks straight forward. What do you think about backporting to 4.7.1? |
The code has special handling for java.lang.Deprecated. In Java 9, that annotation has two attributes which are not scanned, thus returning the wrong offset for any following annotations. Consider this method in java.lang.SecurityManager: @Deprecated(since="1.8", forRemoval=true) @CallerSensitive public void checkMemberAccess(Class<?> clazz, int which) {...} This is manifested in troubles indexing such a class file or compiling to its API.