From mernst at cs.washington.edu Thu Jan 3 15:25:07 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 03 Jan 2013 15:25:07 -0800 (PST) Subject: [type-annos-observers] Type annotations for method/ctor reference expressions In-Reply-To: <50C7CB69.7050303@oracle.com> References: <50C7CB69.7050303@oracle.com> Message-ID: <20130103.152507.458809141732201204.mernst@cs.washington.edu> Alex and Expert Group, > The following productions occur in the latest spec for JSR 335 "Lambda > expressions" (v0.6 - I will send a URL to a suitably-licensed file > tomorrow): > > MethodReference: > ExpressionName '::' NonWildTypeArgumentsopt Identifier > Primary '::' NonWildTypeArgumentsopt Identifier > 'super' '::' NonWildTypeArgumentsopt Identifier > TypeName '.' 'super' '::' NonWildTypeArgumentsopt Identifier > ReferenceType '::' NonWildTypeArgumentsopt Identifier > > ConstructorReference: > ClassType '::' NonWildTypeArgumentsopt 'new' > ArrayType '::' 'new' > > Some implications for JSR 308: > > 1. The NonWildTypeArguments term in MethodReference and > ConstructorReference means that type arguments in method/ctor reference > expressions are annotatable in source according to the current JSR 308 > grammar. (NonWildTypeArguments depends on ReferenceType, which the 308 > grammar makes annotatable.) For the class file, we have a target_type > constant for method references, but there should be a separate constant for > ctor references. Right. > 2. The ReferenceType term in MethodReference means that a type use there is > annotatable in source. For the class file, a new target_type constant is > needed. Right. I will add this. > 3. The TypeName term in MethodReference should probably be annotatable in > source. Come to think of it, what about annotating the TypeName in > T.super.f (JLS 15.11.2)? Has JSR 308 missed this location all along? This is not a use of a type; rather, it is a scoping mechanism. Therefore, it is not a target for a type annotation. > 4. The ClassType and ArrayType terms in ConstructorReference ought to be > annotatable in source, but the JSR 308 grammar needs to be extended to > allow this. Then new target_type constants are needed. It would be nicer, from our point of view, for the production to be made: ConstructorReference: ReferenceType '::' NonWildTypeArgumentsopt 'new' and it cleans up the grammar as well, avoiding the direct use of the low-level productions ClassType and ArrayType. Alex will suggest this change to the JSR 335 expert group. -Mike From alex.buckley at oracle.com Fri Jan 4 13:54:19 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 04 Jan 2013 13:54:19 -0800 Subject: [type-annos-observers] Grammar of ConstructorReference In-Reply-To: References: <50E618F2.4090704@oracle.com> Message-ID: <50E74F8B.5030501@oracle.com> Dan, thanks for responding. Yes, one of the many tasks in integrating JSRs into JLS8 will be to thread 335's productions into ch.18 and 308's productions into chs.2-15. Alex On 1/4/2013 1:46 PM, Dan Smith wrote: > I have conveniently avoided Chapter 18 (because it requires a global expertise in the Ch. 18 grammar and its invariants, which I do not have). We can keep this in mind when we get around to it... > > ?Dan > > On Jan 3, 2013, at 4:49 PM, Alex Buckley wrote: > >> The grammar of ConstructorReference is: >> >> ConstructorReference: >> ClassType '::' NonWildTypeArgumentsopt 'new' >> ArrayType '::' 'new' >> >> The class or array type which appears before the '::' is a first-class type use on which JSR 308 would like to allow annotations. JSR 308 usually catches type uses by redefining ReferenceType in JLS ch.18 from: >> >> ReferenceType: >> Identifier [TypeArguments] { . Identifier [TypeArguments] } >> >> to: >> >> ReferenceType: >> [Annotations] UnannReferenceType >> >> UnannReferenceType: >> Identifier [TypeArguments] {. [Annotations] Identifier [TypeArguments]} >> >> My question to the 335 EG then is, what is the ch.18 version of ConstructorReference? If it uses ReferenceType, 308 is good to go. >> >> Alex > From alex.buckley at oracle.com Tue Jan 15 12:02:56 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Jan 2013 12:02:56 -0800 Subject: [type-annos-observers] FYI: Java SE 8 schedule Message-ID: <50F5B5F0.5010807@oracle.com> Experts, I draw your attention to recent posts on the Expert Group mailing list for the SE 8 Umbrella JSR: - An updated JCP schedule for the SE 8 Umbrella JSR: http://mail.openjdk.java.net/pipermail/java-se-8-spec-experts/2013-January/000023.html - A preview of the Early Draft Review for the SE 8 Umbrella JSR: http://mail.openjdk.java.net/pipermail/java-se-8-spec-experts/2013-January/000022.html The impact on JSR 308 is that our Public Review will occur no later than May 2013, and probably at the same time as the SE 8 Umbrella JSR Public Review. (Stay tuned.) Alex From mernst at cs.washington.edu Wed Jan 23 21:59:55 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Wed, 23 Jan 2013 21:59:55 -0800 (PST) Subject: [type-annos-observers] Type annotations (JSR 308) specification draft Message-ID: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Here is the latest draft of the Type annotations (JSR 308) specification. I've attached it in PDF and HTML, and attached the changelog in HTML. Many thanks to Alex and Werner for their numerous comments and contributions. Further comments are always welcome! -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: design.pdf Type: application/pdf Size: 202640 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/attachments/20130123/efa52b9f/design-0001.pdf From srikanth_sankaran at in.ibm.com Wed Jan 23 23:29:03 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Thu, 24 Jan 2013 12:59:03 +0530 Subject: [type-annos-observers] Type annotations (JSR 308) specification draft In-Reply-To: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Message-ID: JLS8 8.4 states: For compatibility with older versions of the Java SE platform, the declaration of a method that returns an array is allowed to place (some or all of) the empty bracket pairs that form the declaration of the array type after the formal parameter list. This is supported by the following obsolescent production, but should not be used in new code. --------------- Given that it could be argued that it does not make sense to allow for annotations to be specified in the extra dimensions. Can we simply get rid of the changes in the grammar for MethodDeclaratorRest and InterfaceMethodDeclaratorRest ? Is there a compelling reason to support a discouraged construct ? It would simplify our implementation a bit if we don't have to. Thanks! Srikanth From mernst at cs.washington.edu Thu Jan 24 11:08:37 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 24 Jan 2013 11:08:37 -0800 (PST) Subject: [type-annos-observers] Type annotations (JSR 308) specification draft In-Reply-To: References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Message-ID: <20130124.110837.1774415814928811675.mernst@cs.washington.edu> Srikanth- My first reaction is that it would surprise programmers for type annotations to be permitted in some locations that are legal Java but forbidden in other locations that are legal Java. Furthermore, a programmer may want to add type annotations to a legacy Java program without being forced to rewrite the Java program. The programmer may not wish to rewrite the program simply because any rewriting, however minor, carries a risk of error. If the JLS required a Java compiler to issue a warning for the obsolescent usage, then that would encourage programmers to rewrite their code and I would be more in favor of not supporting type annotations there. I'd like to hear others' opinions as well. -Mike > Subject: Re: Type annotations (JSR 308) specification draft > From: Srikanth S Adayapalam > To: Michael Ernst > Date: Thu, 24 Jan 2013 12:59:03 +0530 > > JLS8 8.4 states: > > For compatibility with older versions of the Java SE platform, the declaration of > a > method that returns an array is allowed to place (some or all of) the empty > bracket > pairs that form the declaration of the array type after the formal parameter > list. This > is supported by the following obsolescent production, but should not be used in > new code. > > --------------- > > Given that it could be argued that it does not make sense to allow for > annotations to > be specified in the extra dimensions. Can we simply get rid of the changes in the > grammar for MethodDeclaratorRest and InterfaceMethodDeclaratorRest ? > > Is there a compelling reason to support a discouraged construct ? It would > simplify > our implementation a bit if we don't have to. > > Thanks! > Srikanth From alex.buckley at oracle.com Thu Jan 24 11:50:11 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 24 Jan 2013 11:50:11 -0800 Subject: [type-annos-observers] Type annotations (JSR 308) specification draft In-Reply-To: <20130124.110837.1774415814928811675.mernst@cs.washington.edu> References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> <20130124.110837.1774415814928811675.mernst@cs.washington.edu> Message-ID: <51019073.4090207@oracle.com> On the one hand, post-parameter [] is "obsolescent" and shouldn't be encouraged by supporting it in new language features. It's not hard to move the [] which are part of the return type to their proper syntactic location if you want to annotate them. On the other hand, post-parameter [] is legal and causes no standard compile-time warning. Weasel words in the JLS about "should not be used" can be ignored without penalty, so I assume someone does ignore them. Bottom line, it's a first-class language feature in Java SE 7, and it's not on the table for removal in Java SE 8, so if Mike wants to let it be annotated (to avoid rewriting legacy code), that's fine with me. Alex On 1/24/2013 11:08 AM, Michael Ernst wrote: > Srikanth- > > My first reaction is that it would surprise programmers for type > annotations to be permitted in some locations that are legal Java but > forbidden in other locations that are legal Java. Furthermore, a > programmer may want to add type annotations to a legacy Java program > without being forced to rewrite the Java program. The programmer may not > wish to rewrite the program simply because any rewriting, however minor, > carries a risk of error. > > If the JLS required a Java compiler to issue a warning for the obsolescent > usage, then that would encourage programmers to rewrite their code and I > would be more in favor of not supporting type annotations there. > > I'd like to hear others' opinions as well. > > -Mike > > >> Subject: Re: Type annotations (JSR 308) specification draft >> From: Srikanth S Adayapalam >> To: Michael Ernst >> Date: Thu, 24 Jan 2013 12:59:03 +0530 >> >> JLS8 8.4 states: >> >> For compatibility with older versions of the Java SE platform, the declaration of >> a >> method that returns an array is allowed to place (some or all of) the empty >> bracket >> pairs that form the declaration of the array type after the formal parameter >> list. This >> is supported by the following obsolescent production, but should not be used in >> new code. >> >> --------------- >> >> Given that it could be argued that it does not make sense to allow for >> annotations to >> be specified in the extra dimensions. Can we simply get rid of the changes in the >> grammar for MethodDeclaratorRest and InterfaceMethodDeclaratorRest ? >> >> Is there a compelling reason to support a discouraged construct ? It would >> simplify >> our implementation a bit if we don't have to. >> >> Thanks! >> Srikanth From joel.franck at oracle.com Fri Jan 25 06:44:14 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 25 Jan 2013 15:44:14 +0100 Subject: [type-annos-observers] Type annotations (JSR 308) specification draft In-Reply-To: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Message-ID: Hi Mike, I think an error crept into the spec while renumbering the target_infos, in figure 1 on page 12: Cast is now 0x48 and there is a gap where cast used to be (0x43). Or is this intended? cheers /Joel On Jan 24, 2013, at 6:59 AM, Michael Ernst wrote: > Here is the latest draft of the Type annotations (JSR 308) specification. > I've attached it in PDF and HTML, and attached the changelog in HTML. Many > thanks to Alex and Werner for their numerous comments and contributions. > Further comments are always welcome! > > -Mike > > From mernst at cs.washington.edu Fri Jan 25 07:48:34 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Fri, 25 Jan 2013 07:48:34 -0800 (PST) Subject: [type-annos-observers] Type annotations (JSR 308) specification draft In-Reply-To: References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Message-ID: <20130125.074834.1682493064786441108.mernst@cs.washington.edu> > I think an error crept into the spec while renumbering the target_infos, in figure 1 on page 12: > > Cast is now 0x48 and there is a gap where cast used to be (0x43). Joel is entirely correct. Thanks for noticing this! I have renumbered to remove the gap. -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: design.pdf Type: application/pdf Size: 204541 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/attachments/20130125/ca0ea528/design-0001.pdf From ebruneton at free.fr Sat Jan 26 09:37:17 2013 From: ebruneton at free.fr (Eric Bruneton) Date: Sat, 26 Jan 2013 18:37:17 +0100 Subject: [type-annos-observers] Type annotations (JSR 308) specification draft In-Reply-To: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Message-ID: <5104144D.90104@free.fr> 24/01/2013 06:59, Michael Ernst wrote: > Here is the latest draft of the Type annotations (JSR 308) specification. > I've attached it in PDF and HTML, and attached the changelog in HTML. Many > thanks to Alex and Werner for their numerous comments and contributions. > Further comments are always welcome! > > -Mike > Thanks! I found a typo in p 10: "Annotations that target instructions are those in Figure 1 with target type >= 0x86;" 0x86 should be 0x40 Eric From mernst at cs.washington.edu Sat Jan 26 09:52:15 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Sat, 26 Jan 2013 09:52:15 -0800 (PST) Subject: [type-annos-observers] Type annotations (JSR 308) specification draft In-Reply-To: <5104144D.90104@free.fr> References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> <5104144D.90104@free.fr> Message-ID: <20130126.095215.2229729536374745455.mernst@cs.washington.edu> Eric Bruneton found a typo in the JSR 308 spec: > I found a typo in p 10: "Annotations that target instructions are > those in Figure 1 with target type >= 0x86;" 0x86 should be 0x40 Thanks, Eric, for noticing my error! I have corrected it. -Mike From srikanth_sankaran at in.ibm.com Mon Jan 28 19:58:48 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 29 Jan 2013 09:28:48 +0530 Subject: [type-annos-observers] Annotations on extended dimension in method declarations. In-Reply-To: References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Message-ID: Mike, Here is the response from Markus Keller - JDT/UI lead on Eclipse. We would once again request the EG to consider this request. ----- Mike, I agree that there is a possibility that someone has to annotate code that uses extended dimensions in a method declaration. But the notation is already very little used (I haven't ever seen it in my life), and the chance that someone annotates code that still makes use of it is even smaller. The transition path is as simple as a copy-paste. The extended dimensions notation has no practical value. It only causes confusion. On the other hand, every unnecessary language construct adds bloat to the language and makes it harder to use for everyone (readers, writers, tool implementers). The audience that is negatively affected by this addition is by magnitudes bigger than the small group of users who have to perform a simple copy-paste. Note that I'm not asking to deprecate or even remove an existing language feature. I'm just asking to not add bloat for a language feature that has been acknowledged to have been a bad idea in the first place. The first version of the JLS already says explicitly that this form should not be used. Let's apply good engineering principles and keep Java as simple as possible. Thank you, Markus Keller From mernst at cs.washington.edu Tue Jan 29 21:14:12 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 29 Jan 2013 21:14:12 -0800 (PST) Subject: [type-annos-observers] Annotations on extended dimension in method declarations. In-Reply-To: References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> Message-ID: <20130129.211412.876131102415925126.mernst@cs.washington.edu> Srikanth- Do you propose to forbid type annotations on arrays only in the method declaration syntax? Or do you also propose to forbid them in the variable declaration syntax when they follow the identifier? Your email mentioned MethodDeclaratorRest and InterfaceMethodDeclaratorRest but not VariableDeclaratorRest, ConstantDeclaratorRest, or VariableDeclaratorId. Thanks, -Mike From srikanth_sankaran at in.ibm.com Tue Jan 29 21:25:37 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Wed, 30 Jan 2013 10:55:37 +0530 Subject: [type-annos-observers] Annotations on extended dimension in method declarations. In-Reply-To: <20130129.211412.876131102415925126.mernst@cs.washington.edu> References: <20130123.215955.1146629385599322907.mernst@cs.washington.edu> <20130129.211412.876131102415925126.mernst@cs.washington.edu> Message-ID: No, only in method declaration syntax. In other places, the extended dimensions *do* play a useful role, in enabling declaration of multiple variables in the same line, with the different variables having different types. int x, y[]; // x is an integer, while y is an int [] In the case of method declaration, the extra dimensions have no useful role to play are just a lingering nuisance. Srikanth. Michael Ernst wrote on 01/30/2013 10:44:12 AM: > From: Michael Ernst > To: Srikanth S Adayapalam/India/IBM at IBMIN, > Cc: type-annotations-spec-experts experts at openjdk.java.net> > Date: 01/30/2013 10:43 AM > Subject: Re: Annotations on extended dimension in method declarations. > > Srikanth- > > Do you propose to forbid type annotations on arrays only in the method > declaration syntax? Or do you also propose to forbid them in the variable > declaration syntax when they follow the identifier? Your email mentioned > MethodDeclaratorRest and InterfaceMethodDeclaratorRest but not > VariableDeclaratorRest, ConstantDeclaratorRest, or VariableDeclaratorId. > > Thanks, > > -Mike > From mernst at cs.washington.edu Tue Jan 29 21:55:23 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 29 Jan 2013 21:55:23 -0800 (PST) Subject: [type-annos-observers] Annotations on extended dimension in method declarations. In-Reply-To: References: <20130129.211412.876131102415925126.mernst@cs.washington.edu> Message-ID: <20130129.215523.547368669741390612.mernst@cs.washington.edu> Srikanth- Thanks for the clarification; I appreciate it. I expect that the method syntax was included specifically for consistency with the variable syntax, and so it seems unclean to me to support type annotations in one place but not in another that was designed to mimic the first one. I hate to provide grist for another Java Puzzlers book. I don't think this change would make the specification shorter, because we would have to add a paragraph explaining why we are treating some array brackets differently than other array brackets. This will sound like an ugly wart that clutters the spec and requires an apology, rather than keeping the language clean. With regard to the argument from implementation convenience: The JSR 308 reference implementation uses a single grammar production to parse array brackets (and the type annotations that precede them) wherever they appear. Thus, that implementation would require changes to make it parse different array brackets in different ways. This seems to counterbalance the benefit of reducing Eclipse implementation burden. This is why I am not in favor of this change that introduces a special case into the Java grammar. -Mike