From mernst at cs.washington.edu Mon Apr 1 11:36:43 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Mon, 01 Apr 2013 11:36:43 -0700 (PDT) Subject: JSR 308 (type annotations) specification updated Message-ID: <20130401.113643.1596855887112289045.mernst@cs.washington.edu> I have posted an updated version of the JSR 308 (type annotations) specification, linked from http://types.cs.washington.edu/jsr308/. The changelog is available at http://types.cs.washington.edu/jsr308/specification/jsr308-changes.html and appears below my signature. -Mike Grammar changes: * Add missing modified grammar productions for AnnotationTypeElementRest and LocalVariableDeclarationStatement. Clarifications: * No dynamic dispatching occurs on the receiver of an inner constructor. * Explain the rationale for the syntax java.lang. at NonNull String, as opposed to java.lang. at NonNull String. * Explain why declaration annotations on a type parameter appear in the classfile in type_annotation elements rather than annotation elements. * The receiver parameter is not persisted as a formal parameter in the bytecode. * Remove text that says no changes are made, to reduce confusion and make it easier to integrate the text into the JLS. Advice: * In locations where all are permitted, type annotations should appear immediately before the type, after declaration annotations and modifiers. From alex.buckley at oracle.com Mon Apr 1 11:53:11 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 01 Apr 2013 11:53:11 -0700 Subject: Comments and questions on JSR 308 draft from January 23, 2013 In-Reply-To: <20130331.104747.118402603857440596.mernst@cs.washington.edu> References: <5147F5DE.6010006@oracle.com> <20130328.212241.1714870381793237549.mernst@cs.washington.edu> <51560C0E.5090104@oracle.com> <20130331.104747.118402603857440596.mernst@cs.washington.edu> Message-ID: <5159D797.8030607@oracle.com> On 3/31/2013 10:47 AM, Michael Ernst wrote: > 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".) My intent was that the logical terms "implicitly declared" and "not explicitly or implicitly declared" would appear in JLS 13.1 and then again in JVMS 4.1/4.5/4.6/4.7.22 where the ClassFile conveniently offers ACC_SYNTHETIC/ACC_MANDATED to physically reify those terms. But on reflection, there's nothing wrong with JLS 13.1 saying "marked _as synthetic_" and "marked _as mandated_". Thanks. Alex From joe.darcy at oracle.com Mon Apr 1 11:59:23 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 01 Apr 2013 11:59:23 -0700 Subject: FYI, JSR 308 and the annotation processing discovery process In-Reply-To: <20130331.105622.1728730259911912242.mernst@cs.washington.edu> References: <5155291F.2050907@oracle.com> <51561161.8030207@oracle.com> <20130331.105622.1728730259911912242.mernst@cs.washington.edu> Message-ID: <5159D90B.7090008@oracle.com> Hello, On 03/31/2013 10:56 AM, Michael Ernst wrote: > 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. If an annotation appears on a declaration, it will be included in discovery and if an annotation appears on a type use, it will *not* be included in discovery. If an annotation type is declared to be able to be applied to both declarations and type use, only the former applications will be visible to discovery. > > 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. The processing API from circa 2004 - 2006 was built around the assumption that annotations were only on declarations / elements. For example, for a round of processing there are methods to return the declarations / elements annotated with a particular annotation type: http://download.java.net/jdk8/docs/api/javax/annotation/processing/RoundEnvironment.html#getElementsAnnotatedWith(java.lang.Class) http://download.java.net/jdk8/docs/api/javax/annotation/processing/RoundEnvironment.html#getElementsAnnotatedWith(javax.lang.model.element.TypeElement) Consistency properties like "given the set of annotations to be processed on a round, you can find all the constructs annotated with those annotations by iterating over the elements annotated with each annotation" could not be maintained if type use annotations were included in discovery. This sort of rationale is useful, but generally not the sort of material we put into the javadoc of an API. However, it will certainly be germane to the maintenance review of JSR 269 for Java SE 8. Thanks, -Joe > > -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 alex.buckley at oracle.com Mon Apr 1 12:32:40 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 01 Apr 2013 12:32:40 -0700 Subject: JLS Creator production does not use 'Type' In-Reply-To: <20130331.113356.680248397878604207.mernst@cs.washington.edu> References: <511AEFD2.2030506@oracle.com> <20130331.113356.680248397878604207.mernst@cs.washington.edu> Message-ID: <5159E0D8.7060501@oracle.com> On 3/31/2013 11:33 AM, Michael Ernst wrote: >> 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. When and where was the message sent which calls out Creator as not using Type? I recall identifying that AnnotationTypeElementRest et al must use UnannType rather than Type - but I cannot find mails about Creator, so I am worried a production might be overlooked. > 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? The latter, please - 308 should add [Annotations] to Creator et al. The former - adopting Type in Creator et al - would be tricky because of diamond and partially-dimensioned array types. Alex From alex.buckley at oracle.com Mon Apr 1 12:59:09 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 01 Apr 2013 12:59:09 -0700 Subject: Desugaring of anonymous classes In-Reply-To: <20130331.113913.2061923468052370653.mernst@cs.washington.edu> References: <20130331.113913.2061923468052370653.mernst@cs.washington.edu> Message-ID: <5159E70D.2040702@oracle.com> On 3/31/2013 11:39 AM, Michael Ernst wrote: > 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? It would be better to start with the concept of a class instance creation expression (CICE) since it lets the locations be more precise. A CICE may create an instance of an anonymous class, in which case the declaration of the anonymous class is provided inline. This declaration is required by JLS 13.1 to compile to a form with a binary name; you can take this to mean a standalone class file is emitted. A CICE may have i) type annotations in the 'new ... {' term outside the anonymous class declaration, and ii) type annotations and declaration annotations inside the anonymous class declaration. It would be appropriate to specify: - The (i) annotations (type only) are stored for the CICE in its enclosing class file _and_ stored for the superclass of the anonymous class declaration in its emitted class file. - The (ii) annotations (type and decl) are stored for the appropriate type uses and declarations in the class file emitted for the anonymous class declaration. Alex From srikanth_sankaran at in.ibm.com Tue Apr 2 01:02:47 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 2 Apr 2013 13:32:47 +0530 Subject: Constraining type annotations to occur just before type In-Reply-To: <20130330.113457.793719605306684806.mernst@cs.washington.edu> References: <514A05AC.3080909@oracle.com> <20130321.102150.1919962541793975235.mernst@cs.washington.edu> <514B64C3.6040306@oracle.com> <20130330.113457.793719605306684806.mernst@cs.washington.edu> Message-ID: [I am sorry I was away from my mail for a few days and couldn't forward this feedback from Markus Keller of the Eclipse JDT team earlier - Srikanth] ----------------8<------------ > 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 agree we can't fix the Java 5 mix-up. The proposed rule sounds good. > I personally remain to be convinced that this rule is necessary. Allowing the TYPE_USE annotations not right in front of the variable or return type is even more absurd if the type is an array or qualified type: // Allowed (should be disallowed): @NonNull final String s2 = new @NonNull String(); // The @NonNull annotates "String", not the whole return type "String[]": @NonNull final String[] s3 = new @NonNull String[] { }; // Not allowed (annotation on package "java"): @NonNull final java.lang.String s4 = new @NonNull String(); // What the user meant: final java.lang. at NonNull String s5 = new @NonNull String(); I don't see any practical value in allowing TYPE_USE annotations to show up in front of other modifiers, but there's a clear reduction of confusion if they are only allowed at the end of the modifiers list. The compiler currently doesn't care much about the position of the annotations because it only marginally processes the annotations (for code generation). On the other hand, every tool that processes annotations is also affected by the torn-apart type references, since the AST becomes irregular. For refactoring tools, fetching the information from everywhere is a mess, and trivial rewrite operations like qualifying a type reference (compare s2 with s4) need much more logic than necessary. For users who have to read or manually refactor such code, it's an even bigger mess. Since "conventions" in the JLS are not binding, they are not a big help in practice. Conventions are fine to help users avoid bugs from earlier versions of the spec. But a new spec should not contain new conventions if it's trivial to just set a standard and avoid digressions. Let's list the arguments: Pro rule: * Easier to understand for everybody * Easier to process by tools and humans that refactor code * If necessary, rule can be relaxed later; but it cannot be added later Contra rule: * Source code incompatibility with pre-Java-8 hacks that use declaration annotations to stand for type annotations. => When an annotation becomes a TYPE_USE annotation, existing code needs to be massaged anyway. As the examples above show, the pre-Java-8 hacks are incompatible with Java 8 anyway. I'd even declare it a feature that users are forced to make a pass over their source in that case. * Rule cannot be implemented by the parser since the grammar is ambiguous. The grammar cannot be fixed, since the parser cannot distinguish TYPE_USE from other annotations in these cases (the parser did not resolve the @Target yet). The rule needs to be enforced at a later compilation step. * Rule needs to be implemented From alex.buckley at oracle.com Tue Apr 2 11:55:32 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 02 Apr 2013 11:55:32 -0700 Subject: Constraining type annotations to occur just before type In-Reply-To: References: <514A05AC.3080909@oracle.com> <20130321.102150.1919962541793975235.mernst@cs.washington.edu> <514B64C3.6040306@oracle.com> <20130330.113457.793719605306684806.mernst@cs.washington.edu> Message-ID: <515B29A4.4090006@oracle.com> I reiterate that compile-time errors are used _only_ when the program's implied behavior would cause a run-time error. Type annotations cannot cause that, so there is simply no case for a compile-time error about type annotations "in the wrong place". There is some confusion about what happens when an annotation type has TYPE_USE added as a target. No previous code becomes illegal. And forcing users to make a pass over their source is _never_ a feature of a programming language. I would add that even if type annotations were required to go at the end of the modifier list, it is still possible to write: public static final @Foo @Bar String s; Is @Foo a declaration annotation or a type annotation? If it's a poorly placed declaration annotation, then is @Bar the same, or a type annotation? You can't tell. It's up to the IDE to help out, not the compiler. Alex On 4/2/2013 1:02 AM, Srikanth S Adayapalam wrote: > [I am sorry I was away from my mail for a few days and couldn't > forward this feedback from Markus Keller of the Eclipse JDT team > earlier - Srikanth] > > ----------------8<------------ > >> 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 agree we can't fix the Java 5 mix-up. The proposed rule sounds good. > > >> I personally remain to be convinced that this rule is necessary. > > Allowing the TYPE_USE annotations not right in front of the variable or > return type is even more absurd if the type is an array or qualified type: > > // Allowed (should be disallowed): > @NonNull final String s2 = new @NonNull String(); > > // The @NonNull annotates "String", not the whole return type "String[]": > @NonNull final String[] s3 = new @NonNull String[] { }; > > // Not allowed (annotation on package "java"): > @NonNull final java.lang.String s4 = new @NonNull String(); > > // What the user meant: > final java.lang. at NonNull String s5 = new @NonNull String(); > > > I don't see any practical value in allowing TYPE_USE annotations to show up > in front of other modifiers, but there's a clear reduction of confusion if > they are only allowed at the end of the modifiers list. > > The compiler currently doesn't care much about the position of the > annotations because it only marginally processes the annotations (for code > generation). On the other hand, every tool that processes annotations is > also affected by the torn-apart type references, since the AST becomes > irregular. > > For refactoring tools, fetching the information from everywhere is a mess, > and trivial rewrite operations like qualifying a type reference (compare s2 > with s4) need much more logic than necessary. For users who have to read or > manually refactor such code, it's an even bigger mess. > > Since "conventions" in the JLS are not binding, they are not a big help in > practice. Conventions are fine to help users avoid bugs from earlier > versions of the spec. But a new spec should not contain new conventions if > it's trivial to just set a standard and avoid digressions. > > Let's list the arguments: > > Pro rule: > * Easier to understand for everybody > * Easier to process by tools and humans that refactor code > * If necessary, rule can be relaxed later; but it cannot be added later > > Contra rule: > * Source code incompatibility with pre-Java-8 hacks that use > declaration annotations to stand for type annotations. > => When an annotation becomes a TYPE_USE annotation, existing code needs > to be massaged anyway. As the examples above show, the pre-Java-8 hacks are > incompatible with Java 8 anyway. I'd even declare it a feature that users > are forced to make a pass over their source in that case. > * Rule cannot be implemented by the parser since the grammar is ambiguous. > The grammar cannot be fixed, since the parser cannot distinguish TYPE_USE > from other annotations in these cases (the parser did not resolve the > @Target yet). The rule needs to be enforced at a later compilation step. > * Rule needs to be implemented > From joe.darcy at oracle.com Wed Apr 3 19:11:40 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 03 Apr 2013 19:11:40 -0700 Subject: Comments and questions on JSR 308 draft from January 23, 2013 In-Reply-To: <20130328.212955.1561485238142075094.mernst@cs.washington.edu> References: <5147F5DE.6010006@oracle.com> <20130328.212955.1561485238142075094.mernst@cs.washington.edu> Message-ID: <515CE15C.9030602@oracle.com> Hi Mike, On 3/28/2013 9:29 PM, Michael Ernst wrote: > 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. It would be possible to forbid the combination of the "denigrated" feature of mixed array declarations and the new feature of type annotations. No existing code would be directly impacted. > > 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 I'm aware that there were discussions about whether the [] in array declarations go inside-out or outside-in. I assume the mixed array declarations complicate the convention that has been determined for the non-mixed case. If so, I suggest contemplating not allowing the combination of type annotations and mixed array declarations. Cheers, -Joe From srikanth_sankaran at in.ibm.com Wed Apr 3 22:11:14 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Thu, 4 Apr 2013 10:41:14 +0530 Subject: Fw: Constraining type annotations to occur just before type Message-ID: More comments from Eclipse JDT team... Srikanth. ----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/04/2013 10:40 AM ----- From: Markus Keller/Zurich/IBM at IBMCH To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, Date: 04/03/2013 08:32 PM Subject: Re: Fw: Constraining type annotations to occur just before type > I reiterate that compile-time errors are used _only_ when the program's > implied behavior would cause a run-time error. Not really. There are e.g. compile errors if an annotation type cannot be resolved, if an @Target annotation is wrongly placed on a non-annotation type, or if an @Override annotation doesn't find a super method: @Target(ElementType.METHOD) public class Overriding { @Override public void bummer() { } } So the JLS can just as well demand that the compiler verifies that the TYPE_USE annotations are at the right position. > There is some confusion about what happens when an annotation type has > TYPE_USE added as a target. No previous code becomes illegal. It depends on the semantics of the annotation processor. Since JSR 308 specifies the class file format, it also partially specifies the semantics of TYPE_USE annotations. Not the semantics of an annotation itself, but its attachment point in the language model. In "@NonNull String[] s3", the compilation depends on the annotation's @Target meta-annotation. If it's a TYPE_USE annotation, it is now compiled as a Runtime [In]VisibleTypeAnnotations. In this example, it's no longer an annotation on the whole variable, but an annotation on the "String" type fragment of the variable. Adding TYPE_USE to an existing annotation may be superficially compatible (on a syntactical level), but in practice, it's _always_ a breaking change, since the TYPE_USE annotation is compiled into different attributes than annotations with other ElementTypes, and since it sometimes targets a different language element. Adding TYPE_USE to an existing annotation is not a source-compatible change if you assume that the annotation has any semantics (which is safe to assume, otherwise the annotation wouldn't exist). And since we already have a source-incompatible change, it's not a big deal if there's an additional restriction on the position of these annotations. > public static final @Foo @Bar String s; To generate correct class files, the compiler must know whether the annotations are TYPE_USE kinds or not. A purely syntactical parser indeed can't tell, but as soon as types are resolved, the information is available. Markus Alex Buckley wrote: > I reiterate that compile-time errors are used _only_ when the program's > implied behavior would cause a run-time error. Type annotations cannot > cause that, so there is simply no case for a compile-time error about > type annotations "in the wrong place". > > There is some confusion about what happens when an annotation type has > TYPE_USE added as a target. No previous code becomes illegal. And > forcing users to make a pass over their source is _never_ a feature of a > programming language. > > I would add that even if type annotations were required to go at the end > of the modifier list, it is still possible to write: > > public static final @Foo @Bar String s; > > Is @Foo a declaration annotation or a type annotation? If it's a poorly > placed declaration annotation, then is @Bar the same, or a type > annotation? You can't tell. It's up to the IDE to help out, not the > compiler. > > Alex > > On 4/2/2013 1:02 AM, Srikanth S Adayapalam wrote: > > [I am sorry I was away from my mail for a few days and couldn't > > forward this feedback from Markus Keller of the Eclipse JDT team > > earlier - Srikanth] > > > > ----------------8<------------ > > > >> 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 agree we can't fix the Java 5 mix-up. The proposed rule sounds good. > > > > > >> I personally remain to be convinced that this rule is necessary. > > > > Allowing the TYPE_USE annotations not right in front of the variable or > > return type is even more absurd if the type is an array or qualified type: > > > > // Allowed (should be disallowed): > > @NonNull final String s2 = new @NonNull String(); > > > > // The @NonNull annotates "String", not the whole return type "String []": > > @NonNull final String[] s3 = new @NonNull String[] { }; > > > > // Not allowed (annotation on package "java"): > > @NonNull final java.lang.String s4 = new @NonNull String(); > > > > // What the user meant: > > final java.lang. at NonNull String s5 = new @NonNull String(); > > > > > > I don't see any practical value in allowing TYPE_USE annotations to show up > > in front of other modifiers, but there's a clear reduction of confusion if > > they are only allowed at the end of the modifiers list. > > > > The compiler currently doesn't care much about the position of the > > annotations because it only marginally processes the annotations (for code > > generation). On the other hand, every tool that processes annotations is > > also affected by the torn-apart type references, since the AST becomes > > irregular. > > > > For refactoring tools, fetching the information from everywhere is a mess, > > and trivial rewrite operations like qualifying a type reference (compare s2 > > with s4) need much more logic than necessary. For users who have to read or > > manually refactor such code, it's an even bigger mess. > > > > Since "conventions" in the JLS are not binding, they are not a big help in > > practice. Conventions are fine to help users avoid bugs from earlier > > versions of the spec. But a new spec should not contain new conventions if > > it's trivial to just set a standard and avoid digressions. > > > > Let's list the arguments: > > > > Pro rule: > > * Easier to understand for everybody > > * Easier to process by tools and humans that refactor code > > * If necessary, rule can be relaxed later; but it cannot be added later > > > > Contra rule: > > * Source code incompatibility with pre-Java-8 hacks that use > > declaration annotations to stand for type annotations. > > => When an annotation becomes a TYPE_USE annotation, existing code needs > > to be massaged anyway. As the examples above show, the pre-Java-8 hacks are > > incompatible with Java 8 anyway. I'd even declare it a feature that users > > are forced to make a pass over their source in that case. > > * Rule cannot be implemented by the parser since the grammar is ambiguous. > > The grammar cannot be fixed, since the parser cannot distinguish TYPE_USE > > from other annotations in these cases (the parser did not resolve the > > @Target yet). The rule needs to be enforced at a later compilation step. > > * Rule needs to be implemented > > > From srikanth_sankaran at in.ibm.com Wed Apr 3 22:15:13 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Thu, 4 Apr 2013 10:45:13 +0530 Subject: Constraining type annotations to occur just before type In-Reply-To: References: Message-ID: Yet more comments from the Eclipse JDT team. Srikanth --------------------------8<----------------- Another example that shows the inconsistency is the different intended semantics of annotations in multi-field declarations and union types in catch clauses. The @NonNull in the field declaration's modifiers list appears in the type of "a" (@NonNull String) as well as in the type of "b" (array of (@NonNull String)): @NonNull String a, b[]; But here, I would assume the @NonCritical in the modifiers list only applies to the first type of the union: catch (final @NonCritical AccountException | @Critical AccessException ex) Note that the classfile format currently mixes the annotations of all union types together into one EXCEPTION_PARAMETER entry for the catch variable. ----------------------------------------------- The problem is that the JSR 308 only specifies positions in the source code where annotations can appear, but it even says "it makes no commitment as to their semantics". For a compiler that is only concerned about generating class files, that's in most cases enough. But it makes it very hard for language tooling to process these annotations in a sensible way. > > @NonNull String a, b[]; > > And you are saying that is what a programmer would expect - right ? Yes. In this case, JSR 308 2.2.1 tells that the @NonNull is used for both variables. So it does attach some semantics to the annotation. > > But here, I would assume the @NonCritical in the modifiers list only applies > > to the first type of the union: > > > > catch (final @NonCritical AccountException | @Critical AccessException ex) > > And by "I would assume" you are saying that this is what a programmer would > intuitively expect - right ? Yes. But the spec doesn't say a word about the union type case. There's just the table in 3.2 and section 3.3.8, from which we have to assume that the annotations from all union types are collapsed into the same EXCEPTION_PARAMETER target. If I can put different annotations on different union type alternatives, then I would expect them to be treated separately. Currently, the compilation cuts the connection from an EXCEPTION_PARAMETER annotation to its type. http://types.cs.washington.edu/jsr308/specification/java-annotation-extensions.html#locations-disjunctions also assumes that annotations only belong to their union type alternative. From alex.buckley at oracle.com Thu Apr 4 13:04:26 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 04 Apr 2013 13:04:26 -0700 Subject: Fw: Constraining type annotations to occur just before type In-Reply-To: References: Message-ID: <515DDCCA.5050908@oracle.com> Answers inline. On 4/3/2013 10:11 PM, Srikanth S Adayapalam wrote: > More comments from Eclipse JDT team... > > Srikanth. > > ----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/04/2013 10:40 AM > ----- > > From: Markus Keller/Zurich/IBM at IBMCH > To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, > Date: 04/03/2013 08:32 PM > Subject: Re: Fw: Constraining type annotations to occur just before type > > >> I reiterate that compile-time errors are used _only_ when the program's >> implied behavior would cause a run-time error. > > Not really. There are e.g. compile errors if an annotation type cannot be > resolved, if an @Target annotation is wrongly placed on a non-annotation > type, or if an @Override annotation doesn't find a super method: > > @Target(ElementType.METHOD) > public class Overriding { > @Override > public void bummer() { } > } > > So the JLS can just as well demand that the compiler verifies that the > TYPE_USE annotations are at the right position. I accept that "only" was too strong. It's true that applying an annotation of type T to a location not allowed by T's own @Target meta-annotation is unlikely to cause a run-time error. Still, it's easily recognizable as wrong. The ordering of modifiers is a softer topic where new rules are likely to trip up old code - a bad thing. (The other examples of compile-time errors are a bit tricky. If a compiler can't resolve an annotation type, then the compiler can't possibly process source correctly which uses annotations of that type; any class file emitted would be likely to exhibit a run-time error, so a compile-time error is appropriate to prevent that implied behavior. For @Override, its semantics do not in my view justify a compile-time error; it should have been designed to cause a mandatory compile-time warning, a mechanism introduced in Java SE 5.0 for other reasons.) >> There is some confusion about what happens when an annotation type has >> TYPE_USE added as a target. No previous code becomes illegal. > > It depends on the semantics of the annotation processor. Since JSR 308 > specifies the class file format, it also partially specifies the semantics > of TYPE_USE annotations. Not the semantics of an annotation itself, but its > attachment point in the language model. In "@NonNull String[] s3", the > compilation depends on the annotation's @Target meta-annotation. If it's a > TYPE_USE annotation, it is now compiled as a Runtime > [In]VisibleTypeAnnotations. In this example, it's no longer an annotation > on the whole variable, but an annotation on the "String" type fragment of > the variable. > > Adding TYPE_USE to an existing annotation may be superficially compatible > (on a syntactical level), but in practice, it's _always_ a breaking change, > since the TYPE_USE annotation is compiled into different attributes than > annotations with other ElementTypes, and since it sometimes targets a > different language element. Adding TYPE_USE to an existing annotation is > not a source-compatible change if you assume that the annotation has any > semantics (which is safe to assume, otherwise the annotation wouldn't > exist). And since we already have a source-incompatible change, it's not a > big deal if there's an additional restriction on the position of these > annotations. Adding TYPE_USE as an additional target of an existing annotation type causes no compile-time errors when existing source which uses annotations of that type is recompiled. That's basically the definition of a source-compatible change. End of story. It's true that an annotation at a given location may now be _both_ a declaration annotation (i.e. on the s3 variable) and a type annotation (i.e. on s3's type). It will be reified in the class file in multiple attributes, and available to clients of the core reflection and language model APIs _if they use the new methods for obtaining type annotations_. An existing annotation processor (which uses the SE 7-era methods that retrieve only declaration annotations) sees no change. Bottom line, adding TYPE_USE is compatible in all dimensions. >> public static final @Foo @Bar String s; > > To generate correct class files, the compiler must know whether the > annotations are TYPE_USE kinds or not. A purely syntactical parser indeed > can't tell, but as soon as types are resolved, the information is > available. Understood. Rejecting constraints on type annotation placement is not about implementation difficulty. It is about three things: - If TYPE_USE is added as a target for an annotation type which previously targeted only declarations, then the annotation can appear at the start or end of the modifier list. So, the constraint is not always applicable. - If TYPE_USE is made the _sole_ target for an annotation type, then the constraint causes the re-targeting to be a source-incompatible change. This is potentially a big problem because the incompatibilities could be anywhere. (Fixing up one annotation processor to look in the new locations is easy by comparison.) - In any case, the constraint doesn't make the human reader any wiser about what kind of annotation @Foo is, or @Bar is. Alex From mernst at cs.washington.edu Thu Apr 4 21:02:07 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 04 Apr 2013 21:02:07 -0700 (PDT) Subject: annotations on type uses in throws and catch clauses In-Reply-To: References: Message-ID: <20130404.210207.478919438739168166.mernst@cs.washington.edu> Srikanth- Thanks for forwarding these comments! You've identified a flaw in the JLS grammar, which seeped through into the JSR 308 grammar. I've made changes to the specification in response. > I would assume the @NonCritical in the modifiers list only > applies to the first type of the union: > > catch (final @NonCritical AccountException | @Critical AccessException > ex) > > Note that the classfile format currently mixes the annotations of all union > types together into one EXCEPTION_PARAMETER entry for the catch variable. > ... But the spec doesn't say a word about the union type case. There's > just the table in 3.2 and section 3.3.8, from which we have to assume that > the annotations from all union types are collapsed into the same > EXCEPTION_PARAMETER target. > > If I can put different annotations on different > union type alternatives, then I would expect them to be treated separately. > Currently, the compilation cuts the connection from an EXCEPTION_PARAMETER > annotation to its type. The easy answer to your comment is that your proposed syntax for an exception parameter declaration catch (final @NonCritical AccountException | @Critical AccessException ex) is not legal according to the current JSR 308 specification. A programmer can currently only write an annotation at the beginning of the exception parameter declaration. You might ask, why *isn't* it possible to write catch (final @NonCritical AccountException | @Critical AccessException ex) ? The answer is that it should be possible! This is a bug in the JSR 308 specification. As background, the JLS grammar is sloppy about whether a particular construct is a type use or something else. The JSR 308 spec changes the JLS grammar to clarify this issue, but this is a case that I missed. I'm amazed that it took until now for anyone to notice this. I have changed the JSR 308 grammar to rename the non-terminals that are used in throws and catch clauses. The throws and catch grammar rules now use QualifiedTypeList and QualifiedType (which can be annotated), rather than QualifiedIdentifierList and Identifier which cannot. Note that type parameters and arrays are forbidden in such locations. Also note that there is no way to write a single annotation that applies to all the types in the multi-catch. This may cause a bit of duplication, in that a programmer may need to write a given annotation on all the clauses of a multi-catch. However, being able to annotate each disjunct individually is more expressive. I added some explanatory text in section 3.3.8 that the source code's correspondence between union type alternatives and annotations must be maintained in the classfile. This is obvious, but as you point out, it is worth stating explicitly to avoid confusion. It is already possible to write a legal classfile in which there are two entries in the exception table, with different annotations. That shows how a compiler can compile such code. I also clarified that the JSR 308 spec does not specify the semantics of any annotation type, though of course it does specify both source and classfile syntax and the mapping between them. I am attaching the latest version of the specification, with my changes. Let me know if I made any late-night-editing goofs. Thanks again for the very useful comments that are helping to smooth out rough corners in the specification! I appreciate it, and please keep them coming. -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: design.pdf Type: application/pdf Size: 208973 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/attachments/20130404/66ce0ea9/design-0001.pdf From srikanth_sankaran at in.ibm.com Fri Apr 5 20:13:01 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Sat, 6 Apr 2013 08:43:01 +0530 Subject: Fw: Constraining type annotations to occur just before type Message-ID: More comments from Eclipse JDT team ... Srikanth ----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/06/2013 08:42 AM ----- From: Markus Keller/Zurich/IBM at IBMCH To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, Date: 04/05/2013 10:11 PM Subject: Re: Fw: Constraining type annotations to occur just before type Let's closely look at "@NonNull final String[] s3" again. I agree that adding TYPE_USE to an existing NonNull's @Target doesn't change the code generation for declaration targets like FIELD, and that it's not a source-incompatible change from a Java language point of view that doesn't attach any semantics to annotations nor to the @Target meta-annotation. The declaration annotation will still be compiled into the field_info's attributes list. From a language model point of view, the annotation belongs to the declaration. If it was actually meant to be a type-use annotation, then the tooling that knows about the semantics of the annotation would consider the annotation to be on the type of the field, i.e. on "String[]". On the other hand, the 308 spec says how a type-use annotation is to be interpreted: as an annotation on "String", not on "String[]". As the JSR 308 spec says at the end of section 2, we don't expect any real use case where an annotation type supports both a declaration and a type-use target. This combination just doesn't make sense, since it would be unclear which attachment point "wins". They can't both be correct at the same time. If a type-use annotation should target the whole field type "String[]", then it needs to be put in front of the "[]", i.e. "String @NonNull[]". Since adding TYPE_USE changes the attachment point of an annotation, this is not a compatible change. TYPE_USE fundamentally changes the semantics of an annotation type and the correct syntax for annotations of that annotation type. The jsr308 grammar is not trivial to understand because a type-use annotation has the same syntax as a declaration annotation. Just consider for a moment, how it would look like if type-use annotations had to be written with two @, i.e. "final String @@NonNull[] s3". That makes it much easier to keep the different kinds of annotations apart. In the grammar, that would clearly separate the two kinds: TypeUseAnnotations: TypeUseAnnotation TypeUseAnnotations TypeUseAnnotation TypeUseAnnotation: @Annotation Type: [TypeUseAnnotations] BasicType {[TypeUseAnnotations] []} [TypeUseAnnotations] ReferenceType {[TypeAnnotations] []} ReferenceType: Identifier [TypeArguments] { . [TypeUseAnnotations] Identifier [TypeArguments]} // no need for an UnannType, etc. I'm not actually proposing the @@ syntax, and I don't know if changing the grammar like this would make it easier or harder for parser implementers. But this would make it clear where a type-use annotation belongs and where not. Adding TYPE_USE to an existing annotation type is similar in impact as changing the superclass of a public class. For client code, this can be a source-compatible change in some cases, but a breaking change in others. Note that the proposal to restrict the position of type-use annotations does not affect any existing code. It only affects references to annotation types that changed in an incompatible way. > - If TYPE_USE is made the _sole_ target for an annotation type, then the > constraint causes the re-targeting to be a source-incompatible change. > This is potentially a big problem because the incompatibilities could be > anywhere. (Fixing up one annotation processor to look in the new > locations is easy by comparison.) Adding TYPE_USE is _always_ a big problem. Not so much for an annotation processor, but for client code where this changes the semantics. I would expect that a Java compiler informs me about fallout from that problem, rather than trying to hide the difficulties. Java is not a language that accepts "minor syntax errors". Markus From alex.buckley at oracle.com Mon Apr 8 14:35:23 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 08 Apr 2013 14:35:23 -0700 Subject: Fw: Constraining type annotations to occur just before type In-Reply-To: References: Message-ID: <5163381B.60002@oracle.com> On 4/5/2013 8:13 PM, Srikanth S Adayapalam wrote: > From: Markus Keller/Zurich/IBM at IBMCH > To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, > Date: 04/05/2013 10:11 PM > Subject: Re: Fw: Constraining type annotations to occur just before type > > > Let's closely look at "@NonNull final String[] s3" again. > > I agree that adding TYPE_USE to an existing NonNull's @Target doesn't > change the code generation for declaration targets like FIELD, and that > it's not a source-incompatible change from a Java language point of view > that doesn't attach any semantics to annotations nor to the @Target > meta-annotation. Right. > The declaration annotation will still be compiled into the field_info's > attributes list. From a language model point of view, the annotation > belongs to the declaration. If it was actually meant to be a type-use > annotation, then the tooling that knows about the semantics of the > annotation would consider the annotation to be on the type of the field, > i.e. on "String[]". The annotation is compiled as if a declaration annotation and a type annotation. The language model API has been upgraded in concert. It exposes @NonNull on the declaration of the field (Element#getAnnotationMirrors) and on the type of the field (Element#asType#getAnnotationMirrors). The core reflection API has been upgraded too. > On the other hand, the 308 spec says how a type-use annotation is to be > interpreted: as an annotation on "String", not on "String[]". First, it is quite possible that @NonNull was intended to apply to String and not String[]. Second, even if @NonNull was intended to apply to String[], all that means is that client code which uses new methods in the SE 8 API to read type annotations will have to be careful if the type annotation is also a declaration annotation. Migration isn't always free. > As the JSR 308 spec says at the end of section 2, we don't expect any real > use case where an annotation type supports both a declaration and a > type-use target. This combination just doesn't make sense, since it would > be unclear which attachment point "wins". They can't both be correct at the > same time. If a type-use annotation should target the whole field type > "String[]", then it needs to be put in front of the "[]", i.e. "String > @NonNull[]". Sigh. This is the danger of non-normative text in a specification: it doesn't take care to spell out the whole story. The use case where both are correct is migration from declaration annotations to type annotations. > Since adding TYPE_USE changes the attachment point of an annotation, this > is not a compatible change. Incorrect. Adding TYPE_USE augments the attachment points. The old attachment points are still exposed by the SE 7-era API. It is a source, binary, and behaviorally compatible change. > TYPE_USE fundamentally changes the semantics of > an annotation type and the correct syntax for annotations of that > annotation type. The jsr308 grammar is not trivial to understand because a > type-use annotation has the same syntax as a declaration annotation. Just > consider for a moment, how it would look like if type-use annotations had > to be written with two @, i.e. "final String @@NonNull[] s3". That makes it > much easier to keep the different kinds of annotations apart. In the > grammar, that would clearly separate the two kinds: > > TypeUseAnnotations: > TypeUseAnnotation > TypeUseAnnotations TypeUseAnnotation > > TypeUseAnnotation: > @Annotation > > Type: > [TypeUseAnnotations] BasicType {[TypeUseAnnotations] []} > [TypeUseAnnotations] ReferenceType {[TypeAnnotations] []} > > ReferenceType: > Identifier [TypeArguments] { . [TypeUseAnnotations] Identifier > [TypeArguments]} > > // no need for an UnannType, etc. > > I'm not actually proposing the @@ syntax, and I don't know if changing the > grammar like this would make it easier or harder for parser implementers. > But this would make it clear where a type-use annotation belongs and where > not. > > Adding TYPE_USE to an existing annotation type is similar in impact as > changing the superclass of a public class. For client code, this can be a > source-compatible change in some cases, but a breaking change in others. We're going round in circles. There is no comparison from a Java compiler's point of view. Adding TYPE_USE as a target introduces no compile-time errors. Client code which seeks to work with both declaration and type annotations lives in a different universe and must take care. >> - If TYPE_USE is made the _sole_ target for an annotation type, then the >> constraint causes the re-targeting to be a source-incompatible change. >> This is potentially a big problem because the incompatibilities could be >> anywhere. (Fixing up one annotation processor to look in the new >> locations is easy by comparison.) > > Adding TYPE_USE is _always_ a big problem. Not so much for an annotation > processor, but for client code where this changes the semantics. I would > expect that a Java compiler informs me about fallout from that problem, > rather than trying to hide the difficulties. Java is not a language that > accepts "minor syntax errors". I don't understand what this "client code" is. The only place where "semantics" is a valid concern is if code starts to use SE 8 API methods to read type annotations, since they will appear on the ground type (String) which may not have been the intended location (String[]) circa SE 7. Alex From mernst at cs.washington.edu Mon Apr 8 20:42:00 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Mon, 08 Apr 2013 20:42:00 -0700 (PDT) Subject: Constraining type annotations to occur just before type In-Reply-To: <5163381B.60002@oracle.com> References: Message-ID: <20130408.204200.685808678305560049.mernst@cs.washington.edu> Srikanth- Thanks for the continued comments. This discussion is useful. I agree that arrays are an interesting and potentially tricky special case, because Java puts the main part of an array type last instead of first. But, I would caution against basing an argument too strongly on array examples. Most Java code does not use arrays, or at least uses them less than non-arrays. I am reluctant to break source-code compatibility (that is, force refactoring and possibly prevent old and new tools from being run on a single codebase) in the common case in order to give a compile-time warning for the uncommon case. That's especially true because running a pluggable type-checker would already provide the programmer with compile-time warnings about any annotations that are being interpreted differently than the programmer intended. Adding TYPE_USE to @Target purely augments the behavior and never actually changes it in an incompatible way. I think a misunderstanding of this might be at the root of some of our disagreements. (By contrast, your incompatibility argument is valid if one were to change a declaration annotation, so that it is no longer applicable at declaration locations. But that isn't the use case you were thinking of, I believe.) The JLS grammar might be another source of confusion. There is just one production for all annotations, and it might seem that thus all those annotations belong to the declaration. That is not the case -- in the language model, some annotations belong to the type and some belong to the declaration, regardless of the parsed AST produced by the JLS grammar. -Mike From alex.buckley at oracle.com Wed Apr 10 17:54:09 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 10 Apr 2013 17:54:09 -0700 Subject: Clarifying the receiver parameter Message-ID: <516609B1.4060803@oracle.com> There is some confusion around i) the type and ii) the name of the formal parameter which represents the receiver of an inner class's constructor or instance method. The current text is just "For a method, the receivers are named this, Outer.this, etc." and "Within an inner class constructor, the receiver has a name such as Outer.this". This doesn't help with the legality of the following receiver parameters, both of which should be legal: package p; class Outer { class Inner { Inner(p.Outer p.Outer.this) {} } } package p; class Outer { class Middle { class Inner { Inner(Outer.Middle Outer.Middle.this) {} } } } It needs to be stated that: "The receiver of a constructor or instance method of an inner class C, a direct inner class of O (8.1.3), is denoted by a formal parameter which appears first in the formal parameter list, and whose type is O, and whose name is a qualified this expression (15.8.4) which would, if used in the body of the constructor or instance method, refer to the immediately enclosing instance of the instance of C." By saying "whose type is O", we delegate to the normal process of resolving a type name. And by saying the name is that of a qualified this expression, we get the type resolution of the ClassName in a qualified this. Finally, we should apply the same technique for non-inner ctors/methods: "The receiver of a constructor or instance method of a top-level class C is denoted by a formal parameter which appears first in the formal parameter list, and whose type is C, and whose name is a this expression (15.8.3) or qualified this expression (15.8.4) which would, if used in the body of the constructor or instance method, refer to the instance of C." which rightly allows: package p; class C { void m(p.C p.C.this) {} } (We need to allow a qualified this expression as the name because such an expression in the body can refer to _any_ lexically enclosing instance of C _including the zeroth lexically enclosing instance of C_ which is C itself.) Alex From srikanth_sankaran at in.ibm.com Fri Apr 12 03:27:46 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Fri, 12 Apr 2013 15:57:46 +0530 Subject: Fw: Constraining type annotations to occur just before type Message-ID: Follow up comments from Markus Keller, IBM (Eclipse JDT/UI lead) Srikanth ----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/12/2013 03:57 PM ----- From: Markus Keller/Zurich/IBM at IBMCH To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, Date: 04/10/2013 09:31 PM Subject: Re: Fw: Constraining type annotations to occur just before type > I don't understand what this "client code" is. The only place where > "semantics" is a valid concern is if code starts to use SE 8 API methods > to read type annotations, since they will appear on the ground type > (String) which may not have been the intended location (String[]) circa > SE 7. With "client code", I mean Java 7 code that uses an annotation and some compiler add-on that processes the annotation. E.g. the cited @NonNull final String[] s3; or even @NonNull final java.lang.String s4; // legal ONLY for declaration annot. final java.lang. at NonNull String s5; // legal ONLY for type-use annotations The @NonNull annotation has some semantics that are defined by the annotation type and the compiler add-on. The @NonNull annotation is the perfect candidate that wants to migrate to TYPE_USE in Java 8. My point is that there's no way @NonNull can be a declaration and a type-use annotation at the same time, and both of these usages have the same semantics. Yes, you can declare separate reflection APIs for declaration and type-use annotations, but in the end, the compiler add-on that implements the annotation's semantics needs to decide which one to use. And it will show different behavior depending on the used API. Disregarding the semantics of the annotation doesn't make sense. You can't just look at the compiler and reflection APIs in isolation. You also have consider who will use them. The examples s4/s5 with the qualified name shows that it's not even possible to use an @Target({ElementType.FIELD, ElementType.TYPE_USE}) annotation in certain cases that were legal with @Target ({ElementType.FIELD}) alone, since the two target kinds _require_ different positions in the AST. Therefore, adding TYPE_USE is not a 100% source-compatible change, even if you disregard the semantics of the annotation. The spec should not make it look like it's a valid transition path for an existing declaration annotation type to add the TYPE_USE target. I would even disallow this combination, since we haven't found a single use case where it would make sense. TYPE_USE should only be used as the sole @Target. Providers of Java 7 annotation types that want to migrate to TYPE_USE should make it clear that this change is not for free for client code in all cases. That standpoint also gives us the freedom to constrain TYPE_USE annotations to occur just before the type. Markus From srikanth_sankaran at in.ibm.com Tue Apr 16 22:33:14 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Wed, 17 Apr 2013 11:03:14 +0530 Subject: Clarifying the receiver parameter In-Reply-To: <516609B1.4060803@oracle.com> References: <516609B1.4060803@oracle.com> Message-ID: Alex, Could you please provide some rationale/justification for why a fully-qualified name as qualifier of a the receiver parameter's "this" is necessary ? The qualifier would always be redundant and is therefore best not allowed obviating the need for a different grammar. The only situation where the "this" parameter needs a qualifier is in the constructor of an inner class. It is agreed that jsr308 spec in 2.1.5 is not entirely clear about the correct usage of the receiver parameter's "this". It should specify the allowed constructs, rather than just give an example. Srikanth type-annotations-spec-experts-bounces at openjdk.java.net wrote on 04/11/2013 06:24:09 AM: > From: Alex Buckley > To: type-annotations-spec-experts experts at openjdk.java.net>, > Date: 04/11/2013 06:24 AM > Subject: Clarifying the receiver parameter > Sent by: type-annotations-spec-experts-bounces at openjdk.java.net > > There is some confusion around i) the type and ii) the name of the > formal parameter which represents the receiver of an inner class's > constructor or instance method. > > The current text is just "For a method, the receivers are named this, > Outer.this, etc." and "Within an inner class constructor, the receiver > has a name such as Outer.this". This doesn't help with the legality of > the following receiver parameters, both of which should be legal: > > package p; > class Outer { > class Inner { > Inner(p.Outer p.Outer.this) {} > } > } > > package p; > class Outer { > class Middle { > class Inner { > Inner(Outer.Middle Outer.Middle.this) {} > } > } > } > > It needs to be stated that: "The receiver of a constructor or instance > method of an inner class C, a direct inner class of O (8.1.3), is > denoted by a formal parameter which appears first in the formal > parameter list, and whose type is O, and whose name is a qualified this > expression (15.8.4) which would, if used in the body of the constructor > or instance method, refer to the immediately enclosing instance of the > instance of C." > > By saying "whose type is O", we delegate to the normal process of > resolving a type name. And by saying the name is that of a qualified > this expression, we get the type resolution of the ClassName in a > qualified this. > > Finally, we should apply the same technique for non-inner ctors/methods: > > "The receiver of a constructor or instance method of a top-level class C > is denoted by a formal parameter which appears first in the formal > parameter list, and whose type is C, and whose name is a this expression > (15.8.3) or qualified this expression (15.8.4) which would, if used in > the body of the constructor or instance method, refer to the instance of C." > > which rightly allows: > > package p; > class C { > void m(p.C p.C.this) {} > } > > (We need to allow a qualified this expression as the name because such > an expression in the body can refer to _any_ lexically enclosing > instance of C _including the zeroth lexically enclosing instance of C_ > which is C itself.) > > Alex > From mernst at cs.washington.edu Wed Apr 17 07:23:21 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Wed, 17 Apr 2013 07:23:21 -0700 (PDT) Subject: Removing target_type distinctions between constructors and methods Message-ID: <20130417.072321.584038017916992251.mernst@cs.washington.edu> Currently, the Type Annotations (JSR 308) Specification uses different TargetType enum constants and target_type values for constructors and methods. For example, here are target_type values: 0x45 constructor reference receiver 0x46 method reference receiver 0x48 type argument in constructor call 0x49 type argument in method call 0x4A type argument in constructor reference 0x4B type argument in method reference These distinctions seem irrelevant. You can tell whether an annotation relates to a constructor or method from where it appears in the class file, so it doesn't seem to be necessary to also encode this in target_type. Perhaps these distinctions were put in the JSR 308 spec because an earlier version of the lambda spec made these distinctions in its grammar (and possibly elsewhere). I propose that we eliminate this distinction, using only 3 instead of 6 target_type values and TargetType enum constants. I'd like to hear reactions from others (both on and off the Expert Group) before making this change, though. Thoughts? Thanks, -Mike From alex.buckley at oracle.com Wed Apr 17 10:25:08 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 17 Apr 2013 10:25:08 -0700 Subject: Clarifying the receiver parameter In-Reply-To: References: <516609B1.4060803@oracle.com> Message-ID: <516EDAF4.5010805@oracle.com> I presume you're asking about the qualified name of the receiver parameter of a method (not a ctor) _of a top-level class_? The answer is consistency. Since the receiver parameter intends to denote the receiver of the method, the receiver parameter's name should be textually equivalent to any 'this' expression which would denote the receiver of the method in the method body. An unqualified 'this' in the method body is the common case, but qualified 'this' expressions are also legal there. Would you ban a qualified 'this' expression like "p.C.this" because it's "always redundant"? Too late; the language already took the path of allowing both simple and qualified names to refer to the same entity. Alex On 4/16/2013 10:33 PM, Srikanth S Adayapalam wrote: > Alex, Could you please provide some rationale/justification for why a > fully-qualified name as qualifier of a the receiver parameter's "this" is > necessary ? > > The qualifier would always be redundant and is therefore best not allowed > obviating the need for a different grammar. The only situation where the > "this" parameter needs a qualifier > is in the constructor of an inner class. > > It is agreed that jsr308 spec in 2.1.5 is not entirely clear about the > correct usage of the receiver parameter's "this". It should specify the > allowed constructs, rather than just give an example. > > Srikanth > > type-annotations-spec-experts-bounces at openjdk.java.net wrote on 04/11/2013 > 06:24:09 AM: > >> From: Alex Buckley >> To: type-annotations-spec-experts > experts at openjdk.java.net>, >> Date: 04/11/2013 06:24 AM >> Subject: Clarifying the receiver parameter >> Sent by: type-annotations-spec-experts-bounces at openjdk.java.net >> >> There is some confusion around i) the type and ii) the name of the >> formal parameter which represents the receiver of an inner class's >> constructor or instance method. >> >> The current text is just "For a method, the receivers are named this, >> Outer.this, etc." and "Within an inner class constructor, the receiver >> has a name such as Outer.this". This doesn't help with the legality of >> the following receiver parameters, both of which should be legal: >> >> package p; >> class Outer { >> class Inner { >> Inner(p.Outer p.Outer.this) {} >> } >> } >> >> package p; >> class Outer { >> class Middle { >> class Inner { >> Inner(Outer.Middle Outer.Middle.this) {} >> } >> } >> } >> >> It needs to be stated that: "The receiver of a constructor or instance >> method of an inner class C, a direct inner class of O (8.1.3), is >> denoted by a formal parameter which appears first in the formal >> parameter list, and whose type is O, and whose name is a qualified this >> expression (15.8.4) which would, if used in the body of the constructor >> or instance method, refer to the immediately enclosing instance of the >> instance of C." >> >> By saying "whose type is O", we delegate to the normal process of >> resolving a type name. And by saying the name is that of a qualified >> this expression, we get the type resolution of the ClassName in a >> qualified this. >> >> Finally, we should apply the same technique for non-inner ctors/methods: >> >> "The receiver of a constructor or instance method of a top-level class C >> is denoted by a formal parameter which appears first in the formal >> parameter list, and whose type is C, and whose name is a this expression >> (15.8.3) or qualified this expression (15.8.4) which would, if used in >> the body of the constructor or instance method, refer to the instance of > C." >> >> which rightly allows: >> >> package p; >> class C { >> void m(p.C p.C.this) {} >> } >> >> (We need to allow a qualified this expression as the name because such >> an expression in the body can refer to _any_ lexically enclosing >> instance of C _including the zeroth lexically enclosing instance of C_ >> which is C itself.) >> >> Alex >> > From alex.buckley at oracle.com Wed Apr 17 11:32:07 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 17 Apr 2013 11:32:07 -0700 Subject: Fw: Constraining type annotations to occur just before type In-Reply-To: References: Message-ID: <516EEAA7.5020605@oracle.com> On 4/12/2013 3:27 AM, Srikanth S Adayapalam wrote: > ----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/12/2013 03:57 PM > ----- > > From: Markus Keller/Zurich/IBM at IBMCH > To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, > Date: 04/10/2013 09:31 PM > Subject: Re: Fw: Constraining type annotations to occur just before type > > >> I don't understand what this "client code" is. The only place where >> "semantics" is a valid concern is if code starts to use SE 8 API methods >> to read type annotations, since they will appear on the ground type >> (String) which may not have been the intended location (String[]) circa >> SE 7. > > With "client code", I mean Java 7 code that uses an annotation and some > compiler add-on that processes the annotation. E.g. the cited > @NonNull final String[] s3; > or even > @NonNull final java.lang.String s4; // legal ONLY for declaration > annot. > final java.lang. at NonNull String s5; // legal ONLY for type-use > annotations > > The @NonNull annotation has some semantics that are defined by the > annotation type and the compiler add-on. The @NonNull annotation is the > perfect candidate that wants to migrate to TYPE_USE in Java 8. > > My point is that there's no way @NonNull can be a declaration and a > type-use annotation at the same time, and both of these usages have the > same semantics. Yes, you can declare separate reflection APIs for > declaration and type-use annotations, but in the end, the compiler add-on > that implements the annotation's semantics needs to decide which one to > use. And it will show different behavior depending on the used API. It's safe to assume that the author of a type like NonNull always knew it "should" have applied to type uses. Unfortunately, it has only been possible to apply it to field declarations, so that's where code reads it from, via the SE 5.0-era core reflection API. It would not do to make those annotations disappear. Do you agree so far? So, we let the author of the NonNull type add TYPE_USE as a target. Code which uses the SE 5.0-era reflection API will see no difference when running on SE 8 or later. Do you believe this statement about older code to be accurate? Now suppose some annotation processing code is upgraded (or written from scratch) to employ the SE 8-era reflection methods which expose annotations on type uses. Then: 1. Where a field declaration involves a non-array type, the upgraded code has it easy: it can use the new methods to get annotations on the field's type and it will get the same @NonNull as before. 2. Where a field declaration involves an array type, the code will want to determine whether the @NonNull is "meant" to apply to the array type or to the array type's element type. If NonNull's target is just FIELD, it'll be the former; if NonNull's target includes TYPE_USE, it'll be the latter. The determination in 2 is required only because the author of the annotation type kept FIELD in the target list for the benefit of unknown amounts of code. It's no surprise that the author of an annotation type T makes choices which materially affect code which reflects over @T annotations. > The examples s4/s5 with the qualified name shows that it's not even > possible to use an @Target({ElementType.FIELD, ElementType.TYPE_USE}) > annotation in certain cases that were legal with @Target > ({ElementType.FIELD}) alone, since the two target kinds _require_ different > positions in the AST. Therefore, adding TYPE_USE is not a 100% > source-compatible change, even if you disregard the semantics of the > annotation. It's a 100% source-compatible change. Source compatibility means a construct which causes no compile-time error in source code circa Java SE n still causes no compile-time error in source code circa Java SE n+1. > The spec should not make it look like it's a valid transition path for an > existing declaration annotation type to add the TYPE_USE target. I would > even disallow this combination, since we haven't found a single use case > where it would make sense. > > TYPE_USE should only be used as the sole @Target. Providers of Java 7 > annotation types that want to migrate to TYPE_USE should make it clear that > this change is not for free for client code in all cases. That standpoint > also gives us the freedom to constrain TYPE_USE annotations to occur just > before the type. I disagree strongly with this position, and here's why. Annotations are about three kinds of person: - the provider of an annotation type (P) - the applier of annotations in normal code (W) - the creator of code to reflect over applied annotations (R) In general, if P's migration to TYPE_USE forces removal of other ElementType values from @Target, there will be code from W which no longer compiles. (TYPE_USE is reasonably a superset of TYPE and TYPE_PARAMETER, but not, say, METHOD.) Since there are probably 10,000 W's for every P, this is an unacceptable loss of source compatibility. I would rather let P migrate to TYPE_USE by adding it, which has no impact on any W or R person. As W's apply the annotation to type uses, a handful of R's will have to do some work to maintain behavioral compatibility. That's fine in my book. And quite separately: It's a simple fact that a rule to constrain type annotations to occur just before the type tells human readers of code almost nothing. Just by looking at this code, what do you learn about the targets of Foo and Bar: @Foo @Bar String s; Nothing. Foo and Bar could both target FIELD only, or both target TYPE_USE only, in addition to the possibility of Foo targeting FIELD only and Bar targeting TYPE_USE only. So the rule does not help any W person (of whom there are many) or anyone who reads W's code (of whom there are even more). Alex From alex.buckley at oracle.com Thu Apr 18 12:10:30 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 18 Apr 2013 12:10:30 -0700 Subject: JLS Creator production does not use 'Type' In-Reply-To: <5159E0D8.7060501@oracle.com> References: <511AEFD2.2030506@oracle.com> <20130331.113356.680248397878604207.mernst@cs.washington.edu> <5159E0D8.7060501@oracle.com> Message-ID: <51704526.8050409@oracle.com> Mike, please respond to the mail below. The Creator production is not the 308 spec from 4/1 and so annotations are not allowed after a 'new' keyword, period. Accordingly, the current discussion on jsr308-discuss at googlegroups.com is _wrong_ to assume the following is legal: Object o = new @A String[1]; Object o = new String @A[1]; Alex On 4/1/2013 12:32 PM, Alex Buckley wrote: > On 3/31/2013 11:33 AM, Michael Ernst wrote: >>> 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. > > When and where was the message sent which calls out Creator as not using > Type? I recall identifying that AnnotationTypeElementRest et al must use > UnannType rather than Type - but I cannot find mails about Creator, so I > am worried a production might be overlooked. > >> 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? > > The latter, please - 308 should add [Annotations] to Creator et al. The > former - adopting Type in Creator et al - would be tricky because of > diamond and partially-dimensioned array types. > > Alex From alex.buckley at oracle.com Thu Apr 18 12:13:59 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 18 Apr 2013 12:13:59 -0700 Subject: Proposed new schedule for Java SE 8 In-Reply-To: <20130418092814.294113@eggemoggin.niobe.net> References: <20130418092814.294113@eggemoggin.niobe.net> Message-ID: <517045F7.7000204@oracle.com> Experts, Please see the proposal below from Mark Reinhold. I expect JSR 308 will have its Public Review around the same time as the Public Review of the Java SE 8 JSR (337). Alex -------- Original Message -------- Subject: Proposed new schedule for Java SE 8 Date: Thu, 18 Apr 2013 09:28:14 -0700 From: mark.reinhold at oracle.com Reply-To: java-se-8-spec-observers at openjdk.java.net To: java-se-8-spec-experts at openjdk.java.net As I wrote earlier today on my blog [1], the Java 8 schedule is no longer achievable due to a renewed focus on security on the part of all of us here at Oracle. There are many options for how to proceed from here, some of which I discuss in the blog entry. As I've written previously [2], the most important work that's slipped is related to Project Lambda, the sole driving feature of the release. Our current estimate is that we can finish the remaining work on Lambda by early May, about three months later than planned. The other remaining features are not release drivers, so in theory we could just drop them from the release, but if Lambda needs more time then there's no point in doing that. With all that in mind, I think the least-bad option is to slip the schedule just enough to finish Lambda. Here, then, is a proposed new schedule for the Java SE 8 JSR: 2013/6 Early Draft Review 2013/10 Public Review 2013/12 Proposed Final Draft 2014/2 Final Release A Final Release in February of 2014 is, of course, more than three months later than the current goal of August. At this point we're not confident that we could be ready to release the Reference Implementation, JDK 8, in November, and experience has shown that it's almost always a bad idea to try to ship a major software release in December, so that pushes the release date well into the first quarter [3]. The intent here is not to open the gates for a flood of new features, nor to permit the scope of existing features to grow without bound. We'd likely propose a select few additional features, especially in areas related to security. In general, however, we'd use the additional time to stabilize, polish, and fine-tune the features that we already have rather than add a bunch of new ones. Is this the best possible course of action? I think it's better than the alternatives, but I'm open to suggestions. I'd like to hear from the rest of you by this time next week, please, so that we can settle on a new schedule. - Mark [1] http://mreinhold.org/blog/secure-the-train [2] http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-February/002066.html [3] http://openjdk.java.net/projects/jdk8/ From srikanth_sankaran at in.ibm.com Thu Apr 18 21:19:59 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Fri, 19 Apr 2013 09:49:59 +0530 Subject: Proposed new schedule for Java SE 8 In-Reply-To: <517045F7.7000204@oracle.com> References: <20130418092814.294113@eggemoggin.niobe.net> <517045F7.7000204@oracle.com> Message-ID: Just a note that the inline text mentions "2014/2 Final Release" while the schedule page http://openjdk.java.net/projects/jdk8/ mentions March 18th as the GA. Srikanth. type-annotations-spec-experts-bounces at openjdk.java.net wrote on 04/19/2013 12:43:59 AM: > From: Alex Buckley > To: type-annotations-spec-experts experts at openjdk.java.net>, > Date: 04/19/2013 12:43 AM > Subject: Proposed new schedule for Java SE 8 > Sent by: type-annotations-spec-experts-bounces at openjdk.java.net > > Experts, > > Please see the proposal below from Mark Reinhold. > > I expect JSR 308 will have its Public Review around the same time as the > Public Review of the Java SE 8 JSR (337). > > Alex > > -------- Original Message -------- > Subject: Proposed new schedule for Java SE 8 > Date: Thu, 18 Apr 2013 09:28:14 -0700 > From: mark.reinhold at oracle.com > Reply-To: java-se-8-spec-observers at openjdk.java.net > To: java-se-8-spec-experts at openjdk.java.net > > As I wrote earlier today on my blog [1], the Java 8 schedule is no > longer achievable due to a renewed focus on security on the part of > all of us here at Oracle. > > There are many options for how to proceed from here, some of which I > discuss in the blog entry. As I've written previously [2], the most > important work that's slipped is related to Project Lambda, the sole > driving feature of the release. Our current estimate is that we can > finish the remaining work on Lambda by early May, about three months > later than planned. The other remaining features are not release > drivers, so in theory we could just drop them from the release, but > if Lambda needs more time then there's no point in doing that. > > With all that in mind, I think the least-bad option is to slip the > schedule just enough to finish Lambda. > > Here, then, is a proposed new schedule for the Java SE 8 JSR: > > 2013/6 Early Draft Review > 2013/10 Public Review > 2013/12 Proposed Final Draft > 2014/2 Final Release > > A Final Release in February of 2014 is, of course, more than three > months later than the current goal of August. At this point we're not > confident that we could be ready to release the Reference Implementation, > JDK 8, in November, and experience has shown that it's almost always a > bad idea to try to ship a major software release in December, so that > pushes the release date well into the first quarter [3]. > > The intent here is not to open the gates for a flood of new features, > nor to permit the scope of existing features to grow without bound. > We'd likely propose a select few additional features, especially in > areas related to security. In general, however, we'd use the additional > time to stabilize, polish, and fine-tune the features that we already > have rather than add a bunch of new ones. > > Is this the best possible course of action? I think it's better than > the alternatives, but I'm open to suggestions. I'd like to hear from > the rest of you by this time next week, please, so that we can settle > on a new schedule. > > - Mark > > > [1] http://mreinhold.org/blog/secure-the-train > [2] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-February/002066.html > [3] http://openjdk.java.net/projects/jdk8/ > From alex.buckley at oracle.com Fri Apr 19 12:27:27 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 19 Apr 2013 12:27:27 -0700 Subject: Proposed new schedule for Java SE 8 In-Reply-To: References: <20130418092814.294113@eggemoggin.niobe.net> <517045F7.7000204@oracle.com> Message-ID: <51719A9F.5050800@oracle.com> The Final Release of an Umbrella JSR necessarily includes a Reference Implementation which for Java SE 8 will be a build of OpenJDK's "JDK 8" project. To allow for coordination between various parties, the Final Release occurs a touch earlier than the "General Availability" flag day of OpenJDK's "JDK 8" project. The above mirrors events in 2011 for the Final Release of the Umbrella JSR for Java SE 7 [1][2] versus the GA of OpenJDK's "JDK 7" project [3]. The above is independent of binary implementations of Java SE 8 from vendors like Oracle and IBM. Those implementations have their own "General Availability" dates which I expect will be close to the GA of OpenJDK's "JDK 8" project. Alex [1] http://www.jcp.org/en/jsr/detail?id=336 [2] https://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the [3] http://openjdk.java.net/projects/jdk7/ On 4/18/2013 9:19 PM, Srikanth S Adayapalam wrote: > Just a note that the inline text mentions "2014/2 Final Release" > while the schedule page http://openjdk.java.net/projects/jdk8/ mentions > March 18th as the GA. > > Srikanth. > > type-annotations-spec-experts-bounces at openjdk.java.net wrote on 04/19/2013 > 12:43:59 AM: > >> From: Alex Buckley >> To: type-annotations-spec-experts > experts at openjdk.java.net>, >> Date: 04/19/2013 12:43 AM >> Subject: Proposed new schedule for Java SE 8 >> Sent by: type-annotations-spec-experts-bounces at openjdk.java.net >> >> Experts, >> >> Please see the proposal below from Mark Reinhold. >> >> I expect JSR 308 will have its Public Review around the same time as the >> Public Review of the Java SE 8 JSR (337). >> >> Alex >> >> -------- Original Message -------- >> Subject: Proposed new schedule for Java SE 8 >> Date: Thu, 18 Apr 2013 09:28:14 -0700 >> From: mark.reinhold at oracle.com >> Reply-To: java-se-8-spec-observers at openjdk.java.net >> To: java-se-8-spec-experts at openjdk.java.net >> >> As I wrote earlier today on my blog [1], the Java 8 schedule is no >> longer achievable due to a renewed focus on security on the part of >> all of us here at Oracle. >> >> There are many options for how to proceed from here, some of which I >> discuss in the blog entry. As I've written previously [2], the most >> important work that's slipped is related to Project Lambda, the sole >> driving feature of the release. Our current estimate is that we can >> finish the remaining work on Lambda by early May, about three months >> later than planned. The other remaining features are not release >> drivers, so in theory we could just drop them from the release, but >> if Lambda needs more time then there's no point in doing that. >> >> With all that in mind, I think the least-bad option is to slip the >> schedule just enough to finish Lambda. >> >> Here, then, is a proposed new schedule for the Java SE 8 JSR: >> >> 2013/6 Early Draft Review >> 2013/10 Public Review >> 2013/12 Proposed Final Draft >> 2014/2 Final Release >> >> A Final Release in February of 2014 is, of course, more than three >> months later than the current goal of August. At this point we're not >> confident that we could be ready to release the Reference Implementation, >> JDK 8, in November, and experience has shown that it's almost always a >> bad idea to try to ship a major software release in December, so that >> pushes the release date well into the first quarter [3]. >> >> The intent here is not to open the gates for a flood of new features, >> nor to permit the scope of existing features to grow without bound. >> We'd likely propose a select few additional features, especially in >> areas related to security. In general, however, we'd use the additional >> time to stabilize, polish, and fine-tune the features that we already >> have rather than add a bunch of new ones. >> >> Is this the best possible course of action? I think it's better than >> the alternatives, but I'm open to suggestions. I'd like to hear from >> the rest of you by this time next week, please, so that we can settle >> on a new schedule. >> >> - Mark >> >> >> [1] http://mreinhold.org/blog/secure-the-train >> [2] >> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-February/002066.html >> [3] http://openjdk.java.net/projects/jdk8/ >> > From mernst at cs.washington.edu Sun Apr 21 17:04:56 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Sun, 21 Apr 2013 17:04:56 -0700 (PDT) Subject: Interaction between @Target meta-annotations and fully-qualified types Message-ID: <20130421.170456.2259447782227307993.mernst@cs.washington.edu> Dear Type Annotations experts, I recently added the following example to the JSR 308 (Type Annotations) specification, and thought that I would pass it along to ensure this is the anticipated behavior. Suppose you have these definitions: @Target({TYPE_USE}) @interface TAnno { } @Target({METHOD}) @interface MAnno { } @Target({METHOD, TYPE_USE}) @interface MTAnno { } @Target({FIELD}) @interface FAnno { } @Target({FIELD, TYPE_USE}) @interface FTAnno { } For each of the below examples, a comment states whether the syntax is legal or illegal. For each legal source-code annotation, the comment states how many annotations appear in the AST during annotation processing and in the classfile. @FAnno Object field4; // legal, one field annotation @TAnno Object field5; // legal, one type annotation @FTAnno Object field6; // legal, one field annotation and one type annotation @FAnno java.lang.Object field7; // legal, one field annotation @TAnno java.lang.Object field8; // illegal @FTAnno java.lang.Object field9; // legal, one field annotation java.lang. @FAnno Object field10; // illegal java.lang. @TAnno Object field11; // legal, one type annotation java.lang. @FTAnno Object field12 // legal, one type annotation @MAnno void myMethod1() { ... } // legal, one method annotation @TAnno void myMethod2() { ... } // illegal @MTAnno void myMethod3() { ... } // legal, one method annotation @MAnno Object myMethod4() { ... } // legal, one method annotation @TAnno Object myMethod5() { ... } // legal, one type annotation @MTAnno Object myMethod6() { ... } // legal, one method annotation and one type annotation @MAnno java.lang.Object myMethod7() { ... } // legal, one method annotation @TAnno java.lang.Object myMethod8() { ... } // illegal @MTAnno java.lang.Object myMethod9() { ... } // legal, one method annotation java.lang. @MAnno Object myMethod10() { ... } // illegal java.lang. @TAnno Object myMethod11() { ... } // legal, one type annotation java.lang. @MTAnno Object myMethod12() { ... } // legal, one type annotation -Mike From srikanth_sankaran at in.ibm.com Mon Apr 22 01:16:57 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Mon, 22 Apr 2013 13:46:57 +0530 Subject: Fw: Constraining type annotations to occur just before type Message-ID: Follow up comments from Markus Keller, IBM, Eclipse JDT/UI lead. Srikanth ----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/22/2013 01:46 PM ----- From: Markus Keller/Zurich/IBM at IBMCH To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, Date: 04/22/2013 01:13 AM Subject: Re: Constraining type annotations to occur just before type (Reply to Alex Buckley's mail from 4/17/2013) // Repeating the declarations under discussion: public @NonNull String s; @NonNull public String s2; @NonNull public String[] s3; @NonNull public java.lang.String s4; public java.lang. at NonNull String s5; // illegal before SE 8 Sorry, my "// legal ONLY for declaration/type-use annotation" comments were due to a misconception on my part. I saw compile errors from javac 1.8.0-ea-b83 and assumed those would be correct. But in fact, with an @NonNull with @Target({FIELD, TYPE_USE}), all these examples are error-free. s2, s3, and s4 would only be considered as FIELD annotations, whereas s5 would only be considered as TYPE_USE annotation. I agree with your statements about older code and SE 5.0-era core reflection API running on SE 8, and that it's a 100% source-compatible change for old processors. > 2. Where a field declaration involves an array type, the code will want > to determine whether the @NonNull is "meant" to apply to the array type > or to the array type's element type. If NonNull's target is just FIELD, > it'll be the former; if NonNull's target includes TYPE_USE, it'll be the > latter. And that last sentence is an incompatible change. The addition of TYPE_USE either changes the semantics of the annotation or forces annotation processors and users of the annotation to resort to very weird hacks to stay compatible. The problem is this declaration: public @NonNull String[] s6; For the SE 8 APIs, the @NonNull annotates "String". For the SE 5.0 APIs, it annotates the whole field s6 (but actually meant its type "String[]"). If we stipulate that the addition of TYPE_USE should be a compatible change, then this can only mean an SE 8 annotation processor must interpret the @NonNull as an annotation on "String[]". That's a very bad situation. Just because the annotation kept the FIELD target to stay compatible with old code, that means that even new code cannot use normal SE 8 semantics. To annotate "String", a user would have to use a trick like fully-qualifying the type name, so that the annotation loses its SE 5.0 meaning: public java.lang. at NonNull String[] s7; The superficially supported combination of TYPE_USE and declaration targets creates horrible corner cases for every user of such an annotation (even those who only started to use them with SE 8 or later). > I disagree strongly with this position, and here's why. Annotations are > about three kinds of person: > > - the provider of an annotation type (P) > - the applier of annotations in normal code (W) > - the creator of code to reflect over applied annotations (R) > > In general, if P's migration to TYPE_USE forces removal of other > ElementType values from @Target, there will be code from W which no > longer compiles. (TYPE_USE is reasonably a superset of TYPE and > TYPE_PARAMETER, but not, say, METHOD.) Since there are probably 10,000 > W's for every P, this is an unacceptable loss of source compatibility. I would agree about this analysis if SE 5.0 annotations would actually have been enough to create huge and valuable code bases that abuse declaration annotations as type-use annotations. But that's not the case. That's why we have this JSR to make type-use annotations useful in practice. I don't think old annotations that abused declaration targets and that never worked satisfactorily should drive SE 8 annotations. Disallowing mixed targets avoids a lot of confusion. IDEs can help with batch-fixing code that doesn't compile any more. > I would rather let P migrate to TYPE_USE by adding it, which has no > impact on any W or R person. As W's apply the annotation to type uses, a > handful of R's will have to do some work to maintain behavioral > compatibility. That's fine in my book. If the W's could transparently handle the problems, then I could agree. But unfortunately, they can't (see counterexample s6 above). > And quite separately: > > It's a simple fact that a rule to constrain type annotations to occur > just before the type tells human readers of code almost nothing. Just by > looking at this code, what do you learn about the targets of Foo and Bar: > > @Foo @Bar String s; > > Nothing. Foo and Bar could both target FIELD only, or both target > TYPE_USE only, in addition to the possibility of Foo targeting FIELD > only and Bar targeting TYPE_USE only. So the rule does not help any W > person (of whom there are many) or anyone who reads W's code (of whom > there are even more). If Foo and Bar have no meaning or if they are the only modifiers, that may be true. But in longer declarations, the language should help the human reader and writer to keep concepts together: @NonNull public static final @Deprecated String s; //hard to read public static final @NonNull @Deprecated String s; //still strange @Deprecated public static final @NonNull String s; //clear If you use an IDE that has an AST of this code, then you have various ways to get more information. E.g. in Eclipse, you could select the annotation or the field type and then use "Edit > Expand Selection To > Enclosing Element (Alt+Shift+Up)". This would select enclosing elements in the AST, so that you can immediately see whether the annotation belongs to the field type or to the whole declaration. Or there's the Mark Occurrences feature on method return types: Set the caret into the return type and you immediately see the whole return type and the method's exit points marked. Or a code formatter could put declaration annotations on separate lines but keep type-use annotations together with the type. All these features are only possible if the AST is regular and contains the type-use annotations where they belong. Markus From alex.buckley at oracle.com Mon Apr 22 12:33:40 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 22 Apr 2013 12:33:40 -0700 Subject: Interaction between @Target meta-annotations and fully-qualified types In-Reply-To: <20130421.170456.2259447782227307993.mernst@cs.washington.edu> References: <20130421.170456.2259447782227307993.mernst@cs.washington.edu> Message-ID: <51759094.7010906@oracle.com> Thanks Mike, this is a helpful piece of non-normative text for the JLS. Note that "AST" and "annotation processing" are not phrases which will ever appear in normative JLS text. I note that a method whose result is 'void' (and hence has no return type) cannot allow a solely-TYPE_USE annotation where a METHOD annotation previously stood. This is an argument against partitioning type annotations and declaration annotations. The code below shows it is necessary to add TYPE_USE to METHOD in the annotation type's declaration, assuming the annotation type is to be applied widely. @MAnno void myMethod1() { ... } // legal, one method annotation @TAnno void myMethod2() { ... } // illegal @MTAnno void myMethod3() { ... } // legal, one method annotation Alex On 4/21/2013 5:04 PM, Michael Ernst wrote: > Dear Type Annotations experts, > > I recently added the following example to the JSR 308 (Type > Annotations) specification, and thought that I would pass it along to > ensure this is the anticipated behavior. > > Suppose you have these definitions: > > @Target({TYPE_USE}) @interface TAnno { } > @Target({METHOD}) @interface MAnno { } > @Target({METHOD, TYPE_USE}) @interface MTAnno { } > @Target({FIELD}) @interface FAnno { } > @Target({FIELD, TYPE_USE}) @interface FTAnno { } > > For each of the below examples, a comment states whether the syntax is > legal or illegal. For each legal source-code annotation, the comment > states how many annotations appear in the AST during annotation > processing and in the classfile. > > @FAnno Object field4; // legal, one field annotation > @TAnno Object field5; // legal, one type annotation > @FTAnno Object field6; // legal, one field annotation and one type annotation > @FAnno java.lang.Object field7; // legal, one field annotation > @TAnno java.lang.Object field8; // illegal > @FTAnno java.lang.Object field9; // legal, one field annotation > java.lang. @FAnno Object field10; // illegal > java.lang. @TAnno Object field11; // legal, one type annotation > java.lang. @FTAnno Object field12 // legal, one type annotation > > @MAnno void myMethod1() { ... } // legal, one method annotation > @TAnno void myMethod2() { ... } // illegal > @MTAnno void myMethod3() { ... } // legal, one method annotation > @MAnno Object myMethod4() { ... } // legal, one method annotation > @TAnno Object myMethod5() { ... } // legal, one type annotation > @MTAnno Object myMethod6() { ... } // legal, one method annotation and one type annotation > @MAnno java.lang.Object myMethod7() { ... } // legal, one method annotation > @TAnno java.lang.Object myMethod8() { ... } // illegal > @MTAnno java.lang.Object myMethod9() { ... } // legal, one method annotation > java.lang. @MAnno Object myMethod10() { ... } // illegal > java.lang. @TAnno Object myMethod11() { ... } // legal, one type annotation > java.lang. @MTAnno Object myMethod12() { ... } // legal, one type annotation > > > -Mike > From mernst at cs.washington.edu Mon Apr 22 13:50:49 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Mon, 22 Apr 2013 13:50:49 -0700 (PDT) Subject: Interaction between @Target meta-annotations and fully-qualified types In-Reply-To: <51759094.7010906@oracle.com> References: <20130421.170456.2259447782227307993.mernst@cs.washington.edu> <51759094.7010906@oracle.com> Message-ID: <20130422.135049.2025304999772264097.mernst@cs.washington.edu> Alex- > I note that a method whose result is 'void' (and hence has no return type) > cannot allow a solely-TYPE_USE annotation where a METHOD annotation > previously stood. Right. This example already appeared in the specification, so it's not a change nor even a clarification. As we have previously discussed, you would never expect to change (say) a METHOD annotation to a FIELD annotation and write it in the same places, so we wouldn't expect to make other @Target changes either. > This is an argument against partitioning type annotations > and declaration annotations. I don't see this argument. The spec notes that it is bad style to have a single annotation that is both a type annotation and a declaration annotation. The only use that I can think of for such an annotation is if a programmer wishes to use two different tools, one of which operates on type annotations and the other of which operates on declaration annotations, and both of which expect the annotation to have exactly the same name. The spec notes that that is an unusual and temporary situation. The existence of this situation should not change style advice, much less change the way that annotations are conceptualized. (But, is this situation even what you are talking about? I am not sure about that.) > The code below shows it is necessary to add > TYPE_USE to METHOD in the annotation type's declaration, assuming the > annotation type is to be applied widely. > > @MAnno void myMethod1() { ... } // legal, one method annotation > @TAnno void myMethod2() { ... } // illegal > @MTAnno void myMethod3() { ... } // legal, one method annotation It isn't desirable (except in one specific and temporary situation) for an annotation type to be used both in type and declaration positions. Maybe that fact eliminates confusion and makes this discussion unnecessary. -Mike From alex.buckley at oracle.com Mon Apr 22 13:55:06 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 22 Apr 2013 13:55:06 -0700 Subject: Interaction between @Target meta-annotations and fully-qualified types In-Reply-To: <20130422.135049.2025304999772264097.mernst@cs.washington.edu> References: <20130421.170456.2259447782227307993.mernst@cs.washington.edu> <51759094.7010906@oracle.com> <20130422.135049.2025304999772264097.mernst@cs.washington.edu> Message-ID: <5175A3AA.10403@oracle.com> On 4/22/2013 1:50 PM, Michael Ernst wrote: >> I note that a method whose result is 'void' (and hence has no return >> type) >> cannot allow a solely-TYPE_USE annotation where a METHOD annotation >> previously stood. > > Right. This example already appeared in the specification, so it's not > a change nor even a clarification. As we have previously discussed, you > would never expect to change (say) a METHOD annotation to a FIELD > annotation and write it in the same places, so we wouldn't expect to > make other @Target changes either. > >> This is an argument against partitioning type annotations >> and declaration annotations. > > I don't see this argument. The spec notes that it is bad style to have > a single annotation that is both a type annotation and a declaration > annotation. I mean in terms of making it an error if an annotation type targets both TYPE_USE and a declaration location. We agree such an annotation type is unusual and temporary (which in Java time means "about five years") but we also agree it should be legal. Alex From alex.buckley at oracle.com Mon Apr 22 14:16:58 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 22 Apr 2013 14:16:58 -0700 Subject: Fw: Constraining type annotations to occur just before type In-Reply-To: References: Message-ID: <5175A8CA.3000009@oracle.com> On 4/22/2013 1:16 AM, Srikanth S Adayapalam wrote: > Follow up comments from Markus Keller, IBM, Eclipse JDT/UI lead. > > Srikanth > > ----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/22/2013 01:46 PM > ----- > > From: Markus Keller/Zurich/IBM at IBMCH > To: Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE, > Date: 04/22/2013 01:13 AM > Subject: Re: Constraining type annotations to occur just before type > > > (Reply to Alex Buckley's mail from 4/17/2013) > > // Repeating the declarations under discussion: > public @NonNull String s; > @NonNull public String s2; > @NonNull public String[] s3; > @NonNull public java.lang.String s4; > public java.lang. at NonNull String s5; // illegal before SE 8 > > Sorry, my "// legal ONLY for declaration/type-use annotation" comments were > due to a misconception on my part. I saw compile errors from javac > 1.8.0-ea-b83 and assumed those would be correct. But in fact, with an > @NonNull with @Target({FIELD, TYPE_USE}), all these examples are > error-free. s2, s3, and s4 would only be considered as FIELD annotations, > whereas s5 would only be considered as TYPE_USE annotation. > > I agree with your statements about older code and SE 5.0-era core > reflection API running on SE 8, and that it's a 100% source-compatible > change for old processors. > >> 2. Where a field declaration involves an array type, the code will want >> to determine whether the @NonNull is "meant" to apply to the array type >> or to the array type's element type. If NonNull's target is just FIELD, >> it'll be the former; if NonNull's target includes TYPE_USE, it'll be the >> latter. > > And that last sentence is an incompatible change. The addition of TYPE_USE > either changes the semantics of the annotation or forces annotation > processors and users of the annotation to resort to very weird hacks to > stay compatible. The last sentence is a _source compatible_ change for all Java source code, but not necessarily a _behavior compatible_ change for all annotation processors. That's OK: source compatibility is sacrosanct, behavioral compatibility of compiler plugins isn't. ("Sacrosanct? Then what about 'assert'?" - well, the engineers who decided it was acceptable to turn an identifier into a general keyword have moved on. The Java language team would not make that decision today.) > The problem is this declaration: > > public @NonNull String[] s6; > > For the SE 8 APIs, the @NonNull annotates "String". For the SE 5.0 APIs, it > annotates the whole field s6 (but actually meant its type "String[]"). If > we stipulate that the addition of TYPE_USE should be a compatible change, > then this can only mean an SE 8 annotation processor must interpret the > @NonNull as an annotation on "String[]". That's a very bad situation. It's not ideal, but the alternative of breaking source compatibility is worse. All a new SE 8 annotation processor (that is, a processor which uses the new SE 8 reflection methods) has to do - until such time as the annotation type's provider makes TYPE_USE the sole target - is detect that NonNull is a legacy annotation type and react accordingly. > Just > because the annotation kept the FIELD target to stay compatible with old > code, that means that even new code cannot use normal SE 8 semantics. Yes. The annotation type's provider may choose to remove FIELD from the annotation type's targets, but did not do so in this case. This flexibility is a feature, not a bug. At such time as the annotation type's provider makes TYPE_USE the sole target, new code will be able to use the new SE 8 reflection methods properly. > To > annotate "String", a user would have to use a trick like fully-qualifying > the type name, so that the annotation loses its SE 5.0 meaning: > > public java.lang. at NonNull String[] s7; > > The superficially supported combination of TYPE_USE and declaration targets > creates horrible corner cases for every user of such an annotation (even > those who only started to use them with SE 8 or later). No! Not for "every user" of an annotation. Be precise, please. It creates corner cases for the handful of people who write annotation processors. Everyone who applied the annotation is fine. Look, I don't necessarily think it's _good_ to add TYPE_USE to an existing annotation type's targets. It obviously obscures the semantics of the annotation type and complicates the lives of annotation processor creators. But the alternatives are worse. >> I disagree strongly with this position, and here's why. Annotations are >> about three kinds of person: >> >> - the provider of an annotation type (P) >> - the applier of annotations in normal code (W) >> - the creator of code to reflect over applied annotations (R) >> >> In general, if P's migration to TYPE_USE forces removal of other >> ElementType values from @Target, there will be code from W which no >> longer compiles. (TYPE_USE is reasonably a superset of TYPE and >> TYPE_PARAMETER, but not, say, METHOD.) Since there are probably 10,000 >> W's for every P, this is an unacceptable loss of source compatibility. > > I would agree about this analysis if SE 5.0 annotations would actually have > been enough to create huge and valuable code bases that abuse declaration > annotations as type-use annotations. But that's not the case. That's why we > have this JSR to make type-use annotations useful in practice. I don't > think old annotations that abused declaration targets and that never worked > satisfactorily should drive SE 8 annotations. Disallowing mixed targets > avoids a lot of confusion. IDEs can help with batch-fixing code that > doesn't compile any more. Job #0 for a language JSR is to not break existing code. Annotations were introduced in 2004 so there will be a decade's worth of source code which uses and abuses annotations by the time Java SE 8 is final. If a single program annotated by W prior to Java SE 8 is deemed illegal in the language circa Java SE 8, then this JSR will have failed. >> And quite separately: >> >> It's a simple fact that a rule to constrain type annotations to occur >> just before the type tells human readers of code almost nothing. Just by >> looking at this code, what do you learn about the targets of Foo and Bar: >> >> @Foo @Bar String s; >> >> Nothing. Foo and Bar could both target FIELD only, or both target >> TYPE_USE only, in addition to the possibility of Foo targeting FIELD >> only and Bar targeting TYPE_USE only. So the rule does not help any W >> person (of whom there are many) or anyone who reads W's code (of whom >> there are even more). > > If Foo and Bar have no meaning or if they are the only modifiers, that may > be true. But in longer declarations, the language should help the human > reader and writer to keep concepts together: > > @NonNull public static final @Deprecated String s; //hard to read > public static final @NonNull @Deprecated String s; //still strange > @Deprecated public static final @NonNull String s; //clear No, the language should not seek to organize different kinds of annotations. An annotation type like NonNull has semantics - specifically regarding inheritance, repeatability, and targetability - but an @NonNull annotation has no meaning in the language so the language should not prescribe whether it appears before or after 'public'. The JLS can certainly _recommend_ that type annotations appear in one place and declaration annotations appear somewhere else, but enforcement is a matter for tools. Alex From mernst at cs.washington.edu Mon Apr 22 15:21:44 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Mon, 22 Apr 2013 15:21:44 -0700 (PDT) Subject: Interaction between @Target meta-annotations and fully-qualified types In-Reply-To: <5175A3AA.10403@oracle.com> References: <51759094.7010906@oracle.com> <20130422.135049.2025304999772264097.mernst@cs.washington.edu> <5175A3AA.10403@oracle.com> Message-ID: <20130422.152144.255450671755199367.mernst@cs.washington.edu> Alex- > I mean in terms of making it an error if an annotation type targets both > TYPE_USE and a declaration location. We agree such an annotation type is > unusual and temporary (which in Java time means "about five years") but we > also agree it should be legal. I agree entirely. -Mike From srikanth_sankaran at in.ibm.com Tue Apr 23 22:18:22 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Wed, 24 Apr 2013 10:48:22 +0530 Subject: JLS Creator production does not use 'Type' In-Reply-To: <51704526.8050409@oracle.com> References: <511AEFD2.2030506@oracle.com> <20130331.113356.680248397878604207.mernst@cs.washington.edu> <5159E0D8.7060501@oracle.com> <51704526.8050409@oracle.com> Message-ID: > From: Alex Buckley > Subject: Re: JLS Creator production does not use 'Type' > > Mike, please respond to the mail below. The Creator production is not > the 308 spec from 4/1 and so annotations are not allowed after a 'new' > keyword, period. Accordingly, the current discussion on > jsr308-discuss at googlegroups.com is _wrong_ to assume the following is legal: > > Object o = new @A String[1]; > Object o = new String @A[1]; Hi Alex, This passage above makes for confusing reading for me. Could you please clarify: Are you saying the spec as it stands does not allow these and so asking Mike to fix the spec, or are you saying that the code snippet above is illegal ? TIA, Srikanth From alex.buckley at oracle.com Wed Apr 24 10:05:25 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 24 Apr 2013 10:05:25 -0700 Subject: JLS Creator production does not use 'Type' In-Reply-To: References: <511AEFD2.2030506@oracle.com> <20130331.113356.680248397878604207.mernst@cs.washington.edu> <5159E0D8.7060501@oracle.com> <51704526.8050409@oracle.com> Message-ID: <517810D5.40801@oracle.com> On 4/23/2013 10:18 PM, Srikanth S Adayapalam wrote: >> From: Alex Buckley >> Subject: Re: JLS Creator production does not use 'Type' >> >> Mike, please respond to the mail below. The Creator production is not >> the 308 spec from 4/1 and so annotations are not allowed after a 'new' >> keyword, period. Accordingly, the current discussion on >> jsr308-discuss at googlegroups.com is _wrong_ to assume the following is > legal: >> >> Object o = new @A String[1]; >> Object o = new String @A[1]; > > Hi Alex, > > This passage above makes for confusing reading for me. Could you please > clarify: Are you saying the spec as it stands does not allow these and > so asking Mike to fix the spec, or are you saying that the code snippet > above is illegal ? The former. The Creator production does not use Type so is unaffected by the modification of Type in JSR 308 2.2 to allow annotations. This obviously needs addressing in 2.2. Alex From alex.buckley at oracle.com Fri Apr 26 14:12:58 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 26 Apr 2013 14:12:58 -0700 Subject: Proposed new schedule for Java SE 8 In-Reply-To: <517045F7.7000204@oracle.com> References: <20130418092814.294113@eggemoggin.niobe.net> <517045F7.7000204@oracle.com> Message-ID: <517AEDDA.7090701@oracle.com> The proposed schedule for Java SE 8 was adopted today: > -------- Original Message -------- > Subject: Re: Proposed new schedule for Java SE 8 > Date: Fri, 26 Apr 2013 09:48:26 -0700 > From: mark.reinhold at oracle.com > Reply-To: java-se-8-spec-observers at openjdk.java.net > To: java-se-8-spec-experts at openjdk.java.net > > 2013/4/18 2:28 -0700, mark.reinhold at oracle.com: >> ... >> >> With all that in mind, I think the least-bad option is to slip the >> schedule just enough to finish Lambda. >> >> Here, then, is a proposed new schedule for the Java SE 8 JSR: >> >> 2013/6 Early Draft Review >> 2013/10 Public Review >> 2013/12 Proposed Final Draft >> 2014/2 Final Release >> >> ... >> >> Is this the best possible course of action? I think it's better than >> the alternatives, but I'm open to suggestions. I'd like to hear from >> the rest of you by this time next week, please, so that we can settle >> on a new schedule. > > I've seen no objections from EG members. Reasonably broad community > support for this change has been expressed in comments on my blog entry, > on Twitter, and elsewhere. The above schedule is, therefore, now the > plan of record. > > I've updated our primary web page [1] accordingly. > > - Mark > > > [1] http://openjdk.java.net/projects/jdk8/spec/