From alex.buckley at oracle.com Tue Feb 12 17:43:46 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 12 Feb 2013 17:43:46 -0800 Subject: Annotations on anonymous classes In-Reply-To: References: Message-ID: <511AEFD2.2030506@oracle.com> Hi Werner, Thanks for writing to the -spec-comments list. On 2/12/2013 4:17 PM, Werner Dietl wrote: > I have a question about anonymous classes and want to make sure we're > all on the same page on where type and declaration annotations should > go. > > Let's take this code: > > interface Bound {} > > void test() { > new Bound() { }; > } > > This is equivalent to having: > > interface Bound {} > > class Anon extends Object implements Bound {} > > void test() { > new Anon(); > } > > Now, let's take a declaration annotation @DA and type annotations @TA > and @TB, and use them like this: > > interface Bound {} > > void test() { > new @DA @TA Bound<@TB String>() { }; > } > > This should be translated to: > > interface Bound {} > > @DA > class Anon extends Object implements @TA Bound<@TB String> {} > > void test() { > new @TA Anon(); > } The JSR 308 spec has a problem: the 'Creator' production in JLS ch.18 does not use 'Type', so it is unaffected by JSR 308's addition of 'Annotations' to 'Type'. In other words, no annotations after 'new' are permitted by the spec! Obviously they should be, if their type has TYPE or TYPE_USE in @Target. > Note that I have @TA both on the implemented interface and on the > instantiation and @DA only on the class declaration. The JSR 308 should say how these annotations are distributed over Anon, since Anon's existence and form are specified by JLS 15.9.1, 15.9.5, and 13.1. The application of @DA to the class declaration looks good. The application of @TA to the type mentioned in the anonymous class declaration also looks good. No need to sprinkle @TA over Object. I assume that if Bound was a class, then 'new @TA Bound<..>() { }' would cause @TA to appear on the superclass. > Also note how @TB is not stored at the instantiation at all (this > might be surprising; if Bound were a class an instantiation "new @TA > Bound<@TB String>()" would obviously store both @TA and @TB with the > instantiation). My answer here is that @TA should not be left in 'new @TA Anon()'. An anonymous class declaration within a class instance creation expression has a unique binary name. Therefore, tools which seek annotations on a class instance creation expression can easily recognize that "an anonymous class was instantiated here", and find the corresponding class declaration with potential type-decl _and_ type-use annotations. I suspect moving _all_ type-decl and type-use annotations to the implicitly-declared Anon class is simpler to implement too, versus leaving some of them back at the creation expression. Alex From alex.buckley at oracle.com Fri Feb 15 12:51:40 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 15 Feb 2013 12:51:40 -0800 Subject: Type Annotations in the language model API Message-ID: <511E9FDC.1030101@oracle.com> Experts, Previously [1], we proposed to represent type annotations in the language model API via an AnnotatedTypeMirror hierarchy that parallels the TypeMirror hierarchy. This proposal was driven by an abundance of caution for language model implementations that share TypeMirror objects across different use sites, such as a single TypeMirror object for both uses of String in "@Foo String f1; @Bar String f2;". In addition, we proposed new methods on {Type,Variable,Executable}Element to expose AnnotatedTypeMirror objects. We now think our proposal was excessively concerned about freedom for implementers of the language model API, rather than keeping a simple conceptual model for users of the API. In keeping with how the Java language now supports annotations on both declarations and type uses, we propose to expose annotations uniformly on javax.lang.model.element.Element (declarations) and javax.lang.model.type.TypeMirror (type uses). To this end, we propose to pull the annotation methods of Element into a new interface which is implemented by both Element and TypeMirror: package javax.lang.model; interface AnnotatedConstruct { A getAnnotation(Class); A[] getAnnotationsByType(Class) List getAnnotationMirrors(); } (getAnnotationsByType is a new method for repeating annotations, discussed on the enhanced-metadata-spec-discuss list.) The implication for implementers is that a TypeMirror object cannot _always_ be shared across multiple uses of a type in class/interface/field/method/ctor declarations. Previously, a TypeMirror object could _always_ be shared in this manner. For example, suppose v1 is the VariableElement for the field "@Foo String f1;" and v2 is the VariableElement for the field "@Bar String f2;". In Java SE 8, v1.asType() must not return the same TypeMirror object as v2.asType(). But suppose v3 is the VariableElement for "@Quux String f3;" and v4 is the VariableElement for "@Quux String f4;". v3.AsType() may return the same TypeMirror object as v4.asType(). Essentially, the concept which TypeMirror has always represented - "type in the Java programming language" - is now expanded to "potentially annotated type in the Java programming language". For compatibility, the utility methods for type comparison in javax.lang.model.util.Types should ignore annotations. New methods can be added, but comparing annotations may be a rathole, so please let's use a new thread for utility methods. We don't propose to revisit type annotations in the core reflection API. There, we need new methods exposing a new AnnotatedType hierarchy because the legacy Type hierarchy is truly limited to declarations, both in concept and in implementation. Alex [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2012-September/000001.html From srikanth_sankaran at in.ibm.com Mon Feb 18 04:59:20 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Mon, 18 Feb 2013 07:59:20 -0500 Subject: Spec refresh at JCP site ? In-Reply-To: References: <50516CF6.6050400@free.fr> <20120921.031537.857440125198746700.mernst@cs.washington.edu> Message-ID: Hello ! Is it known when we can expect the next refresh at the JCP site. I know very recent versions are available at the University site, but the question is specifically about JCP site. TIA, Srikanth From alex.buckley at oracle.com Mon Feb 18 10:41:21 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 18 Feb 2013 10:41:21 -0800 Subject: Spec refresh at JCP site ? In-Reply-To: References: <50516CF6.6050400@free.fr> <20120921.031537.857440125198746700.mernst@cs.washington.edu> Message-ID: <512275D1.8000103@oracle.com> Mike and I were not planning another Early Draft Review. We were planning for the next milestone to be a Public Review aligned with the Public Reviews of other SE 8 JSRs. I have no information of any kind about when those Public Reviews would happen. Alex On 2/18/2013 4:59 AM, Srikanth S Adayapalam wrote: > Hello ! > > Is it known when we can expect the next refresh at the JCP site. I know > very recent versions are available at the University site, but the > question > is specifically about JCP site. > > TIA, > Srikanth > From alex.buckley at oracle.com Mon Feb 18 11:16:53 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 18 Feb 2013 11:16:53 -0800 Subject: Comments on preliminary javax.lang.model changes for JSR 308 In-Reply-To: <511EDBAB.2090402@oracle.com> References: <511EDBAB.2090402@oracle.com> Message-ID: <51227E25.90106@oracle.com> Thanks for raising this issue. The language model API changes should indeed be limited to solely the AnnotatedConstruct methods I outlined at [2], plus the getReceiverType() and Types methods you identify. Let's discuss those in the thread at [2]. Alex On 2/15/2013 5:06 PM, Joseph Darcy wrote: > Greetings JSR 308 experts, > > The initial push of the JSR 308 changes into JDK 8 [1], included various > changes to the javax.lang.model API > > 1) New type javax.lang.model.type.AnnotatedType > 2) New method ExecutableType.getReceiverType > 3) New enum constant TypeKind.ANNOTATED > 4) New method on visitor interface TypeVisitor.visitAnnotated > 5) Update of AbstractTypeVisitor6 with an implementation of visitAnnotated. > 6) Several new methods in javax.lang.model.util.Types > > Given the direction being taken for javax.lang.model support for type > annotations [2], with the possible exception of 2) and some of 6), the > rest of these changes should be reverted. The the proposed design in > [2], all types are potentially annotated so classifying types in the API > as annotated or not is not a helpful distinction. > > Thanks, > > -Joe > JSR 269 Maintenance Lead > > [1] 8006775: JSR 308: Compiler changes in JDK8, > http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71f35e4b93a5 > > [2] > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000064.html > From alex.buckley at oracle.com Mon Feb 18 13:03:05 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 18 Feb 2013 13:03:05 -0800 Subject: Type Annotations in the language model API In-Reply-To: <511E9FDC.1030101@oracle.com> References: <511E9FDC.1030101@oracle.com> Message-ID: <51229709.3080606@oracle.com> As raised by Joe Darcy elsewhere, the language model needs to consider the only truly new construct in the language for type annotations: the 'this' pseudo-parameter which allows annotations on the type of the object on which a method/ctor is invoked. The question is whether to expose a mirror for that type via: i) a new method ExecutableElement.getReceiverType() that returns a TypeMirror, or ii) inserting a VariableElement for 'this' into the result of Executable.getParameters(), from which clients can get a TypeMirror via asType(). I favor (i) for three reasons: - The EG agreed previously that a method parameter named 'this' is not truly a formal parameter declaration. It isn't reified in a method descriptor, and it's best not to let it be annotated by a PARAMETER-targeting annotation. Therefore it doesn't deserve a VariableElement. - getReceiverType() is easy to implement in ExecutableElement because the result can always be based on the result of asType() from the enclosing TypeElement. Just sprinkle in the type annotations from a 'this' pseudo-parameter if available from source. - getReceiverType() loosely follows j.l.r.Method.getAnnotatedReceiverType(). (ExecutableElement.getAnnotatedReceiverType() would not be a good name because in the language model, we've pushed annotations into type mirrors per Joe's "has-a" comment.) Alex On 2/15/2013 12:51 PM, Alex Buckley wrote: > Experts, > > Previously [1], we proposed to represent type annotations in the > language model API via an AnnotatedTypeMirror hierarchy that parallels > the TypeMirror hierarchy. This proposal was driven by an abundance of > caution for language model implementations that share TypeMirror objects > across different use sites, such as a single TypeMirror object for both > uses of String in "@Foo String f1; @Bar String f2;". In addition, we > proposed new methods on {Type,Variable,Executable}Element to expose > AnnotatedTypeMirror objects. > > We now think our proposal was excessively concerned about freedom for > implementers of the language model API, rather than keeping a simple > conceptual model for users of the API. > > In keeping with how the Java language now supports annotations on both > declarations and type uses, we propose to expose annotations uniformly > on javax.lang.model.element.Element (declarations) and > javax.lang.model.type.TypeMirror (type uses). > > To this end, we propose to pull the annotation methods of Element into a > new interface which is implemented by both Element and TypeMirror: > > package javax.lang.model; > interface AnnotatedConstruct { > A getAnnotation(Class); > A[] getAnnotationsByType(Class) > List getAnnotationMirrors(); > } > > (getAnnotationsByType is a new method for repeating annotations, > discussed on the enhanced-metadata-spec-discuss list.) > > The implication for implementers is that a TypeMirror object cannot > _always_ be shared across multiple uses of a type in > class/interface/field/method/ctor declarations. Previously, a TypeMirror > object could _always_ be shared in this manner. > > For example, suppose v1 is the VariableElement for the field "@Foo > String f1;" and v2 is the VariableElement for the field "@Bar String > f2;". In Java SE 8, v1.asType() must not return the same TypeMirror > object as v2.asType(). But suppose v3 is the VariableElement for "@Quux > String f3;" and v4 is the VariableElement for "@Quux String f4;". > v3.AsType() may return the same TypeMirror object as v4.asType(). > > Essentially, the concept which TypeMirror has always represented - "type > in the Java programming language" - is now expanded to "potentially > annotated type in the Java programming language". > > For compatibility, the utility methods for type comparison in > javax.lang.model.util.Types should ignore annotations. New methods can > be added, but comparing annotations may be a rathole, so please let's > use a new thread for utility methods. > > We don't propose to revisit type annotations in the core reflection API. > There, we need new methods exposing a new AnnotatedType hierarchy > because the legacy Type hierarchy is truly limited to declarations, both > in concept and in implementation. > > Alex > > [1] > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2012-September/000001.html > From alex.buckley at oracle.com Tue Feb 19 16:19:24 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 19 Feb 2013 16:19:24 -0800 Subject: Type Annotations in the language model API In-Reply-To: <51229709.3080606@oracle.com> References: <511E9FDC.1030101@oracle.com> <51229709.3080606@oracle.com> Message-ID: <5124168C.3090902@oracle.com> On 2/18/2013 1:03 PM, Alex Buckley wrote: > As raised by Joe Darcy elsewhere, the language model needs to consider > the only truly new construct in the language for type annotations: the > 'this' pseudo-parameter which allows annotations on the type of the > object on which a method/ctor is invoked. > > The question is whether to expose a mirror for that type via: > > i) a new method ExecutableElement.getReceiverType() that returns a > TypeMirror, or We are working on adding this method. It will return a TypeMirror which is a DeclaredType if the ExecutableElement represents an instance method or an inner constructor. It will return a TypeMirror which is a NoType (kind NONE) if the ExecutableElement represents a static method or an initializer (static or instance). We also plan to add ExecutableType.getReceiverType(), since ExecutableType generally follows ExecutableElement in exposing sub-structural types, e.g. return type. It will return a TypeMirror which is a DeclaredType if the ExecutableType represents the type of an executable which is an instance method or an inner constructor. It will return a TypeMirror which is a a NoType (kind NONE) if the ExecutableType represents the type of an executable which is a static method or an initializer (static or instance). Alex From alex.buckley at oracle.com Mon Feb 25 10:39:20 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 25 Feb 2013 10:39:20 -0800 Subject: Missing location of Runtime[In]VisibleTypeAnnotations attribute Message-ID: <512BAFD8.3030105@oracle.com> Section 3 of the spec says: "A type annotation is stored in a Runtime[In]visibleTypeAnnotations attribute on the smallest enclosing class, field, method, or Code structure." Subsections then give the exact storage location for most, but not all, of the possible type annotations. The location is missing in 3.3.9 "Type tests, object creation, and method/constructor references" - an omission which partly led to dropped annotations in the RI [1]. Also, 3.3.10 gives a location but is inconsistent about the name of the structure being stored. Alex [1] http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-February/000629.html