From markus_keller at ch.ibm.com Mon Mar 3 08:29:42 2014 From: markus_keller at ch.ibm.com (Markus Keller) Date: Mon, 3 Mar 2014 17:29:42 +0100 Subject: [type-annos-observers] ordering of annotated array brackets Message-ID: JLS8 10.2 says: "In a variable declaration (?8.3, ?8.4.1, ?9.3, ?14.14, ?14.20) except for a variable arity parameter, the array type of a variable is denoted by the array type that appears at the beginning of the declaration, followed by any bracket pairs that follow the variable's Identifier in the declarator." This was fine for Java < 8, where array dimension brackets were indistinguishable. But with type annotations, the order of annotated dimension brackets matters. Example: private @A int @B [] field @C []; In "1.8.0-b129", reflection says the type of "field" is "@A int @C [] @B []", and that totally makes sense. See also [1]. The paragraph should e.g. say: "[..] the array type of a variable is denoted by the element type at the beginning of the declaration, followed by any (potentially annotated) bracket pairs that follow the variable's Identifier in the declarator, followed by any (potentially annotated) bracket pairs of the array type at the beginning of the declaration." The ordering of consecutive array dimension brackets is currently also undefined by the spec. There's just an informal example in 9.7.4 (which is good; it's just not a spec). Regards, Markus [1] Executable snippet to test reflection: import java.lang.annotation.*; import java.lang.reflect.*; import java.util.stream.*; @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface A {} @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface B {} @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) @interface C {} public class Snippet { private @A int @B [] field @C []; private @A int @C [] @B [] fieldNormal; private @A int @B [] fieldBase, fieldExtra @C []; public static void main(String[] args) throws Exception { printField("field"); printField("fieldNormal"); printField("fieldBase"); printField("fieldExtra"); } private static void printField(String name) throws NoSuchFieldException { System.out.printf("%-12s %s\n", name + ":", toString(Snippet.class.getDeclaredField(name).getAnnotatedType())); } private static String toString(AnnotatedType annotatedType) { StringBuilder sb = new StringBuilder(); while (annotatedType instanceof AnnotatedArrayType) { sb.append(" ").append(toString(annotatedType.getAnnotations())).append("[]"); annotatedType = ((AnnotatedArrayType) annotatedType).getAnnotatedGenericComponentType(); } Type type = annotatedType.getType(); sb.insert(0, type.toString()); sb.insert(0, toString(annotatedType.getAnnotations())); return sb.toString(); } private static String toString(Annotation[] annotations) { return Stream.of(annotations).map(Snippet::toSimpleString). collect(Collectors.joining(" ", "", " ")); } public static String toSimpleString(Annotation a) { return "@" + a.annotationType().getSimpleName(); } } From alex.buckley at oracle.com Mon Mar 3 11:51:44 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 03 Mar 2014 11:51:44 -0800 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: References: Message-ID: <5314DD50.4070100@oracle.com> Hi Markus, Thanks for your mail and excellent test case. However, I don't see why the post-identifier "@C []" should be the outermost dimension, as if "int @C [] @B []" had been written. Certainly there was no hint of this in the January 2013 thread "Annotations on extended dimension in method declarations". I think the "followed by ..." wording of 10.2 indicates that "@C []" should be the innermost (deepest) dimension, as if "int @B [] @C []" had been written. I am not clear if javac or java.lang.reflect is assembling the full array type in (what I consider to be) the wrong order. Werner, if you're reading this, can you help us out? Alex On 3/3/2014 8:29 AM, Markus Keller wrote: > JLS8 10.2 says: > "In a variable declaration (?8.3, ?8.4.1, ?9.3, ?14.14, ?14.20) except for > a variable > arity parameter, the array type of a variable is denoted by the array type > that appears > at the beginning of the declaration, followed by any bracket pairs that > follow the > variable's Identifier in the declarator." > > This was fine for Java < 8, where array dimension brackets were > indistinguishable. But with type annotations, the order of annotated > dimension brackets matters. > > Example: private @A int @B [] field @C []; > > In "1.8.0-b129", reflection says the type of "field" is "@A int @C [] @B > []", and that totally makes sense. See also [1]. > > The paragraph should e.g. say: > "[..] the array type of a variable is denoted by the element type at the > beginning of the declaration, followed by any (potentially annotated) > bracket pairs that follow the variable's Identifier in the declarator, > followed by any (potentially annotated) bracket pairs of the array type at > the beginning of the declaration." > > The ordering of consecutive array dimension brackets is currently also > undefined by the spec. There's just an informal example in 9.7.4 (which is > good; it's just not a spec). > > Regards, > Markus > > > [1] Executable snippet to test reflection: > > import java.lang.annotation.*; > import java.lang.reflect.*; > import java.util.stream.*; > > @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) > @interface A {} > @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) > @interface B {} > @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) > @interface C {} > > public class Snippet { > private @A int @B [] field @C []; > private @A int @C [] @B [] fieldNormal; > private @A int @B [] fieldBase, fieldExtra @C []; > > public static void main(String[] args) throws Exception { > printField("field"); > printField("fieldNormal"); > printField("fieldBase"); > printField("fieldExtra"); > } > > private static void printField(String name) throws > NoSuchFieldException { > System.out.printf("%-12s %s\n", name + ":", > toString(Snippet.class.getDeclaredField(name).getAnnotatedType())); > } > > private static String toString(AnnotatedType annotatedType) { > StringBuilder sb = new StringBuilder(); > while (annotatedType instanceof AnnotatedArrayType) { > sb.append(" > ").append(toString(annotatedType.getAnnotations())).append("[]"); > annotatedType = ((AnnotatedArrayType) > annotatedType).getAnnotatedGenericComponentType(); > } > Type type = annotatedType.getType(); > sb.insert(0, type.toString()); > sb.insert(0, toString(annotatedType.getAnnotations())); > return sb.toString(); > } > > private static String toString(Annotation[] annotations) { > return Stream.of(annotations).map(Snippet::toSimpleString). > collect(Collectors.joining(" ", "", " ")); > } > > public static String toSimpleString(Annotation a) { > return "@" + a.annotationType().getSimpleName(); > } > } > From wdietl at gmail.com Mon Mar 3 19:48:45 2014 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 3 Mar 2014 22:48:45 -0500 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <5314DD50.4070100@oracle.com> References: <5314DD50.4070100@oracle.com> Message-ID: Hi Markus, Alex, the current javac behavior is as Markus describes, but might be an artifact of pre-type-annotation code. At the moment in test case: tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java we only test having either all or none of the array dimensions before the field name (tests fieldAsArray and fieldAsArrayOld). I expanded the test and see the behavior that Markus describes. The behavior for variable declarations and method return types (with array dimensions after the parameter list) is consistent. Markus, you say that this behavior "totally makes sense". Can you elaborate why? I agree with Alex that having the post-identifier array dimensions become the outermost dimensions seems counter-intuitive and makes the code harder to read. Wouldn't it be easier to read if all of these fields had the same type: @TD String @TA [] @TB [] @TC [] test; @TD String @TA [] @TB [] test @TC []; @TD String @TA [] test @TB [] @TC []; @TD String test @TA [] @TB [] @TC []; cu, WMD. On Mon, Mar 3, 2014 at 2:51 PM, Alex Buckley wrote: > Hi Markus, > > Thanks for your mail and excellent test case. > > However, I don't see why the post-identifier "@C []" should be the outermost > dimension, as if "int @C [] @B []" had been written. Certainly there was no > hint of this in the January 2013 thread "Annotations on extended dimension > in method declarations". > > I think the "followed by ..." wording of 10.2 indicates that "@C []" should > be the innermost (deepest) dimension, as if "int @B [] @C []" had been > written. > > I am not clear if javac or java.lang.reflect is assembling the full array > type in (what I consider to be) the wrong order. Werner, if you're reading > this, can you help us out? > > Alex > > > On 3/3/2014 8:29 AM, Markus Keller wrote: >> >> JLS8 10.2 says: >> "In a variable declaration (?8.3, ?8.4.1, ?9.3, ?14.14, ?14.20) except for >> a variable >> arity parameter, the array type of a variable is denoted by the array type >> that appears >> at the beginning of the declaration, followed by any bracket pairs that >> follow the >> variable's Identifier in the declarator." >> >> This was fine for Java < 8, where array dimension brackets were >> indistinguishable. But with type annotations, the order of annotated >> dimension brackets matters. >> >> Example: private @A int @B [] field @C []; >> >> In "1.8.0-b129", reflection says the type of "field" is "@A int @C [] @B >> []", and that totally makes sense. See also [1]. >> >> The paragraph should e.g. say: >> "[..] the array type of a variable is denoted by the element type at the >> beginning of the declaration, followed by any (potentially annotated) >> bracket pairs that follow the variable's Identifier in the declarator, >> followed by any (potentially annotated) bracket pairs of the array type at >> the beginning of the declaration." >> >> The ordering of consecutive array dimension brackets is currently also >> undefined by the spec. There's just an informal example in 9.7.4 (which is >> good; it's just not a spec). >> >> Regards, >> Markus >> >> >> [1] Executable snippet to test reflection: >> >> import java.lang.annotation.*; >> import java.lang.reflect.*; >> import java.util.stream.*; >> >> @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) >> @interface A {} >> @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) >> @interface B {} >> @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) >> @interface C {} >> >> public class Snippet { >> private @A int @B [] field @C []; >> private @A int @C [] @B [] fieldNormal; >> private @A int @B [] fieldBase, fieldExtra @C []; >> >> public static void main(String[] args) throws Exception { >> printField("field"); >> printField("fieldNormal"); >> printField("fieldBase"); >> printField("fieldExtra"); >> } >> >> private static void printField(String name) throws >> NoSuchFieldException { >> System.out.printf("%-12s %s\n", name + ":", >> toString(Snippet.class.getDeclaredField(name).getAnnotatedType())); >> } >> >> private static String toString(AnnotatedType annotatedType) { >> StringBuilder sb = new StringBuilder(); >> while (annotatedType instanceof AnnotatedArrayType) { >> sb.append(" >> ").append(toString(annotatedType.getAnnotations())).append("[]"); >> annotatedType = ((AnnotatedArrayType) >> annotatedType).getAnnotatedGenericComponentType(); >> } >> Type type = annotatedType.getType(); >> sb.insert(0, type.toString()); >> sb.insert(0, toString(annotatedType.getAnnotations())); >> return sb.toString(); >> } >> >> private static String toString(Annotation[] annotations) { >> return Stream.of(annotations).map(Snippet::toSimpleString). >> collect(Collectors.joining(" ", "", " ")); >> } >> >> public static String toSimpleString(Annotation a) { >> return "@" + a.annotationType().getSimpleName(); >> } >> } >> > -- http://www.google.com/profiles/wdietl From markus_keller at ch.ibm.com Tue Mar 4 06:17:21 2014 From: markus_keller at ch.ibm.com (Markus Keller) Date: Tue, 4 Mar 2014 15:17:21 +0100 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: References: <5314DD50.4070100@oracle.com> Message-ID: Hi Werner, Alex > Markus, you say that this behavior "totally makes sense". Can you elaborate why? AFAIK, the primary goal of the C-style "brackets after identifier" notation is not the "mixed notation" as in Werner's examples (actually discouraged in 10.2), but to allow a declaration of a series of variables, where some of the variables have additional array dimensions: private @A int @B [] fieldBase, fieldExtra @C []; Here, fieldBase obviously has type @A int @B []. fieldExtra has the type of fieldBase, plus the extra dimension @C []. I think it makes sense to arrange it so that an element of array fieldExtra has the same type as fieldBase. To achieve that, the @C [] must be the logically "outermost" type. And by the argumentation in http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#array-syntax and the example in JLS8 9.7.4, the array bracket ordering for an outside-in traversal is from left to right, so the @C [] must be inserted in front of @B [], which gives the equivalent declaration private @A int @C [] @B [] fieldExtra; I agree it's not pretty, but as said in java-annotation-design.html, the notation is bound by history. And the alternative is IMO worse: If fieldExtra had the type @A int @B [] @C [], then its component type would be @A int @C [] -- a type that's even more disconnected from the original variable declaration. Thanks, Markus Werner Dietl wrote on 2014-03-04 04:48:45: > Hi Markus, Alex, > > the current javac behavior is as Markus describes, but might be an > artifact of pre-type-annotation code. > At the moment in test case: > > tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java > > we only test having either all or none of the array dimensions before > the field name (tests fieldAsArray and fieldAsArrayOld). > I expanded the test and see the behavior that Markus describes. > The behavior for variable declarations and method return types (with > array dimensions after the parameter list) is consistent. > > Markus, you say that this behavior "totally makes sense". Can you elaborate why? > I agree with Alex that having the post-identifier array dimensions > become the outermost dimensions seems counter-intuitive and makes the > code harder to read. > Wouldn't it be easier to read if all of these fields had the same type: > > @TD String @TA [] @TB [] @TC [] test; > @TD String @TA [] @TB [] test @TC []; > @TD String @TA [] test @TB [] @TC []; > @TD String test @TA [] @TB [] @TC []; > > cu, WMD. > > On Mon, Mar 3, 2014 at 2:51 PM, Alex Buckley wrote: > > Hi Markus, > > > > Thanks for your mail and excellent test case. > > > > However, I don't see why the post-identifier "@C []" should be the outermost > > dimension, as if "int @C [] @B []" had been written. Certainly there was no > > hint of this in the January 2013 thread "Annotations on extended dimension > > in method declarations". > > > > I think the "followed by ..." wording of 10.2 indicates that "@C []" should > > be the innermost (deepest) dimension, as if "int @B [] @C []" had been > > written. > > > > I am not clear if javac or java.lang.reflect is assembling the full array > > type in (what I consider to be) the wrong order. Werner, if you're reading > > this, can you help us out? > > > > Alex > > > > > > On 3/3/2014 8:29 AM, Markus Keller wrote: > >> > >> JLS8 10.2 says: > >> "In a variable declaration (?8.3, ?8.4.1, ?9.3, ?14.14, ?14.20) except for > >> a variable > >> arity parameter, the array type of a variable is denoted by the array type > >> that appears > >> at the beginning of the declaration, followed by any bracket pairs that > >> follow the > >> variable's Identifier in the declarator." > >> > >> This was fine for Java < 8, where array dimension brackets were > >> indistinguishable. But with type annotations, the order of annotated > >> dimension brackets matters. > >> > >> Example: private @A int @B [] field @C []; > >> > >> In "1.8.0-b129", reflection says the type of "field" is "@A int @C [] @B > >> []", and that totally makes sense. See also [1]. > >> > >> The paragraph should e.g. say: > >> "[..] the array type of a variable is denoted by the element type at the > >> beginning of the declaration, followed by any (potentially annotated) > >> bracket pairs that follow the variable's Identifier in the declarator, > >> followed by any (potentially annotated) bracket pairs of the array type at > >> the beginning of the declaration." > >> > >> The ordering of consecutive array dimension brackets is currently also > >> undefined by the spec. There's just an informal example in 9.7.4 (which is > >> good; it's just not a spec). > >> > >> Regards, > >> Markus > >> > >> > >> [1] Executable snippet to test reflection: > >> > >> import java.lang.annotation.*; > >> import java.lang.reflect.*; > >> import java.util.stream.*; > >> > >> @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) > >> @interface A {} > >> @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) > >> @interface B {} > >> @Target(ElementType.TYPE_USE) @Retention(RetentionPolicy.RUNTIME) > >> @interface C {} > >> > >> public class Snippet { > >> private @A int @B [] field @C []; > >> private @A int @C [] @B [] fieldNormal; > >> private @A int @B [] fieldBase, fieldExtra @C []; > >> > >> public static void main(String[] args) throws Exception { > >> printField("field"); > >> printField("fieldNormal"); > >> printField("fieldBase"); > >> printField("fieldExtra"); > >> } > >> > >> private static void printField(String name) throws > >> NoSuchFieldException { > >> System.out.printf("%-12s %s\n", name + ":", > >> toString(Snippet.class.getDeclaredField(name).getAnnotatedType())); > >> } > >> > >> private static String toString(AnnotatedType annotatedType) { > >> StringBuilder sb = new StringBuilder(); > >> while (annotatedType instanceof AnnotatedArrayType) { > >> sb.append(" > >> ").append(toString(annotatedType.getAnnotations())).append("[]"); > >> annotatedType = ((AnnotatedArrayType) > >> annotatedType).getAnnotatedGenericComponentType(); > >> } > >> Type type = annotatedType.getType(); > >> sb.insert(0, type.toString()); > >> sb.insert(0, toString(annotatedType.getAnnotations())); > >> return sb.toString(); > >> } > >> > >> private static String toString(Annotation[] annotations) { > >> return Stream.of(annotations).map(Snippet::toSimpleString). > >> collect(Collectors.joining(" ", "", " ")); > >> } > >> > >> public static String toSimpleString(Annotation a) { > >> return "@" + a.annotationType().getSimpleName(); > >> } > >> } > >> > > > > > > -- > http://www.google.com/profiles/wdietl > From mernst at cs.washington.edu Tue Mar 4 09:29:57 2014 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 04 Mar 2014 09:29:57 -0800 (PST) Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: References: <5314DD50.4070100@oracle.com> Message-ID: <20140304.092957.619996609875197413.mernst@cs.washington.edu> > Wouldn't it be easier to read if all of these fields had the same type: > > @TD String @TA [] @TB [] @TC [] test; > @TD String @TA [] @TB [] test @TC []; > @TD String @TA [] test @TB [] @TC []; > @TD String test @TA [] @TB [] @TC []; This is not desirable. There was some text in the old specification about this issue. It was commented out in September 2011 for brevity, but not because of controversy. In this (deprecated but legal) syntax, in each component you read left-to-right, like this: @English String @NonNull [] [] [] arr1, arr2 @Length(10) [] [] []; 3-------------> 2---------------> 1------------------> As another example, consider @A T @B [] arr1, arr2 @C []; arr1 should have the same annotations as the elements of arr2. So, @A T @B [] arr2 @C []; should be equivalent to @A T @C [] @B [] arr2; Using the examples quoted at the beginning of this email message, here are equivalence pairs: @TD String @TA [] @TB [] @TC [] test; @TD String test @TA [] @TB [] @TC []; @TD String @TA [] @TB [] test @TC []; @TD String @TC [] @TA [] @TB [] test; @TD String @TA [] test @TB [] @TC []; @TD String @TB [] @TC [] @TA [] test; -Mike From alex.buckley at oracle.com Tue Mar 4 13:47:10 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 04 Mar 2014 13:47:10 -0800 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <20140304.092957.619996609875197413.mernst@cs.washington.edu> References: <5314DD50.4070100@oracle.com> <20140304.092957.619996609875197413.mernst@cs.washington.edu> Message-ID: <531649DE.9040808@oracle.com> On 3/4/2014 9:29 AM, Michael Ernst wrote: > There was some text in the old specification about this issue. It was > commented out in September 2011 for brevity, but not because of > controversy. > > In this (deprecated but legal) syntax, in each component you read > left-to-right, like this: > > @English String @NonNull [] [] [] arr1, arr2 @Length(10) [] [] []; > 3-------------> 2---------------> 1------------------> > > As another example, consider > > @A T @B [] arr1, arr2 @C []; > > arr1 should have the same annotations as the elements of arr2. So, > > @A T @B [] arr2 @C []; > > should be equivalent to > > @A T @C [] @B [] arr2; I don't understand this at all. Allow me to refer to section 2.2.1 of java-annotation-design.pdf: -- An important property of this syntax is that, in two declarations that differ only in the number of array levels, the annotations mean the same thing. For example, var1 has the same annotations as the elements of arr2: @NonNull String var1; @NonNull String[] arr2; because in each case @NonNull refers to the String, not the array. This consistency is especially important since the two variables may appear in a single declaration: @NonNull String var1, arr2[]; -- So in a field declaration with two declarators, arr1 and arr2: @A T @B [] arr1, arr2 @C []; the extra dimension in the second declarator should not affect the type or annotations of the first declarator. Yet you seem to be saying that arr2's extra dimension affects the type of arr1?! Alex From mernst at cs.washington.edu Mon Mar 3 13:55:04 2014 From: mernst at cs.washington.edu (Michael Ernst) Date: Mon, 03 Mar 2014 13:55:04 -0800 (PST) Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <531649DE.9040808@oracle.com> References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> Message-ID: <20140303.135504.816072282202673499.mernst@cs.washington.edu> > So in a field declaration with two declarators, arr1 and arr2: > > @A T @B [] arr1, arr2 @C []; > > the extra dimension in the second declarator should not affect the type > or annotations of the first declarator. Yet you seem to be saying that > arr2's extra dimension affects the type of arr1?! I didn't intend to say that. Can you explain how you think I'm saying that arr2's extra dimension affects the type of arr1? -Mike > Subject: Re: [type-annos-observers] ordering of annotated array brackets > From: Alex Buckley > To: type-annotations-spec-experts > > Date: Tue, 04 Mar 2014 13:47:10 -0800 > > On 3/4/2014 9:29 AM, Michael Ernst wrote: >> There was some text in the old specification about this issue. It was >> commented out in September 2011 for brevity, but not because of >> controversy. >> >> In this (deprecated but legal) syntax, in each component you read >> left-to-right, like this: >> >> @English String @NonNull [] [] [] arr1, arr2 @Length(10) [] [] >> []; >> 3-------------> 2---------------> >> 1------------------> >> >> As another example, consider >> >> @A T @B [] arr1, arr2 @C []; >> >> arr1 should have the same annotations as the elements of arr2. So, >> >> @A T @B [] arr2 @C []; >> >> should be equivalent to >> >> @A T @C [] @B [] arr2; > > I don't understand this at all. Allow me to refer to section 2.2.1 of > java-annotation-design.pdf: > > -- > An important property of this syntax is that, in two declarations that > differ only in the number of array levels, the annotations mean the same > thing. For example, var1 has the same annotations as the elements of > arr2: > @NonNull String var1; > @NonNull String[] arr2; > because in each case @NonNull refers to the String, not the array. This > consistency is especially important since the two variables may appear > in a single declaration: > @NonNull String var1, arr2[]; > -- > > So in a field declaration with two declarators, arr1 and arr2: > > @A T @B [] arr1, arr2 @C []; > > the extra dimension in the second declarator should not affect the type > or annotations of the first declarator. Yet you seem to be saying that > arr2's extra dimension affects the type of arr1?! > > Alex From alex.buckley at oracle.com Tue Mar 4 15:13:37 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 04 Mar 2014 15:13:37 -0800 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <20140303.135504.816072282202673499.mernst@cs.washington.edu> References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> Message-ID: <53165E21.3090609@oracle.com> On 3/3/2014 1:55 PM, Michael Ernst wrote: >> So in a field declaration with two declarators, arr1 and arr2: >> >> @A T @B [] arr1, arr2 @C []; >> >> the extra dimension in the second declarator should not affect the >> type or annotations of the first declarator. Yet you seem to be saying >> that arr2's extra dimension affects the type of arr1?! > > I didn't intend to say that. > > Can you explain how you think I'm saying that arr2's extra dimension > affects the type of arr1? // Using the JLS ch.10 terminology carefully re: array elements v. array components. Consider: >>> As another example, consider >>> >>> @A T @B [] arr1, arr2 @C []; >>> >>> arr1 should have the same annotations as the elements of arr2. So, >>> >>> @A T @B [] arr2 @C []; >>> >>> should be equivalent to >>> >>> @A T @C [] @B [] arr2; I think you're saying: 1) the elements of arr1 are @B, and 2) the elements of arr2 should be the same as the elements of arr1. I agree with (1) but not (2). I guess (2) is deduced from the principle that: "in two declarations that differ only in the number of array levels, the annotations mean the same thing." That is, arr1 and arr2 differ only in the number of array levels, so if @B applies to arr1's element type, then @B should apply to arr2's element type, right? I disagree where post-identifier brackets are concerned, because I think that adding them should not cause the reader to do gymnastics on the annotated array type. It's simply astonishing that post-identifier [] pairs are inserted _before_ the normal [] pairs. I keep recalling the beauty of: @A T x; @A T[] y; whereby adding [] doesn't affect anything to the left of []; in that vein, adding @C [] should not affect anything to the left @B []. @A T @B [] arr1; @A T @B [] arr2 @C []; The principle of least surprise is important. Alex > -Mike > >> Subject: Re: [type-annos-observers] ordering of annotated array brackets >> From: Alex Buckley >> To: type-annotations-spec-experts >> >> Date: Tue, 04 Mar 2014 13:47:10 -0800 >> >> On 3/4/2014 9:29 AM, Michael Ernst wrote: >>> There was some text in the old specification about this issue. It was >>> commented out in September 2011 for brevity, but not because of >>> controversy. >>> >>> In this (deprecated but legal) syntax, in each component you read >>> left-to-right, like this: >>> >>> @English String @NonNull [] [] [] arr1, arr2 @Length(10) [] >>> [] []; >>> 3-------------> 2---------------> 1------------------> >>> >>> As another example, consider >>> >>> @A T @B [] arr1, arr2 @C []; >>> >>> arr1 should have the same annotations as the elements of arr2. So, >>> >>> @A T @B [] arr2 @C []; >>> >>> should be equivalent to >>> >>> @A T @C [] @B [] arr2; >> >> I don't understand this at all. Allow me to refer to section 2.2.1 of >> java-annotation-design.pdf: >> >> -- >> An important property of this syntax is that, in two declarations that >> differ only in the number of array levels, the annotations mean the >> same thing. For example, var1 has the same annotations as the elements >> of arr2: >> @NonNull String var1; >> @NonNull String[] arr2; >> because in each case @NonNull refers to the String, not the array. >> This consistency is especially important since the two variables may >> appear in a single declaration: >> @NonNull String var1, arr2[]; >> -- >> >> So in a field declaration with two declarators, arr1 and arr2: >> >> @A T @B [] arr1, arr2 @C []; >> >> the extra dimension in the second declarator should not affect the >> type or annotations of the first declarator. Yet you seem to be saying >> that arr2's extra dimension affects the type of arr1?! >> >> Alex From mernst at cs.washington.edu Tue Mar 4 16:31:26 2014 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 04 Mar 2014 16:31:26 -0800 (PST) Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <53165E21.3090609@oracle.com> References: <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> Message-ID: <20140304.163126.2301295499733824065.mernst@cs.washington.edu> Alex- Thanks for the clarification! >>>> As another example, consider >>>> >>>> @A T @B [] arr1, arr2 @C []; >>>> >>>> arr1 should have the same annotations as the elements of arr2. So, >>>> >>>> @A T @B [] arr2 @C []; >>>> >>>> should be equivalent to >>>> >>>> @A T @C [] @B [] arr2; > > I think you're saying: the elements of arr2 should be the same as the elements of arr1. No, I meant that arr1 (whose type is "@A T @B []") should have the same type as the components of arr2 (whose type is also "@A T @B []", since the type of arr2 is "@A T @C [] @B []"). I think that is consistent with the rest of my message, but I was sloppy in mixing up the JLS's "array component" vs. "array element" terminology. (I am not fond of that terminology, though I know that's not your fault.) I think this clears up at least part of the confusion. My position is that this assignment should type-check for any type MyType: MyType arr1, arr2[]; arr2[7] = arr1; I think it would be extremely confusing to users (it would violate the principle of least surprise) if this was not the case. In particular, this assignment should type-check: @A T @B [] arr1, arr2 @C []; arr2[7] = arr1; -Mike > Subject: Re: [type-annos-observers] ordering of annotated array brackets > From: Alex Buckley > To: type-annotations-spec-experts > Date: Tue, 04 Mar 2014 15:13:37 -0800 > > On 3/3/2014 1:55 PM, Michael Ernst wrote: >>> So in a field declaration with two declarators, arr1 and arr2: >>> >>> @A T @B [] arr1, arr2 @C []; >>> >>> the extra dimension in the second declarator should not affect the >>> type or annotations of the first declarator. Yet you seem to be saying >>> that arr2's extra dimension affects the type of arr1?! >> >> I didn't intend to say that. >> >> Can you explain how you think I'm saying that arr2's extra dimension >> affects the type of arr1? > > // Using the JLS ch.10 terminology carefully re: array elements v. array components. > > Consider: > >>>> As another example, consider >>>> >>>> @A T @B [] arr1, arr2 @C []; >>>> >>>> arr1 should have the same annotations as the elements of arr2. So, >>>> >>>> @A T @B [] arr2 @C []; >>>> >>>> should be equivalent to >>>> >>>> @A T @C [] @B [] arr2; > > I think you're saying: 1) the elements of arr1 are @B, and 2) the elements of arr2 should be the same as the elements of arr1. I agree with (1) but not (2). I guess (2) is deduced from the principle that: > > "in two declarations that differ only in the number of array levels, the annotations mean the same thing." > > That is, arr1 and arr2 differ only in the number of array levels, so if @B applies to arr1's element type, then @B should apply to arr2's element type, right? > > I disagree where post-identifier brackets are concerned, because I think that adding them should not cause the reader to do gymnastics on the annotated array type. It's simply astonishing that post-identifier [] pairs are inserted _before_ the normal [] pairs. I keep recalling the beauty of: > > @A T x; > @A T[] y; > > whereby adding [] doesn't affect anything to the left of []; in that vein, adding @C [] should not affect anything to the left @B []. > > @A T @B [] arr1; > @A T @B [] arr2 @C []; > > The principle of least surprise is important. > > Alex > >> -Mike >> >>> Subject: Re: [type-annos-observers] ordering of annotated array brackets >>> From: Alex Buckley >>> To: type-annotations-spec-experts >>> >>> Date: Tue, 04 Mar 2014 13:47:10 -0800 >>> >>> On 3/4/2014 9:29 AM, Michael Ernst wrote: >>>> There was some text in the old specification about this issue. It was >>>> commented out in September 2011 for brevity, but not because of >>>> controversy. >>>> >>>> In this (deprecated but legal) syntax, in each component you read >>>> left-to-right, like this: >>>> >>>> @English String @NonNull [] [] [] arr1, arr2 @Length(10) [] >>>> [] []; >>>> 3-------------> 2---------------> 1------------------> >>>> >>>> As another example, consider >>>> >>>> @A T @B [] arr1, arr2 @C []; >>>> >>>> arr1 should have the same annotations as the elements of arr2. So, >>>> >>>> @A T @B [] arr2 @C []; >>>> >>>> should be equivalent to >>>> >>>> @A T @C [] @B [] arr2; >>> >>> I don't understand this at all. Allow me to refer to section 2.2.1 of >>> java-annotation-design.pdf: >>> >>> -- >>> An important property of this syntax is that, in two declarations that >>> differ only in the number of array levels, the annotations mean the >>> same thing. For example, var1 has the same annotations as the elements >>> of arr2: >>> @NonNull String var1; >>> @NonNull String[] arr2; >>> because in each case @NonNull refers to the String, not the array. >>> This consistency is especially important since the two variables may >>> appear in a single declaration: >>> @NonNull String var1, arr2[]; >>> -- >>> >>> So in a field declaration with two declarators, arr1 and arr2: >>> >>> @A T @B [] arr1, arr2 @C []; >>> >>> the extra dimension in the second declarator should not affect the >>> type or annotations of the first declarator. Yet you seem to be saying >>> that arr2's extra dimension affects the type of arr1?! >>> >>> Alex From markus_keller at ch.ibm.com Wed Mar 5 02:26:44 2014 From: markus_keller at ch.ibm.com (Markus Keller) Date: Wed, 5 Mar 2014 11:26:44 +0100 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <53165E21.3090609@oracle.com> References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> Message-ID: Alex Buckley wrote on 2014-03-05 00:13:37: > I disagree where post-identifier brackets are concerned, because I think > that adding them should not cause the reader to do gymnastics on the > annotated array type. It's simply astonishing that post-identifier [] > pairs are inserted _before_ the normal [] pairs. I keep recalling the > beauty of: > > @A T x; > @A T[] y; > > whereby adding [] doesn't affect anything to the left of []; in that > vein, adding @C [] should not affect anything to the left @B []. > > @A T @B [] arr1; > @A T @B [] arr2 @C []; Note that this is not just about post-identifier [] pairs. It's a direct consequence of the notation for multi-dimensional array types. If you have a declaration @A T @B [] @C [] arr3; then arr3 is of type "@B-array of @C-array of @A T", and the component type of arr3 is @A T @C [] arr3component = arr3[7]; because "@B []" is the outermost dimension. This is a bit surprising, but as argued in [1], the surprise is that array brackets have to be written after the element type, and not before. Using a generic List "@B-List of @C-List of @A T", a similar type would look like this: @B List<@C List<@A T>> arrList3; See how the order of annotations is @B, @C as well when @B is the outermost type annotation? [1] http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#array-syntax Markus From timo.kinnunen at gmail.com Wed Mar 5 03:24:08 2014 From: timo.kinnunen at gmail.com (=?utf-8?Q?Timo_Kinnunen?=) Date: Wed, 5 Mar 2014 11:24:08 +0000 Subject: [type-annos-observers] =?utf-8?q?ordering_of_annotated_array_brac?= =?utf-8?q?kets?= In-Reply-To: References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com>, Message-ID: <5317185e.41690e0a.36bd.ffff812c@mx.google.com> Hi, I can?t help thinking that none of what?s being discussed would actually matter if there was a syntactically legal way to write something like this and doing anything else was deemed ambiguous: @A (T[]) arr1; (@A T)[] arr2; ? (more realistically perhaps @Length(10) arr1 and <@NotNull T>[] arr2, in an alternate reality) And then there?s the disquieting doubt about whether the syntax changes that would allow @B ((@C ((@A T)[]))[]) arrList3; (more realistically @B <@C <@A T>[]>[] arrList3; ) might in the end have turned out smaller than and obviating the need for the syntax changes needed to allow T @A[] and org.foo. @A T both. I know, I know, ?it?s too late for Java 8?, it was too late last year when I first started paying attention and probably has been too late since after 2009 when lambda syntax was decided. Hopefully it?s not yet too late for Java 10. -- Have a nice day, Timo. Sent from Windows Mail From: Markus Keller Sent: ?Wednesday?, ?March? ?5?, ?2014 ?12?:?26 To: type-annotations-spec-observers at openjdk.java.net Cc: alex.buckley at oracle.com Alex Buckley wrote on 2014-03-05 00:13:37: > I disagree where post-identifier brackets are concerned, because I think > that adding them should not cause the reader to do gymnastics on the > annotated array type. It's simply astonishing that post-identifier [] > pairs are inserted _before_ the normal [] pairs. I keep recalling the > beauty of: > > @A T x; > @A T[] y; > > whereby adding [] doesn't affect anything to the left of []; in that > vein, adding @C [] should not affect anything to the left @B []. > > @A T @B [] arr1; > @A T @B [] arr2 @C []; Note that this is not just about post-identifier [] pairs. It's a direct consequence of the notation for multi-dimensional array types. If you have a declaration @A T @B [] @C [] arr3; then arr3 is of type "@B-array of @C-array of @A T", and the component type of arr3 is @A T @C [] arr3component = arr3[7]; because "@B []" is the outermost dimension. This is a bit surprising, but as argued in [1], the surprise is that array brackets have to be written after the element type, and not before. Using a generic List "@B-List of @C-List of @A T", a similar type would look like this: @B List<@C List<@A T>> arrList3; See how the order of annotations is @B, @C as well when @B is the outermost type annotation? [1] http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#array-syntax Markus From alex.buckley at oracle.com Wed Mar 5 11:34:20 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 05 Mar 2014 11:34:20 -0800 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> Message-ID: <53177C3C.1020905@oracle.com> On 3/5/2014 2:26 AM, Markus Keller wrote: > Note that this is not just about post-identifier [] pairs. It's a direct > consequence of the notation for multi-dimensional array types. > > If you have a declaration > > @A T @B [] @C [] arr3; > > then arr3 is of type "@B-array of @C-array of @A T", and the component > type of arr3 is > > @A T @C [] arr3component = arr3[7]; > > because "@B []" is the outermost dimension. This is a bit surprising, but > as argued in [1], the surprise is that array brackets have to be written > after the element type, and not before. I agree with all of the above. The component type of arr3 is @A T @C [], sure. However, I don't think that has a bearing on the question at hand: why can't the component type of @A T @B [] arr4 @C []; simply be decreed as @A T @C [] ? Now, I know the answer; it's so that the annotations work out on: @A T @B [] arr4 @C []; @A T @B [] arr5; arr5 = arr4[0]; arr4[0] = arr5; But look, if I write: T @B [] @C [] arr7; T @C [] arr8 @B []; then no-one will be astonished to learn that arr7 and arr8 have different types from an annotation point of view: @B [] @C [] versus @C [] @B []. Post-identifier brackets are a corner case, and mixed array syntax is a corner case of that corner case. It's unreasonable to bend a core part of the language - i.e. the rules for "declared type of a field / local var / formal parameter" - to support a corner case of a corner case. (If you must, declare arr8 as: T arr8 @B[] @C []; so it has the same annotated array type as arr7.) Alex From alex.buckley at oracle.com Wed Mar 5 11:37:02 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 05 Mar 2014 11:37:02 -0800 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <20140304.163126.2301295499733824065.mernst@cs.washington.edu> References: <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> <20140304.163126.2301295499733824065.mernst@cs.washington.edu> Message-ID: <53177CDE.7010408@oracle.com> On 3/4/2014 4:31 PM, Michael Ernst wrote: > My position is that this assignment should type-check for any type MyType: > > MyType arr1, arr2[]; > arr2[7] = arr1; > > I think it would be extremely confusing to users (it would violate the > principle of least surprise) if this was not the case. In particular, > this assignment should type-check: > > @A T @B [] arr1, arr2 @C []; > arr2[7] = arr1; I understand this logic, and I accept that post-identifier bracket pairs were described long ago in java-annotation-design.pdf. But I just can't agree with convoluting the basic type-of-a-variable rules to handle annotations in mixed array syntax. Please see my response to Markus: http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2014-March/000278.html Alex From markus_keller at ch.ibm.com Thu Mar 6 08:57:24 2014 From: markus_keller at ch.ibm.com (Markus Keller) Date: Thu, 6 Mar 2014 17:57:24 +0100 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <53177C3C.1020905@oracle.com> References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> <53177C3C.1020905@oracle.com> Message-ID: Alex Buckley wrote on 2014-03-05 20:34:20: > Post-identifier brackets are a corner case, and mixed array syntax is a > corner case of that corner case. It's unreasonable to bend a core part > of the language - i.e. the rules for "declared type of a field / local > var / formal parameter" - to support a corner case of a corner case. I'm sure we can find a better wording for the paragraph in 10.2, so that we don't have to sacrifice the internal consistency of the array type notations. And the new wording can even add the missing definition of the array brackets order for non-mixed array types. Type annotations are part of the language now, so they need to be specified. The rules for the core part of the language don't have to be changed much. Proposal: * Add to 10.1: ----- The leftmost bracket pair of an array type stands for the outermost array dimension; a following bracket pair for the array's component type, and so on. Each bracket pair can be annotated with type annotations (?9.7.4). For example, given the field declaration: @C int @A [] @B [] f; @A applies to the array type int[][], @B applies to its component type int[], and @C applies to the element type int. ----- * Change 10.2: ----- [..] the array type of a variable is denoted by the array type that appears at the beginning of the declaration, extended by any bracket pairs that follow the variable's Identifier in the declarator. If present, the first bracket pair that follows the variable's identifier stands for the outermost array dimension; a following bracket pair for the array's component type, and so on. The component type of the last array dimension is the type that appears at the beginning of the declaration (and that type can be an array type itself). ----- The last example in 10.2 could get a clarifying type annotation: float[][] f[][], g[][][], h @A []; // Yechh! ... float @A [][][] h; Markus From wdietl at gmail.com Mon Mar 17 16:56:14 2014 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 17 Mar 2014 12:56:14 -0400 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> <53177C3C.1020905@oracle.com> Message-ID: Alex, all, I found the arguments by Mike and Markus convincing. I previously only looked at the purely optical impression of moving an identifier between different pre-/post-identifier array brackets. However, thinking about the operations performed on them seems more important. I particularly like Markus' example of converting between arrays and List. To expand on that: @A Elem @B [] a1, a2 @C []; should allow: a2[0] = a1; Similarly, using List, we would have: @B List<@A Elem> a1, a2 @C []; which still allows "a2[0] = a1;". Now let's separate a1 and a2: @B List<@A Elem> a1; @B List<@A Elem> @C [] a2; and now go back to all arrays: @A Elem @B [] a1; @A Elem @C [] @B [] a2; The component type of a2 is "@A Elem @B []" which again allows the assignment. I find thinking about the array / List correspondence helpful and now agree with Markus and Mike that the current javac/ecj behavior is desired. cu, WMD. On Thu, Mar 6, 2014 at 11:57 AM, Markus Keller wrote: > Alex Buckley wrote on 2014-03-05 20:34:20: >> Post-identifier brackets are a corner case, and mixed array syntax is a >> corner case of that corner case. It's unreasonable to bend a core part >> of the language - i.e. the rules for "declared type of a field / local >> var / formal parameter" - to support a corner case of a corner case. > > I'm sure we can find a better wording for the paragraph in 10.2, so that > we don't have to sacrifice the internal consistency of the array type > notations. And the new wording can even add the missing definition of the > array brackets order for non-mixed array types. Type annotations are part > of the language now, so they need to be specified. The rules for the core > part of the language don't have to be changed much. > > Proposal: > > * Add to 10.1: > ----- > The leftmost bracket pair of an array type stands for the outermost array > dimension; a following bracket pair for the array's component type, and so > on. Each bracket pair can be annotated with type annotations (?9.7.4). > > > For example, given the field declaration: > > @C int @A [] @B [] f; > > @A applies to the array type int[][], @B applies to its component > type int[], and @C applies to the element type int. > > ----- > > * Change 10.2: > ----- > [..] the array type of a variable is denoted by the array type that > appears at the beginning of the declaration, extended by any bracket pairs > that follow the variable's Identifier in the declarator. > > If present, the first bracket pair that follows the variable's identifier > stands for the outermost array dimension; a following bracket pair for the > array's component type, and so on. The component type of the last array > dimension is the type that appears at the beginning of the declaration > (and that type can be an array type itself). > ----- > > The last example in 10.2 could get a clarifying type annotation: > > float[][] f[][], g[][][], h @A []; // Yechh! > ... > float @A [][][] h; > > > Markus > -- http://www.google.com/profiles/wdietl From alex.buckley at oracle.com Mon Mar 17 19:48:14 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Mar 2014 12:48:14 -0700 Subject: [type-annos-observers] Are annotations on parameter types supported in lambda expressions? In-Reply-To: References: Message-ID: <5327517E.8090000@oracle.com> Hi Dieter, On 3/15/2014 4:57 AM, Dieter Kleinrath wrote: > I'm not sure, if this is the right place to ask this question, or if it > would be better to ask the developers of JSR 335 (Project Lambda). type-annotations-spec-comments is the right place to ask about the design intent of type annotations. > The JSR 308 Specification is not very specific about whether Type > Annotations should also be allowed on the type parameters of lambda > expressions or not. But if I read it correctly, I guess code like the > following should be ok (where MyTypeAnnotation is an Annotation > with ElementType#TYPE_USE): > > Consumer c = (@MyTypeAnnotation String p) -> System.out.println(p); You speak of "type parameters of lambda expressions" but lambda expressions are not generic so they cannot declare type parameters. As to the types of formal parameters of lambda expressions, it has been legal to annotate them for some time [1]. See JLS8 9.6.4.1, 9.7.4, and 4.11. [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2012-December/000044.html > But the current JDK 8 (b132) javac compiler does not store the information > of parameter type annotations in the generated class files (the same is > true for the current Eclipse JDT compiler). I tested this by trying to get > the Annotation at runtime with Method#getAnnotatedParameterTypes() and by > reading the class file with the latest ASM build (that already supports > Type Annotations). javac emits the correct Runtime[In]VisibleTypeAnnotations attribute for annotations on the types of formal parameters of a lambda expression. The attribute appears on the private method generated for a lambda expression, so you need to run javap with -p to see it. However, there are known bugs in the emission of, and especially the reflection of, annotations on types of formal parameters. See https://bugs.openjdk.java.net/browse/JDK-8027181. > PS.: On a side note: parameter names of lambda expressions are currently > also not stored in the class files, if one compiles with javac > -parameters... I confirm this is a javac bug; thanks, I'll report it. Alex From alex.buckley at oracle.com Mon Mar 17 22:53:44 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Mar 2014 15:53:44 -0700 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> <53177C3C.1020905@oracle.com> Message-ID: <53277CF8.9080601@oracle.com> Hi Werner, Mixed array syntax is germane to the type of a declaration (variable / method) in the following JLS sections: 8.3, 8.4, 9.3, 9.4, 9.6.1, 14.4, 14.14.2, and 15.27.1. Those are important sections. Having them define the type in a way that leads with post-identifier syntax is a non-starter for me. (This applies whether each section defines the type itself, or points to a central definition in 10.2 when square brackets are involved.) The driver for your interpretation of annotated mixed array syntax seems to be a desire to write multiple declarators in a single declaration. I suggest it is more readable to write one declarator per declaration (the "let's separate a1 and a2" case), and keep the rules for array types simple: one pass, left to right. Alex On 3/17/2014 9:56 AM, Werner Dietl wrote: > Alex, all, > > I found the arguments by Mike and Markus convincing. > I previously only looked at the purely optical impression of moving an > identifier between different pre-/post-identifier array brackets. > However, thinking about the operations performed on them seems more important. > I particularly like Markus' example of converting between arrays and > List. To expand on that: > > @A Elem @B [] a1, a2 @C []; > > should allow: > > a2[0] = a1; > > Similarly, using List, we would have: > > @B List<@A Elem> a1, a2 @C []; > > which still allows "a2[0] = a1;". > Now let's separate a1 and a2: > > @B List<@A Elem> a1; > @B List<@A Elem> @C [] a2; > > and now go back to all arrays: > > @A Elem @B [] a1; > @A Elem @C [] @B [] a2; > > The component type of a2 is "@A Elem @B []" which again allows the assignment. > > I find thinking about the array / List correspondence helpful and now > agree with Markus and Mike that the current javac/ecj behavior is > desired. > > cu, WMD. > > > > > > > > > > On Thu, Mar 6, 2014 at 11:57 AM, Markus Keller wrote: >> Alex Buckley wrote on 2014-03-05 20:34:20: >>> Post-identifier brackets are a corner case, and mixed array syntax is a >>> corner case of that corner case. It's unreasonable to bend a core part >>> of the language - i.e. the rules for "declared type of a field / local >>> var / formal parameter" - to support a corner case of a corner case. >> >> I'm sure we can find a better wording for the paragraph in 10.2, so that >> we don't have to sacrifice the internal consistency of the array type >> notations. And the new wording can even add the missing definition of the >> array brackets order for non-mixed array types. Type annotations are part >> of the language now, so they need to be specified. The rules for the core >> part of the language don't have to be changed much. >> >> Proposal: >> >> * Add to 10.1: >> ----- >> The leftmost bracket pair of an array type stands for the outermost array >> dimension; a following bracket pair for the array's component type, and so >> on. Each bracket pair can be annotated with type annotations (?9.7.4). >> >> >> For example, given the field declaration: >> >> @C int @A [] @B [] f; >> >> @A applies to the array type int[][], @B applies to its component >> type int[], and @C applies to the element type int. >> >> ----- >> >> * Change 10.2: >> ----- >> [..] the array type of a variable is denoted by the array type that >> appears at the beginning of the declaration, extended by any bracket pairs >> that follow the variable's Identifier in the declarator. >> >> If present, the first bracket pair that follows the variable's identifier >> stands for the outermost array dimension; a following bracket pair for the >> array's component type, and so on. The component type of the last array >> dimension is the type that appears at the beginning of the declaration >> (and that type can be an array type itself). >> ----- >> >> The last example in 10.2 could get a clarifying type annotation: >> >> float[][] f[][], g[][][], h @A []; // Yechh! >> ... >> float @A [][][] h; >> >> >> Markus >> > > > From srikanth_sankaran at in.ibm.com Tue Mar 18 02:27:02 2014 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 18 Mar 2014 07:57:02 +0530 Subject: [type-annos-observers] Are annotations on parameter types supported in lambda expressions? In-Reply-To: References: Message-ID: Thanks for the report, I have raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=430571 against the eclipse compiler. Srikanth From markus_keller at ch.ibm.com Tue Mar 18 15:42:21 2014 From: markus_keller at ch.ibm.com (Markus Keller) Date: Tue, 18 Mar 2014 16:42:21 +0100 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <53277CF8.9080601@oracle.com> References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> <53177C3C.1020905@oracle.com> <53277CF8.9080601@oracle.com> Message-ID: Nobody wants to touch all the JLS sections you mentioned. The grammar is fine, and all those sections don't say a word about array types (let alone about type annotations on array types). > The driver for your interpretation of annotated mixed array syntax seems > to be a desire to write multiple declarators in a single declaration. Yes, because the multi-declarator syntax is THE reason why the post-identifier brackets notation exists and is used at all. [1] Do you disagree with all the examples that were given? > > @A Elem @B [] a1, a2 @C []; > > > > should allow: > > > > a2[0] = a1; By the simplistic "one pass, left to right" rule, this assignment would not be well-typed. Why would that be favorable? The mixed array type notation is already discouraged, so the more involved annotation order is not a big deal in practice. Consistency of the language is more important than a "simpler" interpretation that would invalidate existing code when type annotations are added. [1] The Java Tutorial already discourages the post-identifier brackets notation: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html The JLS could do the same. Markus Alex Buckley wrote on 2014-03-17 23:53:44: > Hi Werner, > > Mixed array syntax is germane to the type of a declaration (variable / > method) in the following JLS sections: 8.3, 8.4, 9.3, 9.4, 9.6.1, 14.4, > 14.14.2, and 15.27.1. > > Those are important sections. Having them define the type in a way that > leads with post-identifier syntax is a non-starter for me. (This applies > whether each section defines the type itself, or points to a central > definition in 10.2 when square brackets are involved.) > > The driver for your interpretation of annotated mixed array syntax seems > to be a desire to write multiple declarators in a single declaration. I > suggest it is more readable to write one declarator per declaration (the > "let's separate a1 and a2" case), and keep the rules for array types > simple: one pass, left to right. > > Alex > > On 3/17/2014 9:56 AM, Werner Dietl wrote: > > Alex, all, > > > > I found the arguments by Mike and Markus convincing. > > I previously only looked at the purely optical impression of moving an > > identifier between different pre-/post-identifier array brackets. > > However, thinking about the operations performed on them seems more important. > > I particularly like Markus' example of converting between arrays and > > List. To expand on that: > > > > @A Elem @B [] a1, a2 @C []; > > > > should allow: > > > > a2[0] = a1; > > > > Similarly, using List, we would have: > > > > @B List<@A Elem> a1, a2 @C []; > > > > which still allows "a2[0] = a1;". > > Now let's separate a1 and a2: > > > > @B List<@A Elem> a1; > > @B List<@A Elem> @C [] a2; > > > > and now go back to all arrays: > > > > @A Elem @B [] a1; > > @A Elem @C [] @B [] a2; > > > > The component type of a2 is "@A Elem @B []" which again allows the assignment. > > > > I find thinking about the array / List correspondence helpful and now > > agree with Markus and Mike that the current javac/ecj behavior is > > desired. > > > > cu, WMD. > > > > > > > > > > > > > > > > > > > > On Thu, Mar 6, 2014 at 11:57 AM, Markus Keller wrote: > >> Alex Buckley wrote on 2014-03-05 20:34:20: > >>> Post-identifier brackets are a corner case, and mixed array syntax is a > >>> corner case of that corner case. It's unreasonable to bend a core part > >>> of the language - i.e. the rules for "declared type of a field / local > >>> var / formal parameter" - to support a corner case of a corner case. > >> > >> I'm sure we can find a better wording for the paragraph in 10.2, so that > >> we don't have to sacrifice the internal consistency of the array type > >> notations. And the new wording can even add the missing definition of the > >> array brackets order for non-mixed array types. Type annotations are part > >> of the language now, so they need to be specified. The rules for the core > >> part of the language don't have to be changed much. > >> > >> Proposal: > >> > >> * Add to 10.1: > >> ----- > >> The leftmost bracket pair of an array type stands for the outermost array > >> dimension; a following bracket pair for the array's component type, and so > >> on. Each bracket pair can be annotated with type annotations (?9.7.4). > >> > >> > >> For example, given the field declaration: > >> > >> @C int @A [] @B [] f; > >> > >> @A applies to the array type int[][], @B applies to its component > >> type int[], and @C applies to the element type int. > >> > >> ----- > >> > >> * Change 10.2: > >> ----- > >> [..] the array type of a variable is denoted by the array type that > >> appears at the beginning of the declaration, extended by any bracket pairs > >> that follow the variable's Identifier in the declarator. > >> > >> If present, the first bracket pair that follows the variable's identifier > >> stands for the outermost array dimension; a following bracket pair for the > >> array's component type, and so on. The component type of the last array > >> dimension is the type that appears at the beginning of the declaration > >> (and that type can be an array type itself). > >> ----- > >> > >> The last example in 10.2 could get a clarifying type annotation: > >> > >> float[][] f[][], g[][][], h @A []; // Yechh! > >> ... > >> float @A [][][] h; > >> > >> > >> Markus > >> > > > > > > > From alex.buckley at oracle.com Wed Mar 19 18:09:22 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 19 Mar 2014 11:09:22 -0700 Subject: [type-annos-observers] Are annotations on parameter types supported in lambda expressions? In-Reply-To: References: Message-ID: <5329DD52.6090601@oracle.com> On 3/17/2014 7:27 PM, Srikanth S Adayapalam wrote: > Thanks for the report, I have raised > https://bugs.eclipse.org/bugs/show_bug.cgi?id=430571 > against the eclipse compiler. The equivalent javac bug re: MethodParameters for a private method representing a lambda expression is https://bugs.openjdk.java.net/browse/JDK-8037546. Alex From alex.buckley at oracle.com Wed Mar 19 18:33:43 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 19 Mar 2014 11:33:43 -0700 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> <53177C3C.1020905@oracle.com> <53277CF8.9080601@oracle.com> Message-ID: <5329E307.4080107@oracle.com> The JLS sections I mentioned describe how to form the array type of a declared entity (variable, method return type) by reading bracket pairs if present. Regardless of type annotations, those sections should be updated to point to 10.2 to get a centralized definition of how to read an array type [you alluded to that definition before]. With regard to type annotations that thread themselves into an array type, my concern is to keep the centralized definition as simple as possible - "one pass, left to right". I understand the a2[0]=a1 scenario. Since making it well-typed means redefining the array type construction rule to consider post-identifier [] first, I am happy for a2[0]=a1 to not be well typed. There is a simple fix here: declare a1 and a2 in different declarations. Alex On 3/18/2014 8:42 AM, Markus Keller wrote: > Nobody wants to touch all the JLS sections you mentioned. The grammar is > fine, and all those sections don't say a word about array types (let alone > about type annotations on array types). > >> The driver for your interpretation of annotated mixed array syntax seems > >> to be a desire to write multiple declarators in a single declaration. > > Yes, because the multi-declarator syntax is THE reason why the > post-identifier brackets notation exists and is used at all. [1] > > Do you disagree with all the examples that were given? > >>> @A Elem @B [] a1, a2 @C []; >>> >>> should allow: >>> >>> a2[0] = a1; > > By the simplistic "one pass, left to right" rule, this assignment would > not be well-typed. Why would that be favorable? > > The mixed array type notation is already discouraged, so the more involved > annotation order is not a big deal in practice. Consistency of the > language is more important than a "simpler" interpretation that would > invalidate existing code when type annotations are added. > > [1] The Java Tutorial already discourages the post-identifier brackets > notation: > http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html > The JLS could do the same. > > Markus > > > Alex Buckley wrote on 2014-03-17 23:53:44: >> Hi Werner, >> >> Mixed array syntax is germane to the type of a declaration (variable / >> method) in the following JLS sections: 8.3, 8.4, 9.3, 9.4, 9.6.1, 14.4, >> 14.14.2, and 15.27.1. >> >> Those are important sections. Having them define the type in a way that >> leads with post-identifier syntax is a non-starter for me. (This applies > >> whether each section defines the type itself, or points to a central >> definition in 10.2 when square brackets are involved.) >> >> The driver for your interpretation of annotated mixed array syntax seems > >> to be a desire to write multiple declarators in a single declaration. I >> suggest it is more readable to write one declarator per declaration (the > >> "let's separate a1 and a2" case), and keep the rules for array types >> simple: one pass, left to right. >> >> Alex >> >> On 3/17/2014 9:56 AM, Werner Dietl wrote: >>> Alex, all, >>> >>> I found the arguments by Mike and Markus convincing. >>> I previously only looked at the purely optical impression of moving an >>> identifier between different pre-/post-identifier array brackets. >>> However, thinking about the operations performed on them seems more > important. >>> I particularly like Markus' example of converting between arrays and >>> List. To expand on that: >>> >>> @A Elem @B [] a1, a2 @C []; >>> >>> should allow: >>> >>> a2[0] = a1; >>> >>> Similarly, using List, we would have: >>> >>> @B List<@A Elem> a1, a2 @C []; >>> >>> which still allows "a2[0] = a1;". >>> Now let's separate a1 and a2: >>> >>> @B List<@A Elem> a1; >>> @B List<@A Elem> @C [] a2; >>> >>> and now go back to all arrays: >>> >>> @A Elem @B [] a1; >>> @A Elem @C [] @B [] a2; >>> >>> The component type of a2 is "@A Elem @B []" which again allows the > assignment. >>> >>> I find thinking about the array / List correspondence helpful and now >>> agree with Markus and Mike that the current javac/ecj behavior is >>> desired. >>> >>> cu, WMD. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Mar 6, 2014 at 11:57 AM, Markus Keller > wrote: >>>> Alex Buckley wrote on 2014-03-05 20:34:20: >>>>> Post-identifier brackets are a corner case, and mixed array syntax > is a >>>>> corner case of that corner case. It's unreasonable to bend a core > part >>>>> of the language - i.e. the rules for "declared type of a field / > local >>>>> var / formal parameter" - to support a corner case of a corner case. >>>> >>>> I'm sure we can find a better wording for the paragraph in 10.2, so > that >>>> we don't have to sacrifice the internal consistency of the array type >>>> notations. And the new wording can even add the missing definition of > the >>>> array brackets order for non-mixed array types. Type annotations are > part >>>> of the language now, so they need to be specified. The rules for the > core >>>> part of the language don't have to be changed much. >>>> >>>> Proposal: >>>> >>>> * Add to 10.1: >>>> ----- >>>> The leftmost bracket pair of an array type stands for the outermost > array >>>> dimension; a following bracket pair for the array's component type, > and so >>>> on. Each bracket pair can be annotated with type annotations > (?9.7.4). >>>> >>>> >>>> For example, given the field declaration: >>>> >>>> @C int @A [] @B [] f; >>>> >>>> @A applies to the array type int[][], @B applies to its > component >>>> type int[], and @C applies to the element type int. >>>> >>>> ----- >>>> >>>> * Change 10.2: >>>> ----- >>>> [..] the array type of a variable is denoted by the array type that >>>> appears at the beginning of the declaration, extended by any bracket > pairs >>>> that follow the variable's Identifier in the declarator. >>>> >>>> If present, the first bracket pair that follows the variable's > identifier >>>> stands for the outermost array dimension; a following bracket pair > for the >>>> array's component type, and so on. The component type of the last > array >>>> dimension is the type that appears at the beginning of the > declaration >>>> (and that type can be an array type itself). >>>> ----- >>>> >>>> The last example in 10.2 could get a clarifying type annotation: >>>> >>>> float[][] f[][], g[][][], h @A []; // Yechh! >>>> ... >>>> float @A [][][] h; >>>> >>>> >>>> Markus >>>> >>> >>> >>> >> > From markus_keller at ch.ibm.com Thu Mar 27 15:12:19 2014 From: markus_keller at ch.ibm.com (Markus Keller) Date: Thu, 27 Mar 2014 16:12:19 +0100 Subject: [type-annos-observers] ordering of annotated array brackets In-Reply-To: <5329E307.4080107@oracle.com> References: <20140304.092957.619996609875197413.mernst@cs.washington.edu> <531649DE.9040808@oracle.com> <20140303.135504.816072282202673499.mernst@cs.washington.edu> <53165E21.3090609@oracle.com> <53177C3C.1020905@oracle.com> <53277CF8.9080601@oracle.com> <5329E307.4080107@oracle.com> Message-ID: Alex Buckley wrote on 2014-03-19 19:33:43: > I understand the a2[0]=a1 scenario. Since making it well-typed means > redefining the array type construction rule to consider post-identifier > [] first, I am happy for a2[0]=a1 to not be well typed. There is a > simple fix here: declare a1 and a2 in different declarations. Wasn't it a no-go in the past to require users to rewrite existing code? http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-January/000064.html Not adding new features to deprecated constructs would have been fine, but adding them in an inconsistent way is really bad. The too simple "left-to-right" rule also makes simple refactorings a pain, e.g. replacing a type parameter by a concrete type: import static java.lang.annotation.ElementType.TYPE_USE; import java.lang.annotation.*; @Target(TYPE_USE) @interface NonEmpty {} public class Test { public API api; public API2 api2; void test() { api.t = api.ts[0]; // OK api2.t = api2.ts[0]; // Not OK? } } class API { public T t, ts[]; void assign() { t = ts[0]; // OK } } class API2 { public String @NonEmpty [] t, ts[]; void assign() { t = ts[0]; // Not OK? } }