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: 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: 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: 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 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: 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: 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: 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: 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: 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 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: 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 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: 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: 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 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: 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 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: 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: 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: 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: 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: 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