Community
Participate
Working Groups
BETA_JAVA8: From EDR draft section 2.3: @Target({ ElementType.TYPE_USE, ElementType.METHOD }) public @interface SillyAnnotation { } If @SillyAnnotation were written before a non-void method, then the annotation would apply to both the return type and the method declaration. The annotation appears twice in the AST during annotation processing, and it appears twice in the classfile. ... If you write @SillyAnnotation on a void-returning method, then it applies only to the declaration, because it is not written in a type annotation position. We need to add support for this part of the specification.
Jay, this is a corner case scenario. I would touch this only after bug 383624 is resolved.
In today's BETA_JAVA8 I'm seeing 38 regressions (9 in NullAnnotationTest times 4 compliance levels + 2 in AnnotationDependencyTests). It looks like all could be fixed for now by fixing this bug, I'll take a quick look.
May back-and-forth movement in this issue is documented in bug 392119.
Stephan, assigning this to you - this can be worked at a pace & schedule convenient to you.
Thanks for raising this bug, actually. Due to the replication you quote the following case in bug 392238 is easily classified as nonsense: void foo(@Nullable Outer. @NonNull Inner arg) The @Nullable annotation, besides being useless in this position per TYPE_USE, would - interpreted as an SE7 annotation - contradict the @NonNull annotation on the same line (see bug 392238 for more).
Jesper, Manoj raised this issued today: // -- import java.lang.annotation.*; public class X { public static void main(String[] args) { Outer outer = new Outer(); Outer.Inner inner = outer.new Inner(); @Marker3 Outer. @Marker1 Inner. @Marker2 Deeper deeper = inner.new Deeper(); } } class Outer { class Inner { class Deeper {} } } @java.lang.annotation.Target(value = {ElementType.TYPE_USE}) @interface Marker1{} @java.lang.annotation.Target(value = {ElementType.TYPE_USE}) @interface Marker2{} @java.lang.annotation.Target(value = {ElementType.TYPE_USE}) @interface Marker3{} While doing conversion, (ASTConverter: 3537) typeReference showed "Outer.@Marker1 Inner.@Marker2 Deeper". @Marker3 is missing (as a consequence of it not being in Annotations[0][] of course of typeReference). // --- If an annotation target clearly spells out that it is a type annotation and it occurs in a Java7 location, perhaps we should transfer it to the type reference. Thanks for evaluating.
As I understand this, the task is really two-fold: 1) Any annotations targeted for TYPE_USE which are now put on a declaration need to be replicated to the first segment of the type use. 2) Any annotations on the declaration NOT targeted for the type of declaration must be removed from the annotations. The trick regarding 'void' methods only applies to method declarations, right? Should this affect the bindings only, or also modify the AST?
(In reply to comment #7) > Should this affect the bindings only, or also modify the AST? Re-reading comment 0 again, I guess it really should modify the AST, too. I have a rough version which presently only works for locals, but it's shaping up fine. Hybrid annotations are going to disturb formatting, though!
If a binding-only solution is acceptable, then I believe ASTNode.copySE8AnnotationsToType() resolves this issue by now. OTOH, if we need an AST solution, than we should've solved this one before doing our binding tricks... WDYT?
(In reply to Stephan Herrmann from comment #9) > If a binding-only solution is acceptable, then I believe > ASTNode.copySE8AnnotationsToType() resolves this issue by now. > OTOH, if we need an AST solution, than we should've solved this one before > doing our binding tricks... > WDYT? I think the spec is talking about the Sun compiler tree API's which are not standard. I think what is required is in-effect achievement of this to the extent it is visible to other parties (class files, annotation processors etc)
We have an issue with JEP120, where in when the container is just target TYPE_USE and the repeating annotation is both TYPE_USE and METHOD, we emit extra containers for METHOD when we should not. This could be addressed as part of this ticket.
(In reply to Srikanth Sankaran from comment #11) > We have an issue with JEP120, where in when the container is just target > TYPE_USE > and the repeating annotation is both TYPE_USE and METHOD, we emit extra > containers > for METHOD when we should not. This could be addressed as part of this > ticket. With the resolution of https://bugs.eclipse.org/bugs/show_bug.cgi?id=419412 this may have gone away - I didn't actually verify. I think for the present bug per comment#10, we should not touch the ASTs at all. I think most of what is required should already in place. We may have just to verify and close this ticket.
Sorry for grabbing this, I am trying to wrap up loose ends before the early access announcements. Fix and tests released here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=cdd7d3ab18b0522945b5ad8d6604c424fb55fd11 Replication is ensured in class files and bindings (inasmuch as the latter is the underlying artifact for AnnotationMirror's), AST is nobody's business and left untouched.
