From alex.buckley at oracle.com Tue Dec 11 16:10:17 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 11 Dec 2012 16:10:17 -0800 Subject: Type annotations for method/ctor reference expressions Message-ID: <50C7CB69.7050303@oracle.com> 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. 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. 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? 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. Alex From alex.buckley at oracle.com Wed Dec 12 10:31:32 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 12 Dec 2012 10:31:32 -0800 Subject: Declaration annotations on lambda formal parameters Message-ID: <50C8CD84.4020603@oracle.com> I recently wrote to the JSR 335 (Lambda) Expert Group, asking if there was any interest in declaration annotations on a lambda expression's formal parameter: http://mail.openjdk.java.net/pipermail/lambda-spec-comments/2012-December/000003.html After some discussion with the 335 spec lead, the answer is "no", declaration annotations are not needed on lambda parameters. Consequently, we simply need to support the various locations for type annotations that I outlined in the mail "Type annotations for method/ctor reference expressions". Alex From alex.buckley at oracle.com Wed Dec 12 17:40:59 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 12 Dec 2012 17:40:59 -0800 Subject: Type annotations for method/ctor reference expressions In-Reply-To: <50C7CB69.7050303@oracle.com> References: <50C7CB69.7050303@oracle.com> Message-ID: <50C9322B.4060508@oracle.com> FYI, v0.6 of the JSR 335 spec is at: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.0/ and the grammar for method/ctor reference expressions is at: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.0/C.html#C15.28 Alex On 12/11/2012 4:10 PM, Alex Buckley wrote: > 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. > > 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. > > 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? > > 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. > > Alex From mernst at cs.washington.edu Sat Dec 22 21:12:06 2012 From: mernst at cs.washington.edu (Michael Ernst) Date: Sat, 22 Dec 2012 21:12:06 -0800 (PST) Subject: Latest JSR 308 specification draft Message-ID: <20121222.211206.1482372376121208558.mernst@cs.washington.edu> Here is a draft of the JSR 308 specification that includes the classfile changes (notably for representation of compound types). Comments are, as always, welcome. -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: design.pdf Type: application/pdf Size: 216782 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/attachments/20121222/6f206c73/design-0001.pdf From mernst at cs.washington.edu Sat Dec 22 21:13:48 2012 From: mernst at cs.washington.edu (Michael Ernst) Date: Sat, 22 Dec 2012 21:13:48 -0800 (PST) Subject: u1 vs. u2 in JSR 308 classfile format Message-ID: <20121222.211348.2133278435368047982.mernst@cs.washington.edu> The JSR 308 class file format contains what seems like a rather haphazard choices between u1 and u2, for values that we expect to be small as a rule: type_parameter_target { u1 type_parameter_index; }; supertype_target { u2 supertype_index; }; type_parameter_bound_target { u1 type_parameter_index; u1 bound_index; }; method_parameter_target { u1 method_parameter_index; }; throws_target { u2 throws_type_index; }; (By contrast, it's good to use u2 for indices into code, exception tables, etc.) Should all of these be made u1? This is a rather minor issue either way. -Mike From alex.buckley at oracle.com Wed Dec 26 11:22:53 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 26 Dec 2012 11:22:53 -0800 Subject: u1 vs. u2 in JSR 308 classfile format In-Reply-To: <20121222.211348.2133278435368047982.mernst@cs.washington.edu> References: <20121222.211348.2133278435368047982.mernst@cs.washington.edu> Message-ID: <50DB4E8D.4080502@oracle.com> There is some subtlety here. Please confirm the following is acceptable: u1: - In the Java language and in the Signature attribute, generic class and method declarations are not limited to 255 type parameters, nor are parameterized class and method invocations limited to 255 type arguments. However, 255 type parameters ought to be enough for a generic type, just like 255 dimensions are enough for an array type. So, I have no problem with u1 for type_parameter_index and bound_index. (This is consistent with type_path_entry.type_argument_index being a u1. Speaking of compound types, a u1 for type_path.path_length is fine - John Rose said earlier that type expression trees are never so deep as to require a u2 length field.) - In a method descriptor, the number of formal parameters is limited to 255, so u1 is appropriate for method_parameter_index. u2: - In ClassFile, the number of supertypes is a u2, so u2 is appropriate for supertype_index. - In the Exceptions attribute, the number of exceptions is a u2, so u2 is appropriate for throws_type_index. Alex On 12/22/2012 9:13 PM, Michael Ernst wrote: > The JSR 308 class file format contains what seems like a rather haphazard > choices between u1 and u2, for values that we expect to be small as a rule: > > type_parameter_target { > u1 type_parameter_index; > }; > > supertype_target { > u2 supertype_index; > }; > > type_parameter_bound_target { > u1 type_parameter_index; > u1 bound_index; > }; > > method_parameter_target { > u1 method_parameter_index; > }; > > throws_target { > u2 throws_type_index; > }; > > (By contrast, it's good to use u2 for indices into code, exception tables, > etc.) > > Should all of these be made u1? This is a rather minor issue either way. > > -Mike > From alex.buckley at oracle.com Wed Dec 26 11:34:27 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 26 Dec 2012 11:34:27 -0800 Subject: Latest JSR 308 specification draft In-Reply-To: <20121222.211206.1482372376121208558.mernst@cs.washington.edu> References: <20121222.211206.1482372376121208558.mernst@cs.washington.edu> Message-ID: <50DB5143.9040008@oracle.com> Thanks Mike. Could you please indicate: - When target_type constants will be renumbered to be consecutive? - When target_type constants and target_info structures will be defined for the numerous new locations coming from Lambda? The latter locations are non-trivial - lambda formal parameters are the least of our worries. I outlined the locations in my 12/11/12 mail "Type annotations for method/ctor reference expressions". Alex On 12/22/2012 9:12 PM, Michael Ernst wrote: > Here is a draft of the JSR 308 specification that includes the classfile > changes (notably for representation of compound types). Comments are, as > always, welcome. > > -Mike >