From yuri.gaevsky at oracle.com Tue Jul 9 11:01:27 2013 From: yuri.gaevsky at oracle.com (yuri.gaevsky at oracle.com) Date: Tue, 09 Jul 2013 22:01:27 +0400 Subject: [type-annos-observers] Removing target_type distinctions between constructors and methods In-Reply-To: <51843115.6070704@oracle.com> References: <51843115.6070704@oracle.com> Message-ID: <51DC4FF7.3080109@oracle.com> Hello, It's unclear from the discussion [1] if target_type 0x46 has been actually removed because it still exists in the spec [2]. Can someone clarify that, please? Thanks, -Yuri [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-April/000106.html [2] http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#class-file%3Aext%3Atarget_type -------------- next part -------------- An embedded message was scrubbed... From: Jonathan Gibbons Subject: Re: [type-annos-observers] Removing target_type distinctions between constructors and methods Date: Fri, 03 May 2013 14:50:13 -0700 Size: 6317 Url: http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/attachments/20130709/46bae349/type-annos-observersRemovingtarget_typedistinctionsbetweenconstructorsandmethods.eml From yuri.gaevsky at oracle.com Tue Jul 9 11:21:25 2013 From: yuri.gaevsky at oracle.com (yuri.gaevsky at oracle.com) Date: Tue, 09 Jul 2013 22:21:25 +0400 Subject: [type-annos-observers] Removing target_type distinctions between constructors and methods In-Reply-To: <51843115.6070704@oracle.com> References: <51843115.6070704@oracle.com> Message-ID: <51DC54A5.6070900@oracle.com> Hello, It's unclear from the discussion [1] if target_type 0x46 has been actually removed because it still exists in the spec [2]. Can someone clarify that, please? Thanks, -Yuri [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-April/000106.html [2] http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#class-file%3Aext%3Atarget_type -------------- next part -------------- An embedded message was scrubbed... From: Jonathan Gibbons Subject: Re: [type-annos-observers] Removing target_type distinctions between constructors and methods Date: Fri, 03 May 2013 14:50:13 -0700 Size: 6318 Url: http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/attachments/20130709/b35b8523/type-annos-observersRemovingtarget_typedistinctionsbetweenconstructorsandmethods.eml From alex.buckley at oracle.com Tue Jul 9 11:31:11 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 09 Jul 2013 11:31:11 -0700 Subject: [type-annos-observers] Removing target_type distinctions between constructors and methods In-Reply-To: <51DC54A5.6070900@oracle.com> References: <51843115.6070704@oracle.com> <51DC54A5.6070900@oracle.com> Message-ID: <51DC56EF.8020901@oracle.com> Per my response to Mike [1], the target_type values were not changed in the May 2 2013 spec. I think you may be confused by the changelog for the May 2 2013 spec [2] where it says "Remove unused target_info method_reference_target." Notice this concerns the target_info structure, not target_type. Indeed, a stray union item was removed from target_info. Alex [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-May/000124.html [2] http://types.cs.washington.edu/jsr308/specification/jsr308-changes.html On 7/9/2013 11:21 AM, yuri.gaevsky at oracle.com wrote: > Hello, > > It's unclear from the discussion [1] if target_type 0x46 has been > actually removed because it still exists in the spec [2]. > > Can someone clarify that, please? > > Thanks, > -Yuri > > [1] > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-April/000106.html > [2] > http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#class-file%3Aext%3Atarget_type > From andrew.clement at gmail.com Wed Jul 10 14:04:09 2013 From: andrew.clement at gmail.com (Andy Clement) Date: Wed, 10 Jul 2013 14:04:09 -0700 Subject: [type-annos-observers] Question on remapping type annotations when casts are discarded by the compiler Message-ID: I'm in one of the corners of the JSR308 spec, Section 3.3.10, which reads: === If the compiler eliminates an annotated cast, it is required to retain the annotations on the cast in the class file (if the annotation type has at least RetentionPolicy.CLASS retention). When a cast is removed, the compiler may need to adjust (the locations of) the annotations, to account for the relationship between the expression?s type and the casted-to type. Consider: class C { ... } class D extends C { ... } ... ... (C<@A1 X, @A2 Y>) myD ... The compiler may leave out the upcast, but in that case it must record that @A1 is attached to the second type argument of D, even though it was originally attached to the first type argument of C. === I have this (hopefully sane?) set of declarations: class C {} class D extends C {} D d = new D(); C o2 = (C<@Anno1 Float, at Anno2 String, @Anno3 Integer>) d; If the cast were not discarded, the type anno attributes would look like a bit like: @Anno1 TYPE_ARGUMENT(0) @Anno2 TYPE_ARGUMENT(1) @Anno3 TYPE_ARGUMENT(2) But the cast is discarded so I need to remap the annotation positions based on the spec section above, mapping them to where they exist on D. @Anno1 becomes TYPE_ARGUMENT(1) @Anno3 becomes TYPE_ARGUMENT(0) What happens to @Anno2? thanks Andy Clement From alex.buckley at oracle.com Wed Jul 10 16:45:20 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 10 Jul 2013 16:45:20 -0700 Subject: [type-annos-observers] Question on remapping type annotations when casts are discarded by the compiler In-Reply-To: References: Message-ID: <51DDF210.2000609@oracle.com> Hi Andy, Sun/Oracle tries very hard to avoid rigid requirements about what a Java compiler must emit. Attributes in the JVM Specification are defined in terms of what they represent, not the conditions under which they represent it. There are some exceptions involving declarations (e.g. the Signature attribute has a non-trivial "must occur when..." clause) but annotations on an expression do not rise to the level of being mandated. There is no useful conformance test that JCK-VM engineers can write, and as you point out there are difficult corner cases. The text about what a compiler is required to do will not appear in JLS8 or JVMS8. Alex On 7/10/2013 2:04 PM, Andy Clement wrote: > I'm in one of the corners of the JSR308 spec, Section 3.3.10, which reads: > > === > > If the compiler eliminates an annotated cast, it is required to retain the > annotations on the cast in the class file (if the annotation type has at > least RetentionPolicy.CLASS retention). When a cast is removed, the > compiler may need to adjust (the locations of) the annotations, to account > for the relationship between the expression?s type and the casted-to type. > Consider: > > class C { ... } > class D extends C { ... } > ... > ... (C<@A1 X, @A2 Y>) myD ... > > The compiler may leave out the upcast, but in that case it must record that > @A1 is attached to the second type argument of D, even though it was > originally attached to the first type argument of C. > > === > I have this (hopefully sane?) set of declarations: > > class C {} > > class D extends C {} > > D d = new D(); > > C o2 = (C<@Anno1 Float, at Anno2 String, @Anno3 > Integer>) d; > > If the cast were not discarded, the type anno attributes would look like a > bit like: > > @Anno1 TYPE_ARGUMENT(0) > @Anno2 TYPE_ARGUMENT(1) > @Anno3 TYPE_ARGUMENT(2) > > But the cast is discarded so I need to remap the annotation positions based > on the spec section above, mapping them to where they exist on D. > > @Anno1 becomes TYPE_ARGUMENT(1) > @Anno3 becomes TYPE_ARGUMENT(0) > > What happens to @Anno2? > > thanks > Andy Clement > From markus_keller at ch.ibm.com Mon Jul 22 05:03:26 2013 From: markus_keller at ch.ibm.com (Markus Keller) Date: Mon, 22 Jul 2013 14:03:26 +0200 Subject: [type-annos-observers] RetentionPolicy.CLASS too broad for TYPE_USE annotations In-Reply-To: References: Message-ID: Ping? markus_keller at ch.ibm.com wrote on 2013-05-06: The RetentionPolicy.CLASS looks too broad for many TYPE_USE annotations. For annotations that are meant to serve as API contracts, it's enough to include the externally visible annotations (target_type values 0x1*) in the class file. The internal annotations (0x4*) are not interesting for this use case and only bloat the class file. Neither the user who compiles the code nor the provider of a TYPE_USE annotation currently have the means to selectively enable retention only for the interesting group. I see two possible solutions to this problem: 1) Compilers offer an opt-in mechanism to store internal annotations. Similar to JEP 118's proposed "-parameters" command-line switch, this could be called "-internalAnnotations". 2) Introduce new RetentionPolicy values CLASS_INTERNAL and RUNTIME_INTERNAL to tell that non-visible annotations should be stored in the class file as well. The existing CLASS and RUNTIME policies could be kept for externally visible annotations only (the main use case). The suffix could also be "_INCLUDING_CODE_BLOCKS". With both solutions, e.g. an @NonNull annotation could stay at @Retention(RetentionPolicy.CLASS). Markus From elena.votchennikova at oracle.com Tue Jul 23 08:31:40 2013 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Tue, 23 Jul 2013 19:31:40 +0400 Subject: [type-annos-observers] Question regarding j.l.Class.getAnnotatedInterfaces() Message-ID: <51EEA1DC.1010401@oracle.com> Hello, Could you please help me with understanding of the j.l.Class.getAnnotatedInterfaces() method behavior and specification? From the API spec (for jdk8b99): "Returns an array of AnnotatedType objects that represent the use of types to specify superinterfaces of the entity represented by this Class." ... "If this Class represents a class or interface whose declaration does not explicitly indicate any annotated superinterfaces, the return value is an array of length 0." Lets look at the example. We have to classes Cls1 and Cls2 that implement the same interfaces Interf1 and Interf2. But in first case the use of these types are annotated and in second case - not: class Cls1 implements @Anno Interf1, @Anno Interf2 {} class Cls2 implements Interf1, Interf2 {} For Cls1: Cls1.class.getAnnotatedInterfaces() will return an array of two AnnotatedType objects that represent Interf1 and Interf2 classes. For Cls2: Cls2.class.getAnnotatedInterfaces() should return an empty array if Interf1 and Interf2 declarations are not directly annotated, shouldn't it? If Interf1 and Interf2 declarations are directly annotated this method should return an array of AnnotatedType objects that represent these interfaces (corresponding to the specification). Is my understanding correct? Lets look at the one more example: class Cls3 implements Interf1, @Anno Interf2 {} What will return method Cls3.class.getAnnotatedInterfaces()? And Why? Thanks a lot, Elena