From alex.buckley at oracle.com Tue Sep 3 13:53:56 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 03 Sep 2013 13:53:56 -0700 Subject: [type-annos-observers] JLS and JVMS changes for JSR 308 In-Reply-To: <52005319.9000209@oracle.com> References: <52005319.9000209@oracle.com> Message-ID: <52264C64.5090701@oracle.com> I have just updated the 308.pdf spec to i) clarify ClassFile annotations on anonymous class declarations, and ii) sharpen the rule in 9.7.4 against annotating a static member type. The former was discussed here on Aug 23. As for the latter, the spec already prevented types in many syntactic contexts from being annotated - notably types in expression names - but the spec failed to prevent static member types in type contexts themselves from being annotated. Again, I urge EG members to understand the comprehensive nature of type contexts proposed for JLS8. Alex [1]http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-September/001244.html On 8/5/2013 6:36 PM, Alex Buckley wrote: > I have prepared a PDF containing the JLS and JVMS changes for JSR 308: > > http://cr.openjdk.java.net/~abuckley/308.pdf > > If you're expecting a simple list of grammar changes, you may want to > sit down before opening the PDF. There are significant clarifications to > JLS chapters 4 and 6, all aimed at pinning down what exactly is a type > use. The JLS has distinguished between types (a.k.a. type uses) and type > names since JLS3, but it was very subtle, and it is essential for JLS8 > to take a comprehensive view of the language's syntactic contexts and > the types and names allowed therein. > > The ClassFile changes present a recurring challenge: how much to mention > Java language features in the JVMS? The Signature attribute is a > precedent, so for now, I have aimed for maximum clarity. An example > would be mentioning both constructors and methods when describing > target_info, even though the ClassFile structure is aware only of methods. > > Text in the PDF is either normative or informative. Informative text is > smaller and indented. The point of the PDF is that most text is ready to > go into the JLS or JVMS as-is, although informative text which mentions > JSR 308 is intended more as commentary for 2013 than as long-term > specification; it will evolve further, or be removed. > > The UW PDF at: > > > http://types.cs.washington.edu/jsr308/specification/java-annotation-design.pdf > > > remains an excellent source of background, examples, and rationale. This > kind of material should be available on the JSR 308 page at jcp.org > forever, so I envisage offering both 308.pdf and > java-annotation-design.pdf in the milestone reviews yet to come. > > Mike, it would be instructive to look at how JSR 334's specification > changed between Public Review and Proposed Final Draft. Vast swathes of > normative text were replaced with pointers to JLS sections. It would be > appropriate to start the same "pruning" process on > java-annotation-design.pdf. This will provide a double check on my > extraction of normative clauses from java-annotation-design.pdf. > > Alex From alex.buckley at oracle.com Fri Sep 6 10:20:01 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 06 Sep 2013 10:20:01 -0700 Subject: [type-annos-observers] JSR 308 reflection APIs Message-ID: <522A0EC1.6040502@oracle.com> Thanks to Joel Borggr?n-Franck, we have published the spec diffs due to JSR 308 in the Core Reflection, Language Model, and Annotation Processing APIs: http://cr.openjdk.java.net/~jfranck/anno-work/spec/ As presented there, the specs are licensed for evaluation and comment purposes only, like the type-annotations-spec-experts list itself. Alex From srikanth_sankaran at in.ibm.com Wed Sep 11 22:35:30 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Thu, 12 Sep 2013 11:05:30 +0530 Subject: [type-annos-observers] Should JSR308 forbid type annotations on uses of a type parameter ? Message-ID: Hello ! I am trying to understand if there are valid scenarios where type annotating the use of a type variable actually makes sense. The following program compiles fine with both eclipse and javac 8b100: import java.lang.annotation.ElementType; import java.lang.annotation.Target; @Target(ElementType.TYPE_USE) @interface TA { } @Target(ElementType.TYPE_USE) @interface TB { } public abstract class X<@TA T> { @TB T t; } Studying this test case, since both occurrence of T would denote the same type instantiation, does it make sense to think of "only @TA annotated T" and "only @TB annotated T" ? Shouldn't the language insist that they be consolidated and presented all at the declaration site ? Have I overlooked any valid scenarios where this would actually make sense ? Thanks! Srikanth From wdietl at gmail.com Thu Sep 12 02:27:16 2013 From: wdietl at gmail.com (Werner Dietl) Date: Thu, 12 Sep 2013 02:27:16 -0700 Subject: [type-annos-observers] Should JSR308 forbid type annotations on uses of a type parameter ? In-Reply-To: References: Message-ID: Hi Srikanth, For the use in type systems, having the distinction between type parameter declarations and type variable uses is necessary. The Checker Framework manual dedicates a section discussing this interaction: http://types.cs.washington.edu/checker-framework/current/checkers-manual.html#generics In brief, one can imagine: class C<@TA T extends @TB Upper> { T field1; @TC T field2; } Note that @TA can have @Target meta-annotation TYPE_PARAMETER - which is subsumed in the more general TYPE_USE. In the Checker Framework, we interpret @TA as an annotation on the implicit lower bound of type variable T. @TB is an annotation on the upper bound of T. Fields field1 and field2 have different types. The type of field1 is the normal use of the type variable and behaves like a type variable in Java. The type of field2 gives a more specific type annotation, @TC, that should override any annotations from T. As a concrete example, let's consider a Nullness type system with annotations @Nullable and @NonNull, where a @NonNull reference is a subtype of a @Nullable reference. We can imagine a class: class Box<@NonNull T extends @Nullable Object> { T f1; @Nullable T f2; void foo() { f1 = null; // error f2 = null; // valid } } The lower bound of T is @NonNull and the upper bound is @Nullable - any instantiation is allowed. The first assignment must be forbidden: the concrete instantiation of Box might be "Box<@NonNull String>" ; allowing the assignment of the null value into field f1 would be unsound. However, the type of field f2 declares that null is always a valid value and therefore the assignment to f2 is valid. This is the interpretation that we are using in the Checker Framework. However, making the distinction between type parameter declarations and type variable uses is a general one and allowing different type annotations on them seems generally useful. Does this explanation help? cu, WMD. On Sep 11, 2013 10:39 PM, "Srikanth S Adayapalam" < srikanth_sankaran at in.ibm.com> wrote: > Hello ! > > I am trying to understand if there are valid scenarios where type > annotating the use of a type > variable actually makes sense. The following program compiles fine with > both eclipse and > javac 8b100: > > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > > @Target(ElementType.TYPE_USE) > @interface TA { > } > @Target(ElementType.TYPE_USE) > @interface TB { > } > > public abstract class X<@TA T> { > > @TB T t; > } > > Studying this test case, since both occurrence of T would denote the > same type instantiation, does it make sense to think of "only @TA > annotated T" and "only @TB annotated T" ? > > Shouldn't the language insist that they be consolidated and presented all > at the declaration site ? > > Have I overlooked any valid scenarios where this would actually make sense > ? > > Thanks! > Srikanth > From alex.buckley at oracle.com Thu Sep 12 14:06:26 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 12 Sep 2013 14:06:26 -0700 Subject: [type-annos-observers] Should JSR308 forbid type annotations on uses of a type parameter ? In-Reply-To: References: Message-ID: <52322CD2.60606@oracle.com> Werner, thanks for this explanation. Perhaps if the idea of a different model for annotations on type parameters and type variables had been raised 18 months ago, the EG could have considered it. But right now, JSR 308 is in the "endgame". The JDK 8 Developer Preview is out and we just hit the "All Tests Run" milestone today [1]. Early next month, all interfaces will be frozen and the SE JSRs will start Public Review [2]. What would help the most is to review the detailed wording of the Java Language Spec and JVM Spec draft I sent out last month. Alex [1] http://openjdk.java.net/projects/jdk8/milestones [2] http://openjdk.java.net/projects/jdk8/spec/. On 9/12/2013 2:27 AM, Werner Dietl wrote: > Hi Srikanth, > > For the use in type systems, having the distinction between type parameter > declarations and type variable uses is necessary. > > The Checker Framework manual dedicates a section discussing this > interaction: > http://types.cs.washington.edu/checker-framework/current/checkers-manual.html#generics > > In brief, one can imagine: > > class C<@TA T extends @TB Upper> { > T field1; > @TC T field2; > } > > Note that @TA can have @Target meta-annotation TYPE_PARAMETER - which is > subsumed in the more general TYPE_USE. > > In the Checker Framework, we interpret @TA as an annotation on the > implicit lower bound of type variable T. > @TB is an annotation on the upper bound of T. > > Fields field1 and field2 have different types. > The type of field1 is the normal use of the type variable and behaves like > a type variable in Java. > The type of field2 gives a more specific type annotation, @TC, that should > override any annotations from T. > > As a concrete example, let's consider a Nullness type system with > annotations @Nullable and @NonNull, where a @NonNull reference is a subtype > of a @Nullable reference. > > We can imagine a class: > > class Box<@NonNull T extends @Nullable Object> { > T f1; > @Nullable T f2; > > void foo() { > f1 = null; // error > f2 = null; // valid > } > } > > The lower bound of T is @NonNull and the upper bound is @Nullable - any > instantiation is allowed. > > The first assignment must be forbidden: the concrete instantiation of Box > might be "Box<@NonNull String>" ; allowing the assignment of the null value > into field f1 would be unsound. > However, the type of field f2 declares that null is always a valid value > and therefore the assignment to f2 is valid. > > This is the interpretation that we are using in the Checker Framework. > However, making the distinction between type parameter declarations and > type variable uses is a general one and allowing different type annotations > on them seems generally useful. > > Does this explanation help? > cu, WMD. > On Sep 11, 2013 10:39 PM, "Srikanth S Adayapalam" < > srikanth_sankaran at in.ibm.com> wrote: > >> Hello ! >> >> I am trying to understand if there are valid scenarios where type >> annotating the use of a type >> variable actually makes sense. The following program compiles fine with >> both eclipse and >> javac 8b100: >> >> import java.lang.annotation.ElementType; >> import java.lang.annotation.Target; >> >> @Target(ElementType.TYPE_USE) >> @interface TA { >> } >> @Target(ElementType.TYPE_USE) >> @interface TB { >> } >> >> public abstract class X<@TA T> { >> >> @TB T t; >> } >> >> Studying this test case, since both occurrence of T would denote the >> same type instantiation, does it make sense to think of "only @TA >> annotated T" and "only @TB annotated T" ? >> >> Shouldn't the language insist that they be consolidated and presented all >> at the declaration site ? >> >> Have I overlooked any valid scenarios where this would actually make sense >> ? >> >> Thanks! >> Srikanth >> From srikanth_sankaran at in.ibm.com Mon Sep 16 22:36:37 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 17 Sep 2013 11:06:37 +0530 Subject: [type-annos-observers] Should JSR308 forbid type annotations on uses of a type parameter ? In-Reply-To: <52322CD2.60606@oracle.com> References: <52322CD2.60606@oracle.com> Message-ID: Werner, Thanks, I can see the rationale/use cases now. Alex, point noted. Thanks! Srikanth type-annotations-spec-experts-bounces at openjdk.java.net wrote on 09/13/2013 02:36:26 AM: > From: Alex Buckley > To: type-annotations-spec-experts experts at openjdk.java.net>, > Date: 09/13/2013 02:35 AM > Subject: Re: [type-annos-observers] Should JSR308 forbid type > annotations on uses of a type parameter ? > Sent by: type-annotations-spec-experts-bounces at openjdk.java.net > > Werner, thanks for this explanation. > > Perhaps if the idea of a different model for annotations on type > parameters and type variables had been raised 18 months ago, the EG > could have considered it. But right now, JSR 308 is in the "endgame". > The JDK 8 Developer Preview is out and we just hit the "All Tests Run" > milestone today [1]. Early next month, all interfaces will be frozen and > the SE JSRs will start Public Review [2]. What would help the most is to > review the detailed wording of the Java Language Spec and JVM Spec draft > I sent out last month. > > Alex > > [1] http://openjdk.java.net/projects/jdk8/milestones > [2] http://openjdk.java.net/projects/jdk8/spec/. > > On 9/12/2013 2:27 AM, Werner Dietl wrote: > > Hi Srikanth, > > > > For the use in type systems, having the distinction between type parameter > > declarations and type variable uses is necessary. > > > > The Checker Framework manual dedicates a section discussing this > > interaction: > > http://types.cs.washington.edu/checker-framework/current/checkers- > manual.html#generics > > > > In brief, one can imagine: > > > > class C<@TA T extends @TB Upper> { > > T field1; > > @TC T field2; > > } > > > > Note that @TA can have @Target meta-annotation TYPE_PARAMETER - which is > > subsumed in the more general TYPE_USE. > > > > In the Checker Framework, we interpret @TA as an annotation on the > > implicit lower bound of type variable T. > > @TB is an annotation on the upper bound of T. > > > > Fields field1 and field2 have different types. > > The type of field1 is the normal use of the type variable and behaves like > > a type variable in Java. > > The type of field2 gives a more specific type annotation, @TC, that should > > override any annotations from T. > > > > As a concrete example, let's consider a Nullness type system with > > annotations @Nullable and @NonNull, where a @NonNull reference is a subtype > > of a @Nullable reference. > > > > We can imagine a class: > > > > class Box<@NonNull T extends @Nullable Object> { > > T f1; > > @Nullable T f2; > > > > void foo() { > > f1 = null; // error > > f2 = null; // valid > > } > > } > > > > The lower bound of T is @NonNull and the upper bound is @Nullable - any > > instantiation is allowed. > > > > The first assignment must be forbidden: the concrete instantiation of Box > > might be "Box<@NonNull String>" ; allowing the assignment of the null value > > into field f1 would be unsound. > > However, the type of field f2 declares that null is always a valid value > > and therefore the assignment to f2 is valid. > > > > This is the interpretation that we are using in the Checker Framework. > > However, making the distinction between type parameter declarations and > > type variable uses is a general one and allowing different type annotations > > on them seems generally useful. > > > > Does this explanation help? > > cu, WMD. > > On Sep 11, 2013 10:39 PM, "Srikanth S Adayapalam" < > > srikanth_sankaran at in.ibm.com> wrote: > > > >> Hello ! > >> > >> I am trying to understand if there are valid scenarios where type > >> annotating the use of a type > >> variable actually makes sense. The following program compiles fine with > >> both eclipse and > >> javac 8b100: > >> > >> import java.lang.annotation.ElementType; > >> import java.lang.annotation.Target; > >> > >> @Target(ElementType.TYPE_USE) > >> @interface TA { > >> } > >> @Target(ElementType.TYPE_USE) > >> @interface TB { > >> } > >> > >> public abstract class X<@TA T> { > >> > >> @TB T t; > >> } > >> > >> Studying this test case, since both occurrence of T would denote the > >> same type instantiation, does it make sense to think of "only @TA > >> annotated T" and "only @TB annotated T" ? > >> > >> Shouldn't the language insist that they be consolidated and presented all > >> at the declaration site ? > >> > >> Have I overlooked any valid scenarios where this would actually make sense > >> ? > >> > >> Thanks! > >> Srikanth > >> > From timo.kinnunen at gmail.com Wed Sep 18 12:01:13 2013 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Wed, 18 Sep 2013 22:01:13 +0300 Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> Message-ID: This is a repost of a comment from Mark Reinhold?s blog with additional comments below. I have to agree, both Lambdas and Type Annotations that I've been looking forward to don't look very Java-like at all. Lambdas add ugly syntax and Type Annotations break the simplicity of nested scoping. I'd love to see a list of what other options the EG considered and why they were rejected for what we have currently when Public Review phase starts. Here's Lambda with -> syntax: list.stream().map((Runnable runnable) -> { new Thread(runnable) } ).forEach(thread -> thread.start()); Why "->" when "for" is just as many keys to press and no key-combinations: list.stream().map(for(Runnable runnable) { new Thread(runnable) } ).forEach(for thread thread.start()); And Type Annotations, just look at this method signature: void innerMethod(@Any Outer. at Backer Middle. at Counted Inner this, @Any Outer. at Backer Middle. at Nullable @Counted Inner other) { ... } How do you suppose a word-wrapping text-editor would think they are grouped? Care to guess if it matches how they group semantically? Yep, the empty " " character is now more significant than the "." character, which is unbelievable. And if that wasn't enough, Type Annotations also lets you express the difference between annotations applied to a parameter and annotations applied to the type of the parameter. Here's how an annotation is applied to the parameter: void callingJava7Way(@Regarding Example oldOne) { ... } And to make the annotation apply to the type of the parameter, you do this: callingJava8Way(com.somecompany.AnnotationTestBed. at Regarding Example newOne) { ... } That has got to be the most verbose modifier of another modifier I've ever seen in any programming language ever and whoever came up with it deserves some sort of a prize. Alex Buckley replied: ?You don't have to use qualified names with type annotations. To write an annotation on the type of a formal parameter, as opposed to the declaration of the formal parameter, you just add @Target(ElementType.TYPE_USE) to the annotation's own type declaration. Then, "@Regarding Example oldOne" means @Regarding applies to this particular use of the Example type, rather than to the oldOne declaration. More comments on type annotations? Send them to the type-annotations-spec-comments at OpenJDK.? Alex, there might be bugs or unimplemented changes, but trying it out in the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation @Regarding defined like this: @Retention(value = RetentionPolicy.RUNTIME) @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER, ElementType.FIELD, ElementType.LOCAL_VARIABLE}) @interface Regarding { } Then as seen in the Trees (NetBeans development) view, right now you do have to write ?com.somecompany.AnnotationTestBed.? in front of the annotation to modify the modifier into becoming an annotated type instead. Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be 0xMODIFIER, 1xANNOTATED_TYPE. I don?t know where this change in semantics comes from or what its meaning is, but I can see that it?s there. And as long as it is there, it can become requirement for using some functionality in any tool that can detect its presence. -- Have a nice day, Timo Kinnunen From alex.buckley at oracle.com Wed Sep 18 15:27:05 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 18 Sep 2013 15:27:05 -0700 Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> Message-ID: <523A28B9.40702@oracle.com> David, It looks like there is a problem with how NetBeans handles annotations on type names. I confess to not knowing which NetBeans engineer is working on type annotations, so please inform them of the problem below. Timo, On 9/18/2013 12:01 PM, Timo Kinnunen wrote: > Alex, there might be bugs or unimplemented changes, but trying it out in > the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation > @Regarding defined like this: > > @Retention(value = RetentionPolicy.RUNTIME) > @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER, > ElementType.FIELD, ElementType.LOCAL_VARIABLE}) > @interface Regarding { } > > Then as seen in the Trees (NetBeans development) view, right now you do > have to write ?com.somecompany.AnnotationTestBed.? in front of the > annotation to modify the modifier into becoming an annotated type instead. > Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be 0xMODIFIER, > 1xANNOTATED_TYPE. > > I don?t know where this change in semantics comes from or what its meaning > is, but I can see that it?s there. And as long as it is there, it can > become requirement for using some functionality in any tool that can detect > its presence. I'm on JDK 1.8.0-ea-b106. Here's a simplified test case: -- import java.lang.annotation.*; @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.PARAMETER}) @interface Regarding { } public class C { void m(@Regarding Object oldOne) {} } -- javac will emit C.class with a RuntimeVisibleParameterAnnotations attribute for the 'm' method, just as it did in JDK7. Then, if you add ElementType.TYPE_USE to the @Target value: @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) and recompile, javac will emit C.class with a second attribute, RuntimeVisibleTypeAnnotations, for the 'm' method. There are no surprises here, and no need for qualified type names. If you really want to write "java.lang. at Regarding Object oldOne", you can, and it's compiled correctly to just RuntimeVisibleTypeAnnotations - no RuntimeVisibleParameterAnnotations in sight. But you don't have to. Alex From mernst at cs.washington.edu Thu Sep 19 08:47:34 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 19 Sep 2013 08:47:34 -0700 (PDT) Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> Message-ID: <20130919.084734.1411738307279943122.mernst@cs.washington.edu> Timo- It's possible to write ugly code in any programming language, including Java 7 -- just like it is possible to write ugly prose or specious arguments in any natural language. That says nothing about the language or its design. You are incorrect in claiming that fully-qualified names are required for type annotations. If your argument is predicated on this incorrect assumption (or on a bug in some specific tool), then your arguments are invalid. Would it be possible to base a discussion on the specification (or even to double-check against the reference implementation)? If you have concerns about a NetBeans bug or about the syntax of lambda, please direct those elsewhere; they don't belong on this list. Thanks! -Mike > Subject: Type annotations don't look very Java-like > From: Timo Kinnunen > To: type-annotations-spec-comments at openjdk.java.net > Date: Wed, 18 Sep 2013 22:01:13 +0300 > > This is a repost of a comment from Mark Reinhold?s blog with additional > comments below. > > I have to agree, both Lambdas and Type Annotations that I've been looking > forward to don't look very Java-like at all. Lambdas add ugly syntax and > Type Annotations break the simplicity of nested scoping. > I'd love to see a list of what other options the EG considered and why > they > were rejected for what we have currently when Public Review phase starts. > > Here's Lambda with -> syntax: > > list.stream().map((Runnable runnable) -> { new Thread(runnable) } > ).forEach(thread -> thread.start()); > > Why "->" when "for" is just as many keys to press and no > key-combinations: > > list.stream().map(for(Runnable runnable) { new Thread(runnable) } > ).forEach(for thread thread.start()); > > And Type Annotations, just look at this method signature: > > void innerMethod(@Any Outer. at Backer Middle. at Counted Inner this, @Any > Outer. at Backer Middle. at Nullable @Counted Inner other) { ... } > > How do you suppose a word-wrapping text-editor would think they are > grouped? Care to guess if it matches how they group semantically? Yep, > the > empty " " character is now more significant than the "." character, which > is unbelievable. > > And if that wasn't enough, Type Annotations also lets you express the > difference between annotations applied to a parameter and annotations > applied to the type of the parameter. Here's how an annotation is applied > to the parameter: > > void callingJava7Way(@Regarding Example oldOne) { ... } > > And to make the annotation apply to the type of the parameter, you do > this: > > callingJava8Way(com.somecompany.AnnotationTestBed. at Regarding Example > newOne) { ... } > > That has got to be the most verbose modifier of another modifier I've > ever > seen in any programming language ever and whoever came up with it > deserves > some sort of a prize. > > Alex Buckley replied: > ?You don't have to use qualified names with type annotations. To write an > annotation on the type of a formal parameter, as opposed to the > declaration > of the formal parameter, you just add @Target(ElementType.TYPE_USE) to > the > annotation's own type declaration. Then, "@Regarding Example oldOne" > means > @Regarding applies to this particular use of the Example type, rather > than > to the oldOne declaration. > > More comments on type annotations? Send them to the > type-annotations-spec-comments at OpenJDK.? > > Alex, there might be bugs or unimplemented changes, but trying it out in > the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation > @Regarding defined like this: > > @Retention(value = RetentionPolicy.RUNTIME) > @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER, > ElementType.FIELD, ElementType.LOCAL_VARIABLE}) > @interface Regarding { } > > Then as seen in the Trees (NetBeans development) view, right now you do > have to write ?com.somecompany.AnnotationTestBed.? in front of the > annotation to modify the modifier into becoming an annotated type > instead. > Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be > 0xMODIFIER, > 1xANNOTATED_TYPE. > > I don?t know where this change in semantics comes from or what its > meaning > is, but I can see that it?s there. And as long as it is there, it can > become requirement for using some functionality in any tool that can > detect > its presence. > > > > -- > Have a nice day, > Timo Kinnunen From timo.kinnunen at gmail.com Wed Sep 18 20:47:16 2013 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Thu, 19 Sep 2013 06:47:16 +0300 Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: <523A28B9.40702@oracle.com> References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> <523A28B9.40702@oracle.com> Message-ID: Hi, First, please correct me if I'm wrong, but it's my understanding that in Java 8 I be able to express 1) an annotation on a parameter ONLY 2) an annotation on a parameter and its type BOTH 3) an annotation on the type of a parameter ONLY and that each of these be distinguishable from the others, for annotation processing purposes, for example. Assuming the above, it strikes me that the changed grammar in addition to not looking very Java-like is also not expressive enough for the cases 1, 2, 3 above. Suppose I'm writing my magnum opus, a class to solve the problem of two lists in the standard library, the List: public final class List { public static void bridge(List manager, java.util.List container, java.awt.List viewer) { manager.bridge(container, viewer); } public void bridge(List this, java.util.List container, java.awt.List viewer) { // TODO } } @Retention(value = RetentionPolicy.RUNTIME) @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) public @interface Important { } I want to annotate both of the bridge-methods with identical annotations for consistency. 1) The first parameter List I want to have @Important on the parameter only. 2) For the other parameters I want one of them to have the annotation @Important on both parameter and type and the other one have @Important on type only. Neither of these are possible. The case 1 is not possible for two reasons. First because there is no modifier that can make { TYPE_USE, PARAMETER } be treated as { PARAMETER }. Second because a receiver can't be annotated with a parameter annotation, unlike its static counterpart. This forces an inconsistency onto this class design. The case 2 is not possible because it's not possible to express the difference. Annotating one parameter as @Important java.util.List and the other as java.awt. at Important List is not allowed. The grammar can't express the case where the verbose modifier-modifier was used to make { TYPE_USE, PARAMETER } be treated as { TYPE_USE } when the type is a fully-qualified name rather than a simple name. In other words, there is no way to write java.util. at Important java.util.List. Thankfully, one might say. Or mercifully. Interestingly, it is possible and required to write @Important java.util.List if @Important doesn't have TYPE_USE. Which means adding TYPE_USE to an existing annotation in a library can cause compile errors when Java 7 code switches to compiling against a Java 8 version of the library. I think some other mechanism is needed to put annotations on their types because I don't think these grammar changes are very well suited for that at all. On Thu, Sep 19, 2013 at 1:27 AM, Alex Buckley wrote: > David, > > It looks like there is a problem with how NetBeans handles annotations on > type names. I confess to not knowing which NetBeans engineer is working on > type annotations, so please inform them of the problem below. > > Timo, > > > On 9/18/2013 12:01 PM, Timo Kinnunen wrote: > >> Alex, there might be bugs or unimplemented changes, but trying it out in >> the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation >> @Regarding defined like this: >> >> @Retention(value = RetentionPolicy.RUNTIME) >> @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER, >> ElementType.FIELD, ElementType.LOCAL_VARIABLE}) >> @interface Regarding { } >> >> Then as seen in the Trees (NetBeans development) view, right now you do >> have to write ?com.somecompany.**AnnotationTestBed.? in front of the >> annotation to modify the modifier into becoming an annotated type instead. >> Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be >> 0xMODIFIER, >> 1xANNOTATED_TYPE. >> >> I don?t know where this change in semantics comes from or what its meaning >> is, but I can see that it?s there. And as long as it is there, it can >> become requirement for using some functionality in any tool that can >> detect >> its presence. >> > > I'm on JDK 1.8.0-ea-b106. Here's a simplified test case: > > -- > import java.lang.annotation.*; > > @Retention(RetentionPolicy.**RUNTIME) > @Target({ElementType.**PARAMETER}) > @interface Regarding { } > > public class C { > void m(@Regarding Object oldOne) {} > } > -- > > javac will emit C.class with a RuntimeVisibleParameterAnnotat**ions > attribute for the 'm' method, just as it did in JDK7. > > Then, if you add ElementType.TYPE_USE to the @Target value: > > @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) > > and recompile, javac will emit C.class with a second attribute, > RuntimeVisibleTypeAnnotations, for the 'm' method. There are no surprises > here, and no need for qualified type names. > > If you really want to write "java.lang. at Regarding Object oldOne", you > can, and it's compiled correctly to just RuntimeVisibleTypeAnnotations - no > RuntimeVisibleParameterAnnotat**ions in sight. But you don't have to. > > Alex > -- Have a nice day, Timo Kinnunen From timo.kinnunen at gmail.com Thu Sep 19 09:28:30 2013 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Thu, 19 Sep 2013 19:28:30 +0300 Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> <523A28B9.40702@oracle.com> Message-ID: Hi, A small correction to case 2 presented in this: "I want to annotate both of the bridge-methods with identical annotations for consistency. 1) The first parameter List I want to have @Important on the parameter only. 2) For the other parameters I want one of them to have the annotation @Important on both parameter and type and the other one have @Important on type only. Neither of these are possible." It seems I was wrong about case 2 and it is possible after all. Here's what the method looks like: public final class List { public void genericBridge( List this, java.util. at Important List container, @Important java_awt_List viewer) { // TODO } } This produces the following javap -v -p -s output that satisfies the requirement for case 2: RuntimeVisibleTypeAnnotations: 0: #24(): METHOD_FORMAL_PARAMETER, param_index=1 1: #24(): METHOD_FORMAL_PARAMETER, param_index=0 RuntimeVisibleParameterAnnotations: parameter 0: parameter 1: 0: #24() Is this working as designed or a bit of generics type programming? On Thu, Sep 19, 2013 at 6:47 AM, Timo Kinnunen wrote: > Hi, > > First, please correct me if I'm wrong, but it's my understanding that in > Java 8 I be able to express > > 1) an annotation on a parameter ONLY > 2) an annotation on a parameter and its type BOTH > 3) an annotation on the type of a parameter ONLY > > and that each of these be distinguishable from the others, for annotation > processing purposes, for example. > > Assuming the above, it strikes me that the changed grammar in addition to > not looking very Java-like is also not expressive enough for the cases 1, > 2, 3 above. Suppose I'm writing my magnum opus, a class to solve the > problem of two lists in the standard library, the List: > > public final class List { > public static void bridge(List manager, java.util.List container, > java.awt.List viewer) { > manager.bridge(container, viewer); > } > public void bridge(List this, java.util.List container, java.awt.List > viewer) { > // TODO > } > } > @Retention(value = RetentionPolicy.RUNTIME) > @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) > public @interface Important { > } > I want to annotate both of the bridge-methods with identical annotations > for consistency. > > 1) The first parameter List I want to have @Important on the parameter > only. > > 2) For the other parameters I want one of them to have the annotation > @Important on both parameter and type and the other one have @Important on > type only. > > Neither of these are possible. > > The case 1 is not possible for two reasons. First because there is no > modifier that can make { TYPE_USE, PARAMETER } be treated as { PARAMETER }. > Second because a receiver can't be annotated with a parameter annotation, > unlike its static counterpart. This forces an inconsistency onto this class > design. > > The case 2 is not possible because it's not possible to express the > difference. Annotating one parameter as @Important java.util.List and the > other as java.awt. at Important List is not allowed. The grammar can't > express the case where the verbose modifier-modifier was used to make { > TYPE_USE, PARAMETER } be treated as { TYPE_USE } when the type is a > fully-qualified name rather than a simple name. In other words, there is no > way to write java.util. at Important java.util.List. Thankfully, one might > say. Or mercifully. > > Interestingly, it is possible and required to write @Important > java.util.List if @Important doesn't have TYPE_USE. Which means adding > TYPE_USE to an existing annotation in a library can cause compile errors > when Java 7 code switches to compiling against a Java 8 version of the > library. > > I think some other mechanism is needed to put annotations on their types > because I don't think these grammar changes are very well suited for > that at all. > > > > > > > > On Thu, Sep 19, 2013 at 1:27 AM, Alex Buckley wrote: > >> David, >> >> It looks like there is a problem with how NetBeans handles annotations on >> type names. I confess to not knowing which NetBeans engineer is working on >> type annotations, so please inform them of the problem below. >> >> Timo, >> >> >> On 9/18/2013 12:01 PM, Timo Kinnunen wrote: >> >>> Alex, there might be bugs or unimplemented changes, but trying it out in >>> the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation >>> @Regarding defined like this: >>> >>> @Retention(value = RetentionPolicy.RUNTIME) >>> @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER, >>> ElementType.FIELD, ElementType.LOCAL_VARIABLE}) >>> @interface Regarding { } >>> >>> Then as seen in the Trees (NetBeans development) view, right now you do >>> have to write ?com.somecompany.**AnnotationTestBed.? in front of the >>> annotation to modify the modifier into becoming an annotated type >>> instead. >>> Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be >>> 0xMODIFIER, >>> 1xANNOTATED_TYPE. >>> >>> I don?t know where this change in semantics comes from or what its >>> meaning >>> is, but I can see that it?s there. And as long as it is there, it can >>> become requirement for using some functionality in any tool that can >>> detect >>> its presence. >>> >> >> I'm on JDK 1.8.0-ea-b106. Here's a simplified test case: >> >> -- >> import java.lang.annotation.*; >> >> @Retention(RetentionPolicy.**RUNTIME) >> @Target({ElementType.**PARAMETER}) >> @interface Regarding { } >> >> public class C { >> void m(@Regarding Object oldOne) {} >> } >> -- >> >> javac will emit C.class with a RuntimeVisibleParameterAnnotat**ions >> attribute for the 'm' method, just as it did in JDK7. >> >> Then, if you add ElementType.TYPE_USE to the @Target value: >> >> @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) >> >> and recompile, javac will emit C.class with a second attribute, >> RuntimeVisibleTypeAnnotations, for the 'm' method. There are no surprises >> here, and no need for qualified type names. >> >> If you really want to write "java.lang. at Regarding Object oldOne", you >> can, and it's compiled correctly to just RuntimeVisibleTypeAnnotations - no >> RuntimeVisibleParameterAnnotat**ions in sight. But you don't have to. >> >> Alex >> > > > > -- > Have a nice day, > Timo Kinnunen > -- Have a nice day, Timo Kinnunen +358445405900, +37258352396 From alex.buckley at oracle.com Thu Sep 19 10:48:59 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Sep 2013 10:48:59 -0700 Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> <523A28B9.40702@oracle.com> Message-ID: <523B390B.102@oracle.com> On 9/18/2013 8:47 PM, Timo Kinnunen wrote: > First, please correct me if I'm wrong, but it's my understanding that in > Java 8 I be able to express > 1) an annotation on a parameter ONLY > 2) an annotation on a parameter and its type BOTH > 3) an annotation on the type of a parameter ONLY > and that each of these be distinguishable from the others, for > annotation processing purposes, for example. 1) @Target(ElementType.PARAMETER) 2) @Target({ElementType.PARAMETER, ElementType.TYPE_USE}) 3) @Target(ElementType.TYPE_USE) There is very little syntactic "real estate" in which to annotate formal parameters. In the case of (2), JSR 308 interprets an annotation as annotating both the type and the declaration of the parameter. Your use cases require more expressiveness at the annotation type level, but they seem rather contrived and no-one brought similar cases to the Expert Group in over five years. This is not the first time that annotations have been less flexible than people hoped, and it won't be the last. > Interestingly, it is possible and required to write @Important > java.util.List if @Important doesn't have TYPE_USE. Which means adding > TYPE_USE to an existing annotation in a library can cause compile errors > when Java 7 code switches to compiling against a Java 8 version of the > library. You've found another bug. Adding TYPE_USE to an annotation type's targets should _not_ break annotations on variable declarations (field, local, formal parameter) whose types are qualified names, nor on method declarations whose return types are qualified names. javac is misinterpreting the package name part of the qualified name as a "scoping mechanism". From the JSR 308 spec: @Target({TYPE_USE}) @interface TAnno { } @Target({FIELD, TYPE_USE}) @interface FTAnno { } @TAnno java.lang.Object field8; // illegal @FTAnno java.lang.Object field9; // legal, one field annotation Alex From alex.buckley at oracle.com Thu Sep 19 10:52:12 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Sep 2013 10:52:12 -0700 Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> <523A28B9.40702@oracle.com> Message-ID: <523B39CC.6010606@oracle.com> Yes, this is working as designed. Your first @Important is a type annotation, so goes into RuntimeVisibleTypeAnnotations; your second @Important is both a type annotation and a declaration annotation, so goes into RuntimeVisibleTypeAnnotations and RuntimeVisibleParameterAnnotations. Alex On 9/19/2013 9:28 AM, Timo Kinnunen wrote: > Hi, > > A small correction to case 2 presented in this: > > "I want to annotate both of the bridge-methods with identical annotations > for consistency. > > 1) The first parameter List I want to have @Important on the parameter only. > > 2) For the other parameters I want one of them to have the annotation > @Important on both parameter and type and the other one have @Important on > type only. > > Neither of these are possible." > > It seems I was wrong about case 2 and it is possible after all. Here's what > the method looks like: > > public final class List { > public void genericBridge( > List this, > java.util. at Important List container, > @Important java_awt_List viewer) { > // TODO > } > } > This produces the following javap -v -p -s output that satisfies the > requirement for case 2: > > RuntimeVisibleTypeAnnotations: > 0: #24(): METHOD_FORMAL_PARAMETER, param_index=1 > 1: #24(): METHOD_FORMAL_PARAMETER, param_index=0 > RuntimeVisibleParameterAnnotations: > parameter 0: > parameter 1: > 0: #24() > > > Is this working as designed or a bit of generics type programming? > > > > > On Thu, Sep 19, 2013 at 6:47 AM, Timo Kinnunen wrote: > >> Hi, >> >> First, please correct me if I'm wrong, but it's my understanding that in >> Java 8 I be able to express >> >> 1) an annotation on a parameter ONLY >> 2) an annotation on a parameter and its type BOTH >> 3) an annotation on the type of a parameter ONLY >> >> and that each of these be distinguishable from the others, for annotation >> processing purposes, for example. >> >> Assuming the above, it strikes me that the changed grammar in addition to >> not looking very Java-like is also not expressive enough for the cases 1, >> 2, 3 above. Suppose I'm writing my magnum opus, a class to solve the >> problem of two lists in the standard library, the List: >> >> public final class List { >> public static void bridge(List manager, java.util.List container, >> java.awt.List viewer) { >> manager.bridge(container, viewer); >> } >> public void bridge(List this, java.util.List container, java.awt.List >> viewer) { >> // TODO >> } >> } >> @Retention(value = RetentionPolicy.RUNTIME) >> @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) >> public @interface Important { >> } >> I want to annotate both of the bridge-methods with identical annotations >> for consistency. >> >> 1) The first parameter List I want to have @Important on the parameter >> only. >> >> 2) For the other parameters I want one of them to have the annotation >> @Important on both parameter and type and the other one have @Important on >> type only. >> >> Neither of these are possible. >> >> The case 1 is not possible for two reasons. First because there is no >> modifier that can make { TYPE_USE, PARAMETER } be treated as { PARAMETER }. >> Second because a receiver can't be annotated with a parameter annotation, >> unlike its static counterpart. This forces an inconsistency onto this class >> design. >> >> The case 2 is not possible because it's not possible to express the >> difference. Annotating one parameter as @Important java.util.List and the >> other as java.awt. at Important List is not allowed. The grammar can't >> express the case where the verbose modifier-modifier was used to make { >> TYPE_USE, PARAMETER } be treated as { TYPE_USE } when the type is a >> fully-qualified name rather than a simple name. In other words, there is no >> way to write java.util. at Important java.util.List. Thankfully, one might >> say. Or mercifully. >> >> Interestingly, it is possible and required to write @Important >> java.util.List if @Important doesn't have TYPE_USE. Which means adding >> TYPE_USE to an existing annotation in a library can cause compile errors >> when Java 7 code switches to compiling against a Java 8 version of the >> library. >> >> I think some other mechanism is needed to put annotations on their types >> because I don't think these grammar changes are very well suited for >> that at all. >> >> >> >> >> >> >> >> On Thu, Sep 19, 2013 at 1:27 AM, Alex Buckley wrote: >> >>> David, >>> >>> It looks like there is a problem with how NetBeans handles annotations on >>> type names. I confess to not knowing which NetBeans engineer is working on >>> type annotations, so please inform them of the problem below. >>> >>> Timo, >>> >>> >>> On 9/18/2013 12:01 PM, Timo Kinnunen wrote: >>> >>>> Alex, there might be bugs or unimplemented changes, but trying it out in >>>> the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation >>>> @Regarding defined like this: >>>> >>>> @Retention(value = RetentionPolicy.RUNTIME) >>>> @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER, >>>> ElementType.FIELD, ElementType.LOCAL_VARIABLE}) >>>> @interface Regarding { } >>>> >>>> Then as seen in the Trees (NetBeans development) view, right now you do >>>> have to write ?com.somecompany.**AnnotationTestBed.? in front of the >>>> annotation to modify the modifier into becoming an annotated type >>>> instead. >>>> Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be >>>> 0xMODIFIER, >>>> 1xANNOTATED_TYPE. >>>> >>>> I don?t know where this change in semantics comes from or what its >>>> meaning >>>> is, but I can see that it?s there. And as long as it is there, it can >>>> become requirement for using some functionality in any tool that can >>>> detect >>>> its presence. >>>> >>> >>> I'm on JDK 1.8.0-ea-b106. Here's a simplified test case: >>> >>> -- >>> import java.lang.annotation.*; >>> >>> @Retention(RetentionPolicy.**RUNTIME) >>> @Target({ElementType.**PARAMETER}) >>> @interface Regarding { } >>> >>> public class C { >>> void m(@Regarding Object oldOne) {} >>> } >>> -- >>> >>> javac will emit C.class with a RuntimeVisibleParameterAnnotat**ions >>> attribute for the 'm' method, just as it did in JDK7. >>> >>> Then, if you add ElementType.TYPE_USE to the @Target value: >>> >>> @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) >>> >>> and recompile, javac will emit C.class with a second attribute, >>> RuntimeVisibleTypeAnnotations, for the 'm' method. There are no surprises >>> here, and no need for qualified type names. >>> >>> If you really want to write "java.lang. at Regarding Object oldOne", you >>> can, and it's compiled correctly to just RuntimeVisibleTypeAnnotations - no >>> RuntimeVisibleParameterAnnotat**ions in sight. But you don't have to. >>> >>> Alex >>> >> >> >> >> -- >> Have a nice day, >> Timo Kinnunen >> > > > From timo.kinnunen at gmail.com Mon Sep 23 14:03:26 2013 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Tue, 24 Sep 2013 00:03:26 +0300 Subject: [type-annos-observers] Type annotations don't look very Java-like In-Reply-To: <20130919.084734.1411738307279943122.mernst@cs.washington.edu> References: <5239f0c6.4b09b50a.07d7.2ff5@mx.google.com> <20130919.084734.1411738307279943122.mernst@cs.washington.edu> Message-ID: Hi, On Thu, Sep 19, 2013 at 6:47 PM, Michael Ernst wrote: > Timo- > > It's possible to write ugly code in any programming language, including > Java 7 -- just like it is possible to write ugly prose or specious > arguments in any natural language. That says nothing about the language or > its design. > I didn't set out to make the code as ugly as possible, in fact the only stylistic choice that could be argued to have been more ugly than the alternative was the choice of putting @Nullable before @Counted rather than the other way around. Other than that the samples are just using Type Annotations to annotate types. In fact the method void innerMethod(@Any Outer. at Backer Middle. at Counted Inner this, @Any Outer. at Backer Middle. at Nullable @Counted Inner other) { ... } is the example method from JSR308 Specification section 2.1 with a second @Nullable parameter and written using plausible real-world names: class Outer { class Middle { class Inner { void innerMethod(@A Outer. at B Middle. at C Inner this) { ... } } } } Likewise the methods callingJava7Way(@Regarding Example oldOne) { ... } callingJava8Way(com.**somecompany.AnnotationTestBed.**@Regarding Example newOne) { ... } are written using plausible names with the parameters adapted from a field annotation example from JSR308 Specification section 2.3: @FAnno Object field4; // legal, one field annotation java.lang. @FTAnno Object field12 // legal, one type annotation That said, I agree with you that the code looks ugly. It is unfortunate that - given how much potential Type Annotations have - the grammar makes code using Type Annotations in some circumstances really ugly. > > You are incorrect in claiming that fully-qualified names are required for > type annotations. If your argument is predicated on this incorrect > assumption (or on a bug in some specific tool), then your arguments are > invalid. Would it be possible to base a discussion on the specification > (or even to double-check against the reference implementation)? > If you are writing your own annotations and can write them freely any way you want then fully-qualified names are not necessary. If you are using someone else's annotations and need to coax some specific combination out of javac then not only do you need to use fully qualified names in one case (field12), you need to use generics in another case (field15): public class Object { @FAnno Object field4; // legal, one field annotation @TAnno Object field5; // legal, one type annotation @FTAnno Object field6; // legal, one field annotation and one type annotation @FAnno java.lang.Object field7; // legal, one field annotation //@TAnno java.lang.Object field8; // illegal //@FTAnno java.lang.Object field9; // doesn't work in b106, but legal, one field annotation //java.lang. at FAnno Object field10; // illegal java.lang. at TAnno Object field11; // legal, one type annotation java.lang. at FTAnno Object field12; // legal, one type annotation @FAnno java_lang_Object field13; // seems legal, one field annotation @TAnno java_lang_Object field14; // seems legal, one type annotation @FTAnno java_lang_Object field15; // seems legal, one field annotation and one type annotation } Yet I don't know why @FAnno and @TAnno mean different things here. Or why @FTAnno has to exists at all. The specification doesn't have any good ideas either: "We have not found an example where such a meta-annotation is desirable for a newly-created annotation; although it is legal". The best counter-example I can come up with is @Deprecated public final Integer field; in which @Deprecated means that code relying on the field existing may have to change in the future. But you could also read that to mean that code relying on the field containing an expected kind of value may have to change in the future. Likewise for methods. Code relying on a method existing, beware! Or code relying on the result of calling a method, beware! Whether something is a declaration or a type annotation can be a matter of a viewpoint. So rewrite history so field declaration annotations have always meant type use annotations of fields, method declaration annotations have always meant type use annotations of non-void return values, skip annotations on array dimensions (you should use collections or proper low-level structures instead), introduce annotatable real type aliases using syntax, stay backwards compatible for free and stop butchering my type names, please. > If you have concerns about a NetBeans bug or about the syntax of lambda, > please direct those elsewhere; they don't belong on this list. > > Thanks! > > -Mike > > > > Subject: Type annotations don't look very Java-like >> From: Timo Kinnunen >> To: type-annotations-spec-**comments at openjdk.java.net >> Date: Wed, 18 Sep 2013 22:01:13 +0300 >> >> >> This is a repost of a comment from Mark Reinhold?s blog with additional >> comments below. >> >> I have to agree, both Lambdas and Type Annotations that I've been looking >> forward to don't look very Java-like at all. Lambdas add ugly syntax and >> Type Annotations break the simplicity of nested scoping. >> I'd love to see a list of what other options the EG considered and why >> they >> were rejected for what we have currently when Public Review phase starts. >> >> Here's Lambda with -> syntax: >> >> list.stream().map((Runnable runnable) -> { new Thread(runnable) } >> ).forEach(thread -> thread.start()); >> >> Why "->" when "for" is just as many keys to press and no key-combinations: >> >> list.stream().map(for(Runnable runnable) { new Thread(runnable) } >> ).forEach(for thread thread.start()); >> >> And Type Annotations, just look at this method signature: >> >> void innerMethod(@Any Outer. at Backer Middle. at Counted Inner this, @Any >> Outer. at Backer Middle. at Nullable @Counted Inner other) { ... } >> >> How do you suppose a word-wrapping text-editor would think they are >> grouped? Care to guess if it matches how they group semantically? Yep, the >> empty " " character is now more significant than the "." character, which >> is unbelievable. >> >> And if that wasn't enough, Type Annotations also lets you express the >> difference between annotations applied to a parameter and annotations >> applied to the type of the parameter. Here's how an annotation is applied >> to the parameter: >> >> void callingJava7Way(@Regarding Example oldOne) { ... } >> >> And to make the annotation apply to the type of the parameter, you do >> this: >> >> callingJava8Way(com.**somecompany.AnnotationTestBed.**@Regarding Example >> newOne) { ... } >> >> That has got to be the most verbose modifier of another modifier I've ever >> seen in any programming language ever and whoever came up with it deserves >> some sort of a prize. >> >> Alex Buckley replied: >> ?You don't have to use qualified names with type annotations. To write an >> annotation on the type of a formal parameter, as opposed to the >> declaration >> of the formal parameter, you just add @Target(ElementType.TYPE_USE) to the >> annotation's own type declaration. Then, "@Regarding Example oldOne" means >> @Regarding applies to this particular use of the Example type, rather than >> to the oldOne declaration. >> >> More comments on type annotations? Send them to the >> type-annotations-spec-comments at OpenJDK.? >> >> Alex, there might be bugs or unimplemented changes, but trying it out in >> the latest NetBeans IDE 4.7 Beta, JDK 1.8.0-ea-b106 and the annotation >> @Regarding defined like this: >> >> @Retention(value = RetentionPolicy.RUNTIME) >> @Target(value = {ElementType.TYPE_USE, ElementType.PARAMETER, >> ElementType.FIELD, ElementType.LOCAL_VARIABLE}) >> @interface Regarding { } >> >> Then as seen in the Trees (NetBeans development) view, right now you do >> have to write ?com.somecompany.**AnnotationTestBed.? in front of the >> annotation to modify the modifier into becoming an annotated type instead. >> Specifically, instead of 1xMODIFIER, 1xIDENTIFIER there will be >> 0xMODIFIER, >> 1xANNOTATED_TYPE. >> >> I don?t know where this change in semantics comes from or what its meaning >> is, but I can see that it?s there. And as long as it is there, it can >> become requirement for using some functionality in any tool that can >> detect >> its presence. >> >> >> >> -- >> Have a nice day, >> Timo Kinnunen >> > -- Have a nice day, Timo Kinnunen +358445405900, +37258352396