Community
Participate
Working Groups
BETA_JAVA8: From the spec: "If an annotation is not meta-annotated with @Target (which would be poor style!), then the compiler treats the annotation as if it is meta-annotated with all of the ElementType enum constants that appear in Java 7" This would mean that the following snippet should not compile: but it does at the moment. // ---------- @interface Marker { } public class X extends @Marker Object { }
(In reply to comment #0) > From the spec: > > "If an annotation is not meta-annotated with @Target > (which would be poor style!), then the compiler treats the > annotation as if it is meta-annotated with all of the > ElementType enum constants that appear in Java 7" What happens to the scenarios where we have enhanced the existing enum constants, for e.g, though ElementType.METHOD was present earlier, annotations on return types are support only now.
(In reply to comment #1) > What happens to the scenarios where we have enhanced the existing enum > constants, for e.g, though ElementType.METHOD was present earlier, annotations > on return types are support only now. In this code: @interface Marker {} @Marker // 1: Don't complain ? public class X<@Marker T> { // 2: Complain ? public @Marker Object foo(@Marker Object obj) { // Don't complain both ? return null; } } Should we complain only about '2' ?
(In reply to comment #1) > (In reply to comment #0) > > From the spec: > > > > "If an annotation is not meta-annotated with @Target > > (which would be poor style!), then the compiler treats the > > annotation as if it is meta-annotated with all of the > > ElementType enum constants that appear in Java 7" > > What happens to the scenarios where we have enhanced the existing enum > constants, for e.g, though ElementType.METHOD was present earlier, annotations > on return types are support only now. This is easily resolved - The compiler in the course of compiling a project works with a certain version of JRE - we go by the Target meta annotations discovered during the compilation. There is no occasion/opportunity to discover the state as it used to be some time ago. (In reply to comment #2) > (In reply to comment #1) > > What happens to the scenarios where we have enhanced the existing enum > > constants, for e.g, though ElementType.METHOD was present earlier, annotations > > on return types are support only now. > > In this code: > > @interface Marker {} > > @Marker // 1: Don't complain ? > public class X<@Marker T> { // 2: Complain ? > public @Marker Object foo(@Marker Object obj) { // Don't complain both ? > return null; > } > } > Should we complain only about '2' ? Yes, All except #2 are Java SE7 locations for writing annotations and so qualify as targets for an annotation not meta annotated with Target.
Created attachment 218325 [details] Proposed fix Patch with new negative tests added. org.NegativeTypeAnnotationTest.test036() had to be modified to make it pass with this fix. But the changes can be reverted once we can resolve TYPE_USE and TYPE_PARAMETER in our tests. But it doesn't really matter much, I guess.
The patch looks to be in the right direction, here are some comments: - TYPE_USE not, TYPE_US. - In Don't complain on both ?, remove the ? - Changes to test036 do not have to reverted, if the combined set of messages is still valid - didn't check this yet. - I think we should introduce a new problem with a distinct message for this scenario: "The annotation $0 is disallowed for this location" is not informative enough, for a programmer coming from Java SE 7 expectation that an annotation type not meta annotated with target annotation should be applicable everywhere. May be: "Only annotation types that explicitly specify TYPE_USE as a target can be applied here", likewise for TYPE_PARAMETER. In order to make the last change, look at the commit http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=c5fca7ef6c294c6139aba614099e9d98b3db43cc. There is quite a bit of boiler plate code in introducing new IProblem constants (IProblem, message.properties, ProblemReporter, CompilerInvocationTests all need to change) and the above commit could serve to show what is required.
(In reply to comment #5) > "Only annotation types that explicitly specify TYPE_USE as a target > can be applied here", likewise for TYPE_PARAMETER. What do you think about: "Only annotation types that explicitly specify TYPE_USE as a possible target element type can be applied here"
(In reply to comment #6) > "Only annotation types that explicitly specify TYPE_USE as a possible target > element type can be applied here" Do you really want to make it specific to TYPE_USE, even though that is the case today?
(In reply to comment #7) > (In reply to comment #6) > > "Only annotation types that explicitly specify TYPE_USE as a possible target > > element type can be applied here" > > Do you really want to make it specific to TYPE_USE, even though that is the > case today? I am OK with that being an argument: so the message in the properties file could be "Only annotation types that explicitly specify {0} as a possible target element type can be applied here" The substitutions could be retrieved from the properties file itself. I am also fine with there being two hard coded messages for Java SE 8 cases
(In reply to comment #5) > There is quite a bit of boiler plate code in introducing new IProblem constants > (IProblem, message.properties, ProblemReporter, CompilerInvocationTests all > need to change) and the above commit could serve to show what is required. Actually, if at all anything should change, it's only the error message. Rest of them, for e.g. IProblem#DisallowedTargetForAnnotation, seem to have been written specifically for this. In fact, the only scenario where this message gets used is this.
(In reply to comment #9) > (In reply to comment #5) > > There is quite a bit of boiler plate code in introducing new IProblem constants > > (IProblem, message.properties, ProblemReporter, CompilerInvocationTests all > > need to change) and the above commit could serve to show what is required. > > Actually, if at all anything should change, it's only the error message. Rest > of them, for e.g. IProblem#DisallowedTargetForAnnotation, seem to have been > written specifically for this. In fact, the only scenario where this message > gets used is this. Under what you propose what would be the error message for this: // --- import java.lang.annotation.*; @Target(ElementType.METHOD) @interface Annot { } @Annot class X { } We cannot print a message that reads: "Only annotation types that explicitly specify TYPE as a possible target element type can be applied here"
Created attachment 218441 [details] Updated patch This patch introduces a new problem message.
Released the fix in BETA_JAVA8 with couple of changes suggested by Srikanth: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=446232cf1f35af48915a191f1c4500b94c6d46e0
