From ebruneton at free.fr Sat Mar 2 07:00:18 2013 From: ebruneton at free.fr (Eric Bruneton) Date: Sat, 02 Mar 2013 16:00:18 +0100 Subject: [type-annos-observers] some errors in the specification (january 30 version) Message-ID: <51321402.3050602@free.fr> >Hi Eric, > >thanks for noticing that the RI stores the >RuntimeVisibleTypeAnnotations in the Method instead of a Code >attribute. >I will discuss how to verify and fix this on the type-annotations-dev >mailing list. I downloaded the latest langtools version (langtools-a9ea02b425ff) and now the problem with Method vs Code is fixed, thanks! But I now have another issue, with annotations on throws clauses. The specification uses an unsigned short (http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#class-file:ext:ri:throws) but langtools uses an unsigned byte (as can be seen from com/sun/tools/classfile/TypeAnnotation.java). ASM uses an unsigned short, so I get errors while trying to read a class produced with langtools. Which version is correct? The specification or the reference implementation? Eric From wdietl at gmail.com Sat Mar 2 15:07:15 2013 From: wdietl at gmail.com (Werner Dietl) Date: Sat, 2 Mar 2013 15:07:15 -0800 Subject: [type-annos-observers] some errors in the specification (january 30 version) In-Reply-To: <51321402.3050602@free.fr> References: <51321402.3050602@free.fr> Message-ID: Hi Eric, > I downloaded the latest langtools version (langtools-a9ea02b425ff) and now > the problem with Method vs Code is fixed, thanks! Great, thanks for verifying! > But I now have another issue, with annotations on throws clauses. The > specification uses an unsigned short > (http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#class-file:ext:ri:throws) > but langtools uses an unsigned byte (as can be seen from > com/sun/tools/classfile/TypeAnnotation.java). ASM uses an unsigned short, so > I get errors while trying to read a class produced with langtools. > > Which version is correct? The specification or the reference implementation? Sorry about that. Usually the spec is correct. In December we had this brief discussion: http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2012-December/000056.html but I hadn't verified whether the RI implements this correctly. I've now changed throws and extends to shorts, as in the discussion in the message above. I've pushed this fix: http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/15010e417af5 Note how the ClassReader and other parts already used u2s and only the writer was inconsistent. The tl build.properties still uses 1.7 as version number: http://hg.openjdk.java.net/jdk8/tl/langtools/file/55cca2f38ee6/make/build.properties As type-annotations is a clone of that we're also 1.7. I don't know at what point this will be changed. Thanks, Remi, for helping with the build! Please do let me know if you find any other discrepancies! cu, WMD. -- http://www.google.com/profiles/wdietl From ebruneton at free.fr Sun Mar 3 01:35:41 2013 From: ebruneton at free.fr (Eric Bruneton) Date: Sun, 03 Mar 2013 10:35:41 +0100 Subject: [type-annos-observers] some errors in the specification (january 30 version) In-Reply-To: References: <51321402.3050602@free.fr> Message-ID: <5133196D.3020309@free.fr> 03/03/2013 00:07, Werner Dietl wrote: > I've now changed throws and extends to shorts, as in the discussion in > the message above. > I've pushed this fix: > > http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/15010e417af5 > > Note how the ClassReader and other parts already used u2s and only the > writer was inconsistent. Thanks for the fix. Actually my email was wrong, I wanted to say "catch clauses" instead of "throws clauses". They are also using u1 in the RI and u2 in the specification. I hadn't noticed that throws and extends clauses were wrong too! I tried to fix that myself in com.sun.tools.classfile.ClassWriter (ClassReader is also wrong), following your patch, but it took me some time to realize that in fact this code is not used when compiling classes. Instead, it is com.sun.tools.javac.jvm.ClassWriter (where extends and throws clause are correctly implemented, which is why I didn't notice the error in the other ClassWriter class). With the fix in the jvm.ClassWriter class, I can correctly read a class produced by javac with ASM, regenerate it via a null ASM transform, read it again with ASM and obtain the same output. I checked almost all kind of type annotations, except - RESOURCE_VARIABLE - CONSTRUCTOR_REFERENCE_RECEIVER - METHOD_REFERENCE_RECEIVER - CONSTRUCTOR_INVOCATION_TYPE_ARGUMENT - CONSTRUCTOR_REFERENCE_TYPE_ARGUMENT - METHOD_REFERENCE_TYPE_ARGUMENT I don't know if can generate them with langtools, if it's based on 1.7. I'm currently using the following test program: import java.util.*; public class InterningExample<@Interned T extends ArrayList<@Interned ?>> extends @Interned ArrayList implements @Interned Cloneable { @Interned String s; public void example(@Interned String @Interned [] @Interned [] f) { @Interned String foo = "foo"; @Interned String bar = "bar"; if (foo instanceof @Interned String) return; if (foo == (@Interned String) bar) System.out.println("foo == bar"); } public @Interned int m(@Interned InterningExample this, @Interned T e) { return 0; } public void n() throws @Interned Exception { InterningExample.<@Interned T>mm(0); new @Interned ArrayList<@Interned T>(); } public static <@Interned T extends ArrayList<@Interned ?>> T mm(int t) { try { return null; } catch (@Interned Exception e) { } return null; } } with import java.lang.annotation.*; @Documented @Inherited @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER}) public @interface Interned {} Eric From wdietl at gmail.com Sun Mar 3 10:57:59 2013 From: wdietl at gmail.com (Werner Dietl) Date: Sun, 3 Mar 2013 10:57:59 -0800 Subject: [type-annos-observers] some errors in the specification (january 30 version) In-Reply-To: <5133196D.3020309@free.fr> References: <51321402.3050602@free.fr> <5133196D.3020309@free.fr> Message-ID: Hi Eric, > Thanks for the fix. Actually my email was wrong, I wanted to say "catch > clauses" instead of "throws clauses". They are also using u1 in the RI and > u2 in the specification. I hadn't noticed that throws and extends clauses > were wrong too! I pushed a fix: http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/897d7844b645 > With the fix in the jvm.ClassWriter class, I can correctly read a class > produced by javac with ASM, regenerate it via a null ASM transform, read it > again with ASM and obtain the same output. I checked almost all kind of type Great! > annotations, except > - RESOURCE_VARIABLE > - CONSTRUCTOR_REFERENCE_RECEIVER > - METHOD_REFERENCE_RECEIVER > - CONSTRUCTOR_INVOCATION_TYPE_ARGUMENT > - CONSTRUCTOR_REFERENCE_TYPE_ARGUMENT > - METHOD_REFERENCE_TYPE_ARGUMENT > I don't know if can generate them with langtools, if it's based on 1.7. I'm > currently using the following test program: The type-annotations/langtools compiler is a 1.8 compiler and you can generate all these target types. type-annotations/langtools and jdk8/tl/langtools both for some reason still use 1.7 as version number. For exampes of these target types, see: test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java test/tools/javac/annotations/typeAnnotations/newlocations/ResourceVariables.java In your example I also didn't see any nested types and not very complicated generic types. You might want to look at this test for examples: test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java Thanks, cu, WMD. > import java.util.*; > > > public class InterningExample<@Interned T extends ArrayList<@Interned ?>> > extends @Interned ArrayList implements @Interned Cloneable { > > @Interned String s; > > > public void example(@Interned String @Interned [] @Interned [] f) { > @Interned String foo = "foo"; > @Interned String bar = "bar"; > if (foo instanceof @Interned String) return; > if (foo == (@Interned String) bar) > > System.out.println("foo == bar"); > } > > public @Interned int m(@Interned InterningExample this, @Interned T e) > { > return 0; > } > > public void n() throws @Interned Exception { > InterningExample.<@Interned T>mm(0); > new @Interned ArrayList<@Interned T>(); > } > > public static <@Interned T extends ArrayList<@Interned ?>> T mm(int t) { > try { > return null; > } catch (@Interned Exception e) { > } > return null; > } > } > > with > > import java.lang.annotation.*; > @Documented > @Inherited > @Retention(RetentionPolicy.RUNTIME) > @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER}) > public @interface Interned {} > > Eric -- http://www.google.com/profiles/wdietl From mernst at cs.washington.edu Thu Mar 14 15:50:56 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 14 Mar 2013 15:50:56 -0700 (PDT) Subject: [type-annos-observers] specification example: receiver in inner constructor In-Reply-To: References: Message-ID: <20130314.155056.662953361514405144.mernst@cs.washington.edu> Roman- Thanks for your query, and I'm sorry for overlooking it until now. The example is correct. Your confusion perhaps stems from the definition of "receiver". In a method, the receiver is named "this". A constructor has no receiver, unless the constructor is in an inner class. Within an inner class constructor, the receiver has a name such as "Outer.this" (and "this" refers to the result). The fact that the reference implementation fails to parse this is an error. Sorry about that, and thanks for pointing it out! I've submitted a bug report at https://code.google.com/p/jsr308-langtools/issues/detail?id=49 -Mike > Subject: specification example: receiver in inner constructor > From: "Roman Shevchenko" > To: type-annotations-spec-comments at openjdk.java.net > Date: Thu, 14 Feb 2013 14:05:55 +0100 > > Hi! > > I wonder if this example of a receiver annotation is correct: > > class Outer { > class Inner { > @Result Inner(@Receiver Outer Outer.this, boolean b) { } > } > } > > It has receiver have a type Outer instead of Inner, and a syntax > 'Outer.this' isn't understood by > 1.8.0-ea-jsr308-nightly-h2410-20121221-b69-b00 compiler. > > (I'm referring to the spec from January 30, 2013 at > http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html) > > Thanks. From mernst at cs.washington.edu Thu Mar 14 16:10:15 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 14 Mar 2013 16:10:15 -0700 (PDT) Subject: [type-annos-observers] Missing location of Runtime[In]VisibleTypeAnnotations attribute In-Reply-To: <512BAFD8.3030105@oracle.com> References: <512BAFD8.3030105@oracle.com> Message-ID: <20130314.161015.1546412796637324901.mernst@cs.washington.edu> FYI, this is fixed. Thanks, Alex, for pointing it out. -Mike > Subject: Missing location of Runtime[In]VisibleTypeAnnotations attribute > From: Alex Buckley > To: type-annotations-spec-experts > Date: Mon, 25 Feb 2013 10:39:20 -0800 > > Section 3 of the spec says: "A type annotation is stored in a > Runtime[In]visibleTypeAnnotations attribute on the smallest enclosing > class, field, method, or Code structure." > > Subsections then give the exact storage location for most, but not all, of > the possible type annotations. The location is missing in 3.3.9 "Type > tests, object creation, and method/constructor references" - an omission > which partly led to dropped annotations in the RI [1]. Also, 3.3.10 gives a > location but is inconsistent about the name of the structure being stored. > > Alex > > [1] > http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-February/000629.html From mernst at cs.washington.edu Fri Mar 15 10:16:33 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Fri, 15 Mar 2013 10:16:33 -0700 (PDT) Subject: [type-annos-observers] New version of Type Annotations (JSR 308) specification Message-ID: <20130315.101633.1703056249256479109.mernst@cs.washington.edu> I've made a new version of the Type Annotations (JSR 308) specification, at http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html http://types.cs.washington.edu/jsr308/specification/java-annotation-design.pdf This version cleans up a few small issues: Classfile changes: * Type annotations on the body of an initializer appear with the initializer code, not with the field being initialized. * Change method_reference_receiver to method_reference, and change constructor_reference_receiver to constructor_reference. * Change invocation_type_argument_target and method_reference_type_argument to type_argument_target. Clarifications: * Clarify the meaning of the receiver of an inner class constructor. A few other small issues remain to be clarified, but I am not aware of any significant errors that remain. -Mike From joe.darcy at oracle.com Mon Mar 18 22:21:34 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 18 Mar 2013 22:21:34 -0700 Subject: [type-annos-observers] Comments and questions on JSR 308 draft from January 23, 2013 Message-ID: <5147F5DE.6010006@oracle.com> Dear type annotations experts, I've read through the January 23, 2013 JSR 308 specification [1], which is the most recent one I'm aware of. I have comments and questions about the draft. Some of these issues may have already been discussed on JSR 308 mailing lists, but perhaps adding some more notes on design rationale might help answer similar questions for future readers of the document. Section 1 "[JSR 308] does not change the abilities of Java annotation processors as defined in JSR 269 [Dar06]." The phrasing "does not directly change..." would be more accurate since the JSR 269 API is being extended to support type annotations. Section 2.1 Annotation syntax the syntax to annotate a fully-qualitied type use is "java.lang. at NonNull String" rather than "@NonNull java.lang.String" I understand this point has been considered by the EG previously, but I find it surprising and would be interested in seeing the rationale disclosed in the specification document. "(Note that the result of a constructor is different from the receiver. The receiver only exists for inner class constructors, as in theReceiver.new InnerClass(). The receiver is the containing object, and in the body of the constructor it is referred to as Supertype.this. In the constructor body, the result is referred to as this. In any non-constructor, the receiver (if any) is referred to as this.)" I don't have a better terminology suggestion offhand, but I'm uncomfortable with using the term "receiver" to describe the outer this object. At a VM level, a constructor is an odd sort of static method and does not have a receiver; indeed, in the implementation the outer this is passed as an argument to the constructor. No method is dispatched off of the outer this. This fact also filters through to core reflection; when invoking "new InnerClass()" reflectively, the "theReceiver" object is passed as a parameter, not the other way around. "It is permitted to explicitly declare the method receiver as the first formal parameter. (Each non-static method has an implicit formal parameter, this, which is called the receiver.) Then, no special syntax is needed for expressing a receiver type annotation: it is simply an annotation on the type of the this formal parameter." "The optional receiver parameter has no effect on execution ? it only serves as a place to write annotations on the receiver. The compiler generates the same bytecodes, and reflection returns the same results regarding number of method formal parameters, whether or not the optional receiver parameter is present." In Java SE 8, we are also adding support for more reflective information about method and constructor parameters, including modifiers as to whether or not they are "synthetic" vs "mandated". The explicit "receiver" parameter declarations may alter how the corresponding java.lang.reflect.Parameter objects should behave in some situations. In any case, the specification should be updated to be explicit about any interaction or non-interaction here. It was not clear to me from reading the specification whether or not "C style" mixed array declarations were able to be annotated. If the answer is "no", that is fine by me. Section 3 "The VM does not have to validate all the constraints in Section 3.3, such as that offsets point to the right type of instruction. The VM does not do format checking (JVMS 4.8) on attributes used solely for reflection." The JVMS has a rich terminology in terms of what checks happen (or not) where and when in the linking and loading process. This description above should be tied more directly to the JVMS concepts. "For backward compatibility, JSR 308 uses new attributes for storing the type annotations. In other words, JSR 308 merely reserves the names of a few new attributes and specifies their layout. JVMs ignore unknown attributes." "JVMs ignore unknown attributes" is a true statement, but one not directly relevant to this document since JSR 308 is adding the attributes to the set of known attributes. If the new attributes appear in a 51.0 or earlier class file, they should be ignored. Section 3.2 Declaration annotations on type parameters are stored in the *TypeAnnotations attributes as opposed to the pre-existing *Annotations attributes used to store the annotations on all other declarations. This is at least initially surprising and I think a discussion of this point is warranted. Section 3.3 Figure 1 lists the target_type values for different locations. There seem to be inconsistencies in how method vs constructors are distinguished or not. Within code blocks, there are different target_types for methods vs constructors. In contrast, the METHOD TYPE PARAMETER value presumably covers both methods parameters as well as constructor parameters. (Note to future maintainers of the platform: one of the new to-do items for evolving the language may be to add new target_type values [2].) "The symbolic constants appear in the enums com.sun.tools.javac.code.TargetType and com.sun.tools.classfile.TypeAnnotation.TargetType." The implementation note above seems off-topic for this document. Stepping back a bit, while this JSR is adding "Annotations on Java Types" and is thus focused on the Java programming language, are any additional facilities / escape hatches needed to allow annotations in source language other than Java? The class / method / field / constructor representations should stable across most language targeting the JVM. Section 3.3.10 "If the compiler eliminates an annotated cast, it is required to retain the annotations on the cast in the class file. " Presumably only if the corresponding annotation types have at least CLASS retention. Section A "No modifications to the virtual machine are necessary." ... other than the changes to the class file format discussed in section ... Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-January/000053.html [2] "So you want to change the Java Programming Language...", https://blogs.oracle.com/darcy/entry/so_you_want_to_change From mernst at cs.washington.edu Tue Mar 19 07:15:50 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 19 Mar 2013 07:15:50 -0700 (PDT) Subject: [type-annos-observers] Comments and questions on JSR 308 draft from January 23, 2013 In-Reply-To: <5147F5DE.6010006@oracle.com> References: <5147F5DE.6010006@oracle.com> Message-ID: <20130319.071550.1424135489576243772.mernst@cs.washington.edu> Joe- Thanks for your comments. It's great to iron out these remaining issues, so your feedback is valuable. We'll address these to clarify and correct the specification. > I've read through the January 23, 2013 JSR 308 specification [1], which is > the most recent one I'm aware of. > [1] > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-January/000053.html By the way, a newer version was announced to that same mailing list on March 15, three days ago: http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-March/000073.html But, most of your comments remain relevant. -Mike From srikanth_sankaran at in.ibm.com Wed Mar 20 11:28:27 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Wed, 20 Mar 2013 14:28:27 -0400 Subject: [type-annos-observers] Constraining type annotations to occur just before type In-Reply-To: References: <50516CF6.6050400@free.fr> <20120921.031537.857440125198746700.mernst@cs.washington.edu> Message-ID: Dear EG, We have a request from the Eclipse JDT team that JSR308 should constrain/require the position of TYPE_USE annotations in declaration modifiers, so that all TYPE_USE annotations must be placed at the end of the modifiers list. (Or in other words, where a type annotation features in a place a declaration annotation aka a SE7 annotation can also feature, the language should mandate that they be placed immediately preceding the type which they are annotating. Example: package jsr308.bug; import java.lang.annotation.ElementType; import java.lang.annotation.Target; @Target(ElementType.TYPE_USE) @interface NonNull { } public class Bug { @Deprecated @NonNull String s = new @NonNull String(); @NonNull @Deprecated String s2 = new @NonNull String(); // disallow } The rationale being: A declaration like "@NonNull @Deprecated String" is hard to understand for Java programmers. It doesn't make sense to allow the TYPE_USE annotation to occur anywhere in the modifiers list. Unlike e.g. an ElementType.FIELD annotation, a TYPE_USE annotation is not a general modifier of the declaration. A TYPE_USE annotation always belongs to the following type, so it should also be right in front of the type in the source. The main concern is that from a language point of view, it doesn't make sense to tear apart the TYPE_USE annotation and the type proper. This was possible with annotations that abused other ElementTypes to implement a restricted form of TYPE_USE annotations. But that doesn't mean it needs to stay this way. Thanks for considering this, Srikanth. From alex.buckley at oracle.com Wed Mar 20 11:53:32 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 20 Mar 2013 11:53:32 -0700 Subject: [type-annos-observers] Constraining type annotations to occur just before type In-Reply-To: References: <50516CF6.6050400@free.fr> <20120921.031537.857440125198746700.mernst@cs.washington.edu> Message-ID: <514A05AC.3080909@oracle.com> To be precise, the possibility of mixed TYPE_USE and non-TYPE_USE annotations occurs only where a production has been changed to use UnannType (or UnannReferenceType) because the production is preceded by a Modifier list (or VariableModifier list). Productions which continue to use Type (or ReferenceType) obviously allow only TYPE_USE annotations in the new [Annotations] non-terminal of Type. I agree that a TYPE_USE annotation is not a general modifier of a declaration. Semantically, it belongs with the type. The question is, should placing it among the declaration modifiers be considered a semantic error? I think the answer is no, because nothing bad happens at run time if you order modifiers unconventionally: final @NonNull static private String s; A bigger problem as I see it is the longstanding JLS advice to write annotations as the first modifiers, before 'public', 'static', etc. This advice is definitely out of step with type annotations, because placing a TYPE_USE annotation at the front is obtuse: @NonNull private static final String s; The advice (not the Modifier production) should change to give an exception for TYPE_USE annotations, recommending they be placed last: private final @NonNull String s; I think this solves the problem of mixing TYPE_USE and non-TYPE_USE annotations, because the advice would imply: @Deprecated private final @NonNull String s; Mike, Doug, any comments? Alex On 3/20/2013 11:28 AM, Srikanth S Adayapalam wrote: > Dear EG, > > We have a request from the Eclipse JDT team that JSR308 should > constrain/require the position of TYPE_USE annotations in declaration > modifiers, so that all TYPE_USE annotations must be placed at the end > of the modifiers list. (Or in other words, where a type annotation features > in a place a declaration annotation aka a SE7 annotation can also feature, > the language should mandate that they be placed immediately preceding > the type which they are annotating. > > Example: > > package jsr308.bug; > > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > > @Target(ElementType.TYPE_USE) > @interface NonNull { } > > public class Bug { > @Deprecated @NonNull String s = new @NonNull String(); > @NonNull @Deprecated String s2 = new @NonNull String(); // > disallow > } > > The rationale being: > > A declaration like "@NonNull @Deprecated String" is hard to understand for > Java programmers. It doesn't make sense to allow the TYPE_USE annotation > to occur anywhere in the modifiers list. Unlike e.g. an ElementType.FIELD > annotation, a TYPE_USE annotation is not a general modifier of the > declaration. > A TYPE_USE annotation always belongs to the following type, so it should > also > be right in front of the type in the source. > > The main concern is that from a language point of view, it doesn't make > sense to tear apart the TYPE_USE annotation and the type proper. This > was possible with annotations that abused other ElementTypes to > implement a restricted form of TYPE_USE annotations. But that doesn't > mean it needs to stay this way. > > Thanks for considering this, > Srikanth. > From alex.buckley at oracle.com Wed Mar 20 15:35:04 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 20 Mar 2013 15:35:04 -0700 Subject: [type-annos-observers] Spec refresh at JCP site ? In-Reply-To: <512275D1.8000103@oracle.com> References: <50516CF6.6050400@free.fr> <20120921.031537.857440125198746700.mernst@cs.washington.edu> <512275D1.8000103@oracle.com> Message-ID: <514A3998.5020409@oracle.com> To ensure that a current specification is available under a JCP evaluation license, I have initiated an Early Draft Review using the March 15 specification. It lasts for 30 days from March 20. Please see: http://jcp.org/en/jsr/detail?id=308 Alex On 2/18/2013 10:41 AM, Alex Buckley wrote: > Mike and I were not planning another Early Draft Review. We were > planning for the next milestone to be a Public Review aligned with the > Public Reviews of other SE 8 JSRs. I have no information of any kind > about when those Public Reviews would happen. > > Alex > > On 2/18/2013 4:59 AM, Srikanth S Adayapalam wrote: >> Hello ! >> >> Is it known when we can expect the next refresh at the JCP site. I know >> very recent versions are available at the University site, but the >> question >> is specifically about JCP site. >> >> TIA, >> Srikanth >> From mernst at cs.washington.edu Thu Mar 21 10:21:50 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 21 Mar 2013 10:21:50 -0700 (PDT) Subject: [type-annos-observers] Constraining type annotations to occur just before type In-Reply-To: <514A05AC.3080909@oracle.com> References: <514A05AC.3080909@oracle.com> Message-ID: <20130321.102150.1919962541793975235.mernst@cs.washington.edu> Alex and Srikanth- I agree entirely that it is terrible style to mix type annotations and declaration annotations (the declaration annotations should always come first) and that it is terrible style to mix type annotations with modifiers (the modifiers should come first). So, Alex's suggestion to change the advice is definitely good. Alex, can you make that change? It's outside the scope of the JSR 308 specification. I consider it an infelicity in the Java grammar that (declaration) annotations are considered modifiers and are lumped in with them, and even worse that type annotations get lumped in with declaration annotations. Logically, there are types and modifiers, and a type consists of optional type annotations followed by a Java type. This is how people should write them. Now, the question is whether or not the Java language should strictly enforce this practice. I'm sympathetic to this change -- probably my position is between Srikanth's and Alex's. I see the benefit of preventing confusing code rather than just advising programmers not to write it in the first place and then giving them rope to hang themselves. But, here are a few downsides: * More grammatical ambiguity and more parsing complexity. * Any change so late in the game carries risks and extra work. The work includes grammar changes and compiler changes. * Source code incompatibility with pre-Java-8 hacks that use declaration annotations to stand for type annotations. Are there other downsides I am missing? Incidentally, the Annotation File Utilities (AFU) grammar has these productions: decl-annotation ::= # annotation must be a declaration annotation. annotation type-annotation ::= # annotation must be a type annotation. annotation annotation ::= # The name may be the annotation?s simple name, unless the file # contains definitions for two annotations with the same simple name. # In this case, the fully-qualified name of the annotation name is required. "@"name [ "(" annotation-field [ "," annotation-field ]+ ")" ] Elsewhere, the AFU grammar always uses the decl-annotation or type-annotation non-terminal, rather than just using the "annotation" non-terminal. The AFU grammar would accept exactly the same annotation files if it did not contain the decl-annotation and type-annotation non-terminals, but those clarify the meaning. We could imagine doing a similar thing with the JLS grammar, though the required changes would be more extensive. Modifiers would include declaration annotations but not type annotations, which would be rolled into types. I suspect that the reason I didn't do this in the first place was because I was trying to make the changes to the JLS grammar as minimal as possible to clarify what was actually changing. We've since moved away from that position (and even if we hadn't, what's good for a diff isn't necessarily good for a final version). -Mike > Subject: Re: Constraining type annotations to occur just before type > From: Alex Buckley > To: type-annotations-spec-experts at openjdk.java.net > Date: Wed, 20 Mar 2013 11:53:32 -0700 > > To be precise, the possibility of mixed TYPE_USE and non-TYPE_USE > annotations occurs only where a production has been changed to use > UnannType (or UnannReferenceType) because the production is preceded by a > Modifier list (or VariableModifier list). > > Productions which continue to use Type (or ReferenceType) obviously allow > only TYPE_USE annotations in the new [Annotations] non-terminal of Type. > > I agree that a TYPE_USE annotation is not a general modifier of a > declaration. Semantically, it belongs with the type. The question is, > should placing it among the declaration modifiers be considered a semantic > error? I think the answer is no, because nothing bad happens at run time if > you order modifiers unconventionally: > > final @NonNull static private String s; > > A bigger problem as I see it is the longstanding JLS advice to write > annotations as the first modifiers, before 'public', 'static', etc. This > advice is definitely out of step with type annotations, because placing a > TYPE_USE annotation at the front is obtuse: > > @NonNull private static final String s; > > The advice (not the Modifier production) should change to give an exception > for TYPE_USE annotations, recommending they be placed last: > > private final @NonNull String s; > > I think this solves the problem of mixing TYPE_USE and non-TYPE_USE > annotations, because the advice would imply: > > @Deprecated private final @NonNull String s; > > Mike, Doug, any comments? > > Alex > > On 3/20/2013 11:28 AM, Srikanth S Adayapalam wrote: > > Dear EG, > > > > We have a request from the Eclipse JDT team that JSR308 should > > constrain/require the position of TYPE_USE annotations in declaration > > modifiers, so that all TYPE_USE annotations must be placed at the end > > of the modifiers list. (Or in other words, where a type annotation features > > in a place a declaration annotation aka a SE7 annotation can also feature, > > the language should mandate that they be placed immediately preceding > > the type which they are annotating. > > > > Example: > > > > package jsr308.bug; > > > > import java.lang.annotation.ElementType; > > import java.lang.annotation.Target; > > > > @Target(ElementType.TYPE_USE) > > @interface NonNull { } > > > > public class Bug { > > @Deprecated @NonNull String s = new @NonNull String(); > > @NonNull @Deprecated String s2 = new @NonNull String(); // > > disallow > > } > > > > The rationale being: > > > > A declaration like "@NonNull @Deprecated String" is hard to understand for > > Java programmers. It doesn't make sense to allow the TYPE_USE annotation > > to occur anywhere in the modifiers list. Unlike e.g. an ElementType.FIELD > > annotation, a TYPE_USE annotation is not a general modifier of the > > declaration. > > A TYPE_USE annotation always belongs to the following type, so it should > > also > > be right in front of the type in the source. > > > > The main concern is that from a language point of view, it doesn't make > > sense to tear apart the TYPE_USE annotation and the type proper. This > > was possible with annotations that abused other ElementTypes to > > implement a restricted form of TYPE_USE annotations. But that doesn't > > mean it needs to stay this way. > > > > Thanks for considering this, > > Srikanth. > From jonathan.gibbons at oracle.com Thu Mar 21 10:28:29 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 21 Mar 2013 10:28:29 -0700 Subject: [type-annos-observers] Constraining type annotations to occur just before type In-Reply-To: <20130321.102150.1919962541793975235.mernst@cs.washington.edu> References: <514A05AC.3080909@oracle.com> <20130321.102150.1919962541793975235.mernst@cs.washington.edu> Message-ID: <514B433D.20309@oracle.com> On 03/21/2013 10:21 AM, Michael Ernst wrote: > But, here are a few downsides: > * More grammatical ambiguity and more parsing complexity. > * Any change so late in the game carries risks and extra work. The work > includes grammar changes and compiler changes. > * Source code incompatibility with pre-Java-8 hacks that use > declaration annotations to stand for type annotations. > Are there other downsides I am missing? You don't have to fix this in the parser -- and indeed, you can't, because at parse time you cannot differentiate between declaration annotations and type annotations. This just means you have to be tolerant in the parser and apply the checks later on. One option would be to use -Xlint or similar techniques to encourage good style, without mandating it. -- Jon From alex.buckley at oracle.com Thu Mar 21 12:51:31 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 21 Mar 2013 12:51:31 -0700 Subject: [type-annos-observers] Constraining type annotations to occur just before type In-Reply-To: <20130321.102150.1919962541793975235.mernst@cs.washington.edu> References: <514A05AC.3080909@oracle.com> <20130321.102150.1919962541793975235.mernst@cs.washington.edu> Message-ID: <514B64C3.6040306@oracle.com> On 3/21/2013 10:21 AM, Michael Ernst wrote: > I agree entirely that it is terrible style to mix type annotations and > declaration annotations (the declaration annotations should always come > first) and that it is terrible style to mix type annotations with modifiers > (the modifiers should come first). So, Alex's suggestion to change the > advice is definitely good. Alex, can you make that change? It's outside > the scope of the JSR 308 specification. Since type annotations are the reason to change the advice about modifier order, the 308 spec should have a note giving the preferred layout of declaration annotations v. type annotations. I will then incorporate it into JLS sections which use modifiers. > I consider it an infelicity in the Java grammar that (declaration) > annotations are considered modifiers and are lumped in with them, and even > worse that type annotations get lumped in with declaration annotations. > Logically, there are types and modifiers, and a type consists of optional > type annotations followed by a Java type. This is how people should write > them. Carefully distinguishing declaration annotations from type annotations would be the heart of the new note :-) > Now, the question is whether or not the Java language should strictly > enforce this practice. > > I'm sympathetic to this change -- probably my position is between > Srikanth's and Alex's. I see the benefit of preventing confusing code > rather than just advising programmers not to write it in the first place > and then giving them rope to hang themselves. I understand, but there are infinite ways to writing confusing code in Java, and none of them get their own compile-time error. Even potentially unsafe use of raw types - which can lead to unpredictable program termination! - only gets a compile-time warning. I think people are over-rotating towards the IDE context, where informative messages and warnings abound, rather than focusing on hard-edged rules of the language. > Incidentally, the Annotation File Utilities (AFU) grammar has these > productions: ... > Elsewhere, the AFU grammar always uses the decl-annotation or > type-annotation non-terminal, rather than just using the "annotation" > non-terminal. The AFU grammar would accept exactly the same annotation > files if it did not contain the decl-annotation and type-annotation > non-terminals, but those clarify the meaning. > > We could imagine doing a similar thing with the JLS grammar, though the > required changes would be more extensive. Modifiers would include > declaration annotations but not type annotations, which would be rolled > into types. I suspect that the reason I didn't do this in the first place > was because I was trying to make the changes to the JLS grammar as minimal > as possible to clarify what was actually changing. We've since moved away > from that position (and even if we hadn't, what's good for a diff isn't > necessarily good for a final version). As Jon implied in [1], the grammar would have to be relaxed (use only the Annotation non-terminal) because parsers cannot in general do the semantic analysis required to distinguish decl. from type annotations. It would have to be a higher-level complaint - either a standard compile-time error or a compiler-specific lint warning - if a decl. annotation is used where a type annotation is required, and vice-versa. However, we cannot say that decl. annotations must come before traditional modifiers (private/public/static/final etc) because it has been legal since Java SE 5.0 to mix them up. The only rule which could possibly be added is "type annotations are not modifiers, and occur after all modifiers (which include declaration annotations)". I personally remain to be convinced that this rule is necessary. Alex [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-March/000103.html From ebruneton at free.fr Sat Mar 23 07:09:41 2013 From: ebruneton at free.fr (Eric Bruneton) Date: Sat, 23 Mar 2013 15:09:41 +0100 Subject: [type-annos-observers] New version of Type Annotations (JSR 308) specification In-Reply-To: <20130315.101633.1703056249256479109.mernst@cs.washington.edu> References: <20130315.101633.1703056249256479109.mernst@cs.washington.edu> Message-ID: <514DB7A5.7080506@free.fr> 15/03/2013 18:16, Michael Ernst wrote: > I've made a new version of the Type Annotations (JSR 308) specification, at > > http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html > http://types.cs.washington.edu/jsr308/specification/java-annotation-design.pdf > > This version cleans up a few small issues: > > Classfile changes: > * Type annotations on the body of an initializer appear with the initializer code, not with the field being initialized. > * Change method_reference_receiver to method_reference, and change constructor_reference_receiver to constructor_reference. > * Change invocation_type_argument_target and method_reference_type_argument to type_argument_target. Thanks for the update; FYI, I updated ASM accordingly. > Clarifications: > * Clarify the meaning of the receiver of an inner class constructor. > > A few other small issues remain to be clarified, but I am not aware of any > significant errors that remain. > > -Mike > From mernst at cs.washington.edu Thu Mar 28 21:22:41 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 28 Mar 2013 21:22:41 -0700 (PDT) Subject: [type-annos-observers] Comments and questions on JSR 308 draft from January 23, 2013 In-Reply-To: <5147F5DE.6010006@oracle.com> References: <5147F5DE.6010006@oracle.com> Message-ID: <20130328.212241.1714870381793237549.mernst@cs.washington.edu> Joe- Thanks for your comments on the JSR 308 specification; they're very useful. I have addressed most of them in the specification, and I won't respond to those by email. But I'll follow up on a few others. This first message is a request for more information on two points. > "It is permitted to explicitly declare the method receiver as the first > formal parameter. (Each non-static method > has an implicit formal parameter, this, which is called the receiver.) > Then, no special syntax is needed for > expressing a receiver type annotation: it is simply an annotation on the > type of the this formal parameter." > > "The optional receiver parameter has no effect on execution ? it only > serves as a place to write annotations > on the receiver. The compiler generates the same bytecodes, and reflection > returns the same results regarding > number of method formal parameters, whether or not the optional receiver > parameter is present." > > In Java SE 8, we are also adding support for more reflective information > about method and constructor parameters, including modifiers as to whether > or not they are "synthetic" vs "mandated". The explicit "receiver" > parameter declarations may alter how the corresponding > java.lang.reflect.Parameter objects should behave in some situations. In > any case, the specification should be updated to be explicit about any > interaction or non-interaction here. Can you point me at the specification? (I don't see a reference to this in lambda, so it must be separate.) Also, I suspect you may have an opinion about the interaction or non-interaction. If you can share that, it would be very helpful. > Section 3 > > "The VM does not have to validate all the constraints in Section 3.3, such > as that offsets point to the right type of > instruction. The VM does not do format checking (JVMS 4.8) on attributes > used solely for reflection." > > The JVMS has a rich terminology in terms of what checks happen (or not) > where and when in the linking and loading process. This description above > should be tied more directly to the JVMS concepts. Can you give specific, constructive suggestions for the terminology? You can probably do that quickly and easily. Thanks! Thanks in advance for the info about these two points. -Mike From mernst at cs.washington.edu Thu Mar 28 21:29:55 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 28 Mar 2013 21:29:55 -0700 (PDT) Subject: [type-annos-observers] Comments and questions on JSR 308 draft from January 23, 2013 In-Reply-To: <5147F5DE.6010006@oracle.com> References: <5147F5DE.6010006@oracle.com> Message-ID: <20130328.212955.1561485238142075094.mernst@cs.washington.edu> Joe- > It was not clear to me from reading the specification whether or not "C > style" mixed array declarations were able to be annotated. If the answer is > "no", that is fine by me. "C style" mixed array declarations are permitted because the grammar uses FormalParameterDecls, which permits them. Whereas I'm addressing your other comments by editing the document, this one doesn't seem worth discussing explicitly in the spec. But if I am missing something, please let me know. -Mike From joe.darcy at oracle.com Thu Mar 28 22:39:43 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 28 Mar 2013 22:39:43 -0700 Subject: [type-annos-observers] FYI, JSR 308 and the annotation processing discovery process Message-ID: <5155291F.2050907@oracle.com> Hello, FYI, as the JSR 269 maintenance lead, besides updating the javax.lang.model.* API to handle new-in-Java-SE-8 features, I'm not looking at updating the javax.annotation.processing API to deal with those new annotation-related features too. To provide some context, here is an excerpt from the javax.annotation.processing.Processor interfaces which describes part of the tool <-> processor protocol: "The tool uses a discovery process to find annotation processors and decide whether or not they should be run. [...] Which processors the tool asks to run is a function of what annotations are present on the root elements, what annotation types a processor processes, and whether or not a processor claims the annotations it processes. [...] For a given round, the tool computes the set of annotation types on the root elements. If there is at least one annotation type present, as processors claim annotation types, they are removed from the set of unmatched annotations." To this, I plan to add a paragraph explaining how type annotations do not interact with the this discovery process; something like: "

An annotation type is considered present if there is at least one annotation of that type on a declaration enclosed within the root elements of a round. For this purpose, a type parameter is considered to be enclosed by its generic element. Annotations on type uses are not considered as part of the computation. An annotation is present on a declaration if it is present as defined in {@link AnnotatedConstruct}. That is, the annotation may be directly present or present via inheritance. An annotation indirectly present by virtue of a repeatable annotation type is not considered represent for the purposes of the discovery process. [..]" For the purposes of JSR 308: * Declaration annotations on type parameters are included in discovery * TYPE_USE annotations are *not* included as part of discovery Comments? Thanks, -Joe From jonathan.gibbons at oracle.com Fri Mar 29 12:03:37 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 29 Mar 2013 12:03:37 -0700 Subject: [type-annos-observers] FYI, JSR 308 and the annotation processing discovery process In-Reply-To: <5155291F.2050907@oracle.com> References: <5155291F.2050907@oracle.com> Message-ID: <5155E589.8050200@oracle.com> On 03/28/2013 10:39 PM, Joe Darcy wrote: > I'm not looking at updating the javax.annotation.processing API typo? now? :-) -- Jon From alex.buckley at oracle.com Fri Mar 29 14:47:58 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 29 Mar 2013 14:47:58 -0700 Subject: [type-annos-observers] Comments and questions on JSR 308 draft from January 23, 2013 In-Reply-To: <20130328.212241.1714870381793237549.mernst@cs.washington.edu> References: <5147F5DE.6010006@oracle.com> <20130328.212241.1714870381793237549.mernst@cs.washington.edu> Message-ID: <51560C0E.5090104@oracle.com> Moving things along while Joe is away... On 3/28/2013 9:22 PM, Michael Ernst wrote: >> "The optional receiver parameter has no effect on execution ? it only >> serves as a place to write annotations >> on the receiver. The compiler generates the same bytecodes, and reflection >> returns the same results regarding >> number of method formal parameters, whether or not the optional receiver >> parameter is present." >> >> In Java SE 8, we are also adding support for more reflective information >> about method and constructor parameters, including modifiers as to whether >> or not they are "synthetic" vs "mandated". The explicit "receiver" >> parameter declarations may alter how the corresponding >> java.lang.reflect.Parameter objects should behave in some situations. In >> any case, the specification should be updated to be explicit about any >> interaction or non-interaction here. > > Can you point me at the specification? (I don't see a reference to this in > lambda, so it must be separate.) An explicit receiver parameter isn't persisted as a formal parameter. That's why JSR 308 prohibits a PARAMETER annotation from being applied to it. It essentially disappears during compilation. The only trace is that its TYPE_USE annotations persist in a *TypeAnnotations attribute in method_info. Core reflection (j.l.r.Parameter) therefore knows nothing about it. Mike, please see section 2 of the PDF spec linked from http://mail.openjdk.java.net/mailman/listinfo/enhanced-metadata-spec-discuss, particularly the new JLS 13.1 section. An explicit receiver parameter is definitely declared explicitly in source code, so there is no need to mark it. (You might ask, how would it be marked? For that, see the new JVMS 4.7.22 section, and note carefully how ACC_SYNTHETIC and ACC_MANDATED bind to JLS 13.1.) >> Section 3 >> >> "The VM does not have to validate all the constraints in Section 3.3, such >> as that offsets point to the right type of >> instruction. The VM does not do format checking (JVMS 4.8) on attributes >> used solely for reflection." >> >> The JVMS has a rich terminology in terms of what checks happen (or not) >> where and when in the linking and loading process. This description above >> should be tied more directly to the JVMS concepts. > > Can you give specific, constructive suggestions for the terminology? You > can probably do that quickly and easily. Thanks! For this and other text which says "nothing changes" (e.g. "No changes are made to the StackMapTable ...") it is best just to take the text out. I plan in JVMS8 to call out attributes which are read solely by the core reflection API (it's a growing list), since they need to be excepted from format checking, but there is nothing surprising about the *TypeAnnotations attribute so the less said, the better. Alex From alex.buckley at oracle.com Fri Mar 29 15:10:41 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 29 Mar 2013 15:10:41 -0700 Subject: [type-annos-observers] FYI, JSR 308 and the annotation processing discovery process In-Reply-To: <5155291F.2050907@oracle.com> References: <5155291F.2050907@oracle.com> Message-ID: <51561161.8030207@oracle.com> On 3/28/2013 10:39 PM, Joe Darcy wrote: > FYI, as the JSR 269 maintenance lead, besides updating the > javax.lang.model.* API to handle new-in-Java-SE-8 features, I'm not > looking at updating the javax.annotation.processing API to deal with > those new annotation-related features too. "not looking"? Surely "now looking". > "The tool uses a discovery process to find annotation processors and > decide whether or not they should be run. [...] Which processors the > tool asks to run is a function of what annotations are present on the > root elements, what annotation types a processor processes, and whether > or not a processor claims the annotations it processes. [...] For a > given round, the tool computes the set of annotation types on the root > elements. If there is at least one annotation type present, as > processors claim annotation types, they are removed from the set of > unmatched annotations." Close reading of the above paragraph reveals that: - a processor _claims_ annotation types - a processor _claims_ annotations - a processor _processes_ annotations - from a set of annotations, it is possible to remove annotation _types_ I contend there is at least one kind error going on here. > To this, I plan to add a paragraph explaining how type annotations do > not interact with the this discovery process; something like: > > "

An annotation type is considered present if there is at least one > annotation of that type on a declaration enclosed within the root > elements of a round. For this purpose, a type parameter is considered > to be enclosed by its generic element. Annotations on type uses are > not considered as part of the computation. There is quite a phase shift between the "For this purpose" sentence and the type uses sentence. I think a new paragraph is warranted: "Annotations on type uses are ignored when computing the set of annotation types present on the root elements." > For the purposes of JSR 308: > > * Declaration annotations on type parameters are included in discovery > * TYPE_USE annotations are *not* included as part of discovery You mean to put "For the purposes of JSR 308" into the SE 8 API spec? That would be wrong, as a JSR number is pure administration and the API spec should deal only in features. For the bullet points, beware: an annotation whose type targets TYPE_USE can appear on a type declaration or a type parameter declaration. Surely you want such an annotation on class Foo's declaration to be discovered. Do you mean: - Annotations on type parameter declarations are included in discovery. - Annotations on type uses are not included in discovery. Alex From mernst at cs.washington.edu Sat Mar 30 11:34:57 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Sat, 30 Mar 2013 11:34:57 -0700 (PDT) Subject: [type-annos-observers] Constraining type annotations to occur just before type In-Reply-To: <514B64C3.6040306@oracle.com> References: <514A05AC.3080909@oracle.com> <20130321.102150.1919962541793975235.mernst@cs.washington.edu> <514B64C3.6040306@oracle.com> Message-ID: <20130330.113457.793719605306684806.mernst@cs.washington.edu> To follow up, I am convinced by the analogy to other code that is in bad style (but isn't forbidden by the compiler). That's in addition to the issues I brought up in my previous message. So, we'll keep the spec as it is. But, this would be a good thing for an IDE or code quality tool to warn about. I've added the advice about order of annotations (type annotations come last, immediately before the type name) to the JSR 308 specification. -Mike > Subject: Re: Constraining type annotations to occur just before type > From: Alex Buckley > To: type-annotations-spec-experts at openjdk.java.net > Date: Thu, 21 Mar 2013 12:51:31 -0700 > > On 3/21/2013 10:21 AM, Michael Ernst wrote: > > I agree entirely that it is terrible style to mix type annotations and > > declaration annotations (the declaration annotations should always come > > first) and that it is terrible style to mix type annotations with modifiers > > (the modifiers should come first). So, Alex's suggestion to change the > > advice is definitely good. Alex, can you make that change? It's outside > > the scope of the JSR 308 specification. > > Since type annotations are the reason to change the advice about modifier > order, the 308 spec should have a note giving the preferred layout of > declaration annotations v. type annotations. I will then incorporate it > into JLS sections which use modifiers. > > > I consider it an infelicity in the Java grammar that (declaration) > > annotations are considered modifiers and are lumped in with them, and even > > worse that type annotations get lumped in with declaration annotations. > > Logically, there are types and modifiers, and a type consists of optional > > type annotations followed by a Java type. This is how people should write > > them. > > Carefully distinguishing declaration annotations from type annotations > would be the heart of the new note :-) > > > Now, the question is whether or not the Java language should strictly > > enforce this practice. > > > > I'm sympathetic to this change -- probably my position is between > > Srikanth's and Alex's. I see the benefit of preventing confusing code > > rather than just advising programmers not to write it in the first place > > and then giving them rope to hang themselves. > > I understand, but there are infinite ways to writing confusing code in > Java, and none of them get their own compile-time error. Even potentially > unsafe use of raw types - which can lead to unpredictable program > termination! - only gets a compile-time warning. I think people are > over-rotating towards the IDE context, where informative messages and > warnings abound, rather than focusing on hard-edged rules of the language. > > > Incidentally, the Annotation File Utilities (AFU) grammar has these > > productions: > ... > > Elsewhere, the AFU grammar always uses the decl-annotation or > > type-annotation non-terminal, rather than just using the "annotation" > > non-terminal. The AFU grammar would accept exactly the same annotation > > files if it did not contain the decl-annotation and type-annotation > > non-terminals, but those clarify the meaning. > > > > We could imagine doing a similar thing with the JLS grammar, though the > > required changes would be more extensive. Modifiers would include > > declaration annotations but not type annotations, which would be rolled > > into types. I suspect that the reason I didn't do this in the first place > > was because I was trying to make the changes to the JLS grammar as minimal > > as possible to clarify what was actually changing. We've since moved away > > from that position (and even if we hadn't, what's good for a diff isn't > > necessarily good for a final version). > > As Jon implied in [1], the grammar would have to be relaxed (use only the > Annotation non-terminal) because parsers cannot in general do the semantic > analysis required to distinguish decl. from type annotations. It would have > to be a higher-level complaint - either a standard compile-time error or a > compiler-specific lint warning - if a decl. annotation is used where a type > annotation is required, and vice-versa. > > However, we cannot say that decl. annotations must come before traditional > modifiers (private/public/static/final etc) because it has been legal since > Java SE 5.0 to mix them up. The only rule which could possibly be added is > "type annotations are not modifiers, and occur after all modifiers (which > include declaration annotations)". I personally remain to be convinced that > this rule is necessary. > > Alex > > [1] > http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-March/000103.html From mernst at cs.washington.edu Sun Mar 31 10:47:47 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Sun, 31 Mar 2013 10:47:47 -0700 (PDT) Subject: [type-annos-observers] Comments and questions on JSR 308 draft from January 23, 2013 In-Reply-To: <51560C0E.5090104@oracle.com> References: <5147F5DE.6010006@oracle.com> <20130328.212241.1714870381793237549.mernst@cs.washington.edu> <51560C0E.5090104@oracle.com> Message-ID: <20130331.104747.118402603857440596.mernst@cs.washington.edu> > Subject: Re: Comments and questions on JSR 308 draft from January 23, 2013 > From: Alex Buckley > To: type-annotations-spec-experts > Date: Fri, 29 Mar 2013 14:47:58 -0700 > > Moving things along while Joe is away... > > On 3/28/2013 9:22 PM, Michael Ernst wrote: > >> "The optional receiver parameter has no effect on execution ? it only > >> serves as a place to write annotations > >> on the receiver. The compiler generates the same bytecodes, and reflection > >> returns the same results regarding > >> number of method formal parameters, whether or not the optional receiver > >> parameter is present." > >> > >> In Java SE 8, we are also adding support for more reflective information > >> about method and constructor parameters, including modifiers as to whether > >> or not they are "synthetic" vs "mandated". The explicit "receiver" > >> parameter declarations may alter how the corresponding > >> java.lang.reflect.Parameter objects should behave in some situations. In > >> any case, the specification should be updated to be explicit about any > >> interaction or non-interaction here. > > > > Can you point me at the specification? (I don't see a reference to this in > > lambda, so it must be separate.) > > An explicit receiver parameter isn't persisted as a formal parameter. > That's why JSR 308 prohibits a PARAMETER annotation from being applied > to it. It essentially disappears during compilation. The only trace is > that its TYPE_USE annotations persist in a *TypeAnnotations attribute in > method_info. Core reflection (j.l.r.Parameter) therefore knows nothing > about it. I've added a sentence of explanation along these lines, which should address Joe's desire for clarification, and will prevent confusion in the future. > Mike, please see section 2 of the PDF spec linked from > http://mail.openjdk.java.net/mailman/listinfo/enhanced-metadata-spec-discuss, > particularly the new JLS 13.1 section. This is very helpful, thanks. The new JLS 13.1 (from enhanced-metadata) uses "marked" without defining it. The current JLS 13.1 uses "marked as synthetic". It would be helpful to me if the new 13.1 was more explicit, and/or defined the term, and/or gave a cross-reference from the word "marked" to where its definition appears. (JVMS 4.7.22 does not use the terminology "marked".) > >> Section 3 > >> > >> "The VM does not have to validate all the constraints in Section 3.3, such > >> as that offsets point to the right type of > >> instruction. The VM does not do format checking (JVMS 4.8) on attributes > >> used solely for reflection." > >> > >> The JVMS has a rich terminology in terms of what checks happen (or not) > >> where and when in the linking and loading process. This description above > >> should be tied more directly to the JVMS concepts. > > > > Can you give specific, constructive suggestions for the terminology? You > > can probably do that quickly and easily. Thanks! > > For this and other text which says "nothing changes" (e.g. "No changes > are made to the StackMapTable ...") it is best just to take the text > out. I plan in JVMS8 to call out attributes which are read solely by the > core reflection API (it's a growing list), since they need to be > excepted from format checking, but there is nothing surprising about the > *TypeAnnotations attribute so the less said, the better. This is an easy change to make! I've done so, in all the places I saw this kind of wording. Let me know if I missed any. Thanks again. -Mike From mernst at cs.washington.edu Sun Mar 31 10:56:22 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Sun, 31 Mar 2013 10:56:22 -0700 (PDT) Subject: [type-annos-observers] FYI, JSR 308 and the annotation processing discovery process In-Reply-To: <51561161.8030207@oracle.com> References: <5155291F.2050907@oracle.com> <51561161.8030207@oracle.com> Message-ID: <20130331.105622.1728730259911912242.mernst@cs.washington.edu> Joe- Thanks for sharing this, and for the updates you are making. Adding to Alex's comments: > * TYPE_USE annotations are *not* included as part of discovery An annotation can be marked as targeting both TYPE_USE and other targets. Presumably you mean only those that target only TYPE_USE, or maybe you mean only those uses that are resolved to target TYPE_USE. I would find the text easier to understand with a sentence of explanation that remarks that the current annotation processing API is designed for, and suited for, declaration annotations, but it is not suited for processing type annotations. That explains why you are making the choices to ignore type annotations. -Mike > Subject: Re: FYI, JSR 308 and the annotation processing discovery process > From: Alex Buckley > To: Joe Darcy > Date: Fri, 29 Mar 2013 15:10:41 -0700 > > On 3/28/2013 10:39 PM, Joe Darcy wrote: > > FYI, as the JSR 269 maintenance lead, besides updating the > > javax.lang.model.* API to handle new-in-Java-SE-8 features, I'm not > > looking at updating the javax.annotation.processing API to deal with > > those new annotation-related features too. > > "not looking"? Surely "now looking". > > > "The tool uses a discovery process to find annotation processors and > > decide whether or not they should be run. [...] Which processors the > > tool asks to run is a function of what annotations are present on the > > root elements, what annotation types a processor processes, and whether > > or not a processor claims the annotations it processes. [...] For a > > given round, the tool computes the set of annotation types on the root > > elements. If there is at least one annotation type present, as > > processors claim annotation types, they are removed from the set of > > unmatched annotations." > > Close reading of the above paragraph reveals that: > > - a processor _claims_ annotation types > - a processor _claims_ annotations > - a processor _processes_ annotations > - from a set of annotations, it is possible to remove annotation _types_ > > I contend there is at least one kind error going on here. > > > To this, I plan to add a paragraph explaining how type annotations do > > not interact with the this discovery process; something like: > > > > "

An annotation type is considered present if there is at least one > > annotation of that type on a declaration enclosed within the root > > elements of a round. For this purpose, a type parameter is considered > > to be enclosed by its generic element. Annotations on type uses are > > not considered as part of the computation. > > There is quite a phase shift between the "For this purpose" sentence and > the type uses sentence. I think a new paragraph is warranted: "Annotations > on type uses are ignored when computing the set of annotation types present > on the root elements." > > > For the purposes of JSR 308: > > > > * Declaration annotations on type parameters are included in discovery > > * TYPE_USE annotations are *not* included as part of discovery > > You mean to put "For the purposes of JSR 308" into the SE 8 API spec? That > would be wrong, as a JSR number is pure administration and the API spec > should deal only in features. > > For the bullet points, beware: an annotation whose type targets TYPE_USE > can appear on a type declaration or a type parameter declaration. Surely > you want such an annotation on class Foo's declaration to be discovered. Do > you mean: > > - Annotations on type parameter declarations are included in discovery. > - Annotations on type uses are not included in discovery. > > Alex From mernst at cs.washington.edu Sun Mar 31 11:33:56 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Sun, 31 Mar 2013 11:33:56 -0700 (PDT) Subject: [type-annos-observers] JLS Creator production does not use 'Type' In-Reply-To: <511AEFD2.2030506@oracle.com> References: <511AEFD2.2030506@oracle.com> Message-ID: <20130331.113356.680248397878604207.mernst@cs.washington.edu> Alex- > The JSR 308 spec has a problem: the 'Creator' production in JLS ch.18 does > not use 'Type', so it is unaffected by JSR 308's addition of 'Annotations' > to 'Type'. In other words, no annotations after 'new' are permitted by the > spec! Obviously they should be, if their type has TYPE or TYPE_USE in > @Target. I'm sorry, but I can't remember what decision we made about fixing this problem with the JLS specification. Are you going to change that in the JLS, so that the JSR 308 specification doesn't have to call it out? Or, do you want the JSR 308 specification to change the BNF rules for Creator, ArrayCreator, and InnerCreator? Thanks, -Mike From mernst at cs.washington.edu Sun Mar 31 11:39:13 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Sun, 31 Mar 2013 11:39:13 -0700 (PDT) Subject: [type-annos-observers] Desugaring of anonymous classes Message-ID: <20130331.113913.2061923468052370653.mernst@cs.washington.edu> Dear type annotations specification experts, In January, I removed the text from the specification that was compiler-specific. This text was among the removed text: As another example, an anonymous class desugars into a class declaration and instantiation. A programmer may write both type and declaration annotations on an anonymous class in Java source code. In the classfile, the type annotations are copied to the class declaration and to its instantiation (new expression). The declaration annotations are copied only to the class declaration. Do you consider this possibly implementation-specific, and therefore it does not belong in the specification. Or, will every compiler follow this implementation strategy so it is worth re-instating as useful guidance? -Mike