From jesper at selskabet.org  Tue Sep  3 15:38:58 2013
From: jesper at selskabet.org (=?iso-8859-1?Q?Jesper_Steen_M=F8ller?=)
Date: Wed, 4 Sep 2013 00:38:58 +0200
Subject: enhanced-metadata-spec-discuss Digest, Vol 12, Issue 4
In-Reply-To: <521BB587.4070207@oracle.com>
References: <mailman.45.1377284403.18218.enhanced-metadata-spec-discuss@openjdk.java.net>
	<OF59748B1B.0079169F-ON65257BD3.00611D19-65257BD3.00683BB3@in.ibm.com>
	<521BB587.4070207@oracle.com>
Message-ID: <961AE2BF-3E37-4428-93BE-F369ACA4A9BA@selskabet.org>

Hi Alex, Srikanth

Question is inline, below:

On 26/08/2013, at 22.07, Alex Buckley wrote:

> Hi Srikanth,
> 
> Many thanks for trying out javac in the JDK 8 builds. Answers below.
> 
> On 8/26/2013 11:56 AM, Srikanth S Adayapalam wrote:
>> 
>> 8b100's behavior is confusing on the following code:
>> 
>> // --
>> public class X {
>>     void foo() {
>>         new Y().new Z() {
>>         };
>>     }
>> }
>> class Y {
>>     class Z {}
>> }
>> // --
>> 
>>   final X this$0;
>>     descriptor: LX;
>>     flags: ACC_FINAL, ACC_SYNTHETIC
>> 
>>   X$1(X, Y);
>>     descriptor: (LX;LY;)V
>>     flags:
>>     Code:
>>       stack=3, locals=3, args_size=3
>>          0: aload_0
>>          1: aload_1
>>          2: putfield      #1                  // Field this$0:LX;
>>          5: aload_0
>>          6: aload_2
>>          7: dup
>>          8: invokevirtual #2                  // Method
>> java/lang/Object.getClas
>> s:()Ljava/lang/Class;
>>         11: pop
>>         12: invokespecial #3                  // Method
>> Y$Z."<init>":(LY;)V
>>         15: return
>>       LineNumberTable:
>>         line 3: 0
>>     MethodParameters:
>>       Name                           Flags
>>       this$0                         final mandated
>>       x0
>> 
>> Why would the anonymous class's own enclosing instances be mandated
>> while "x0" which I presume is the super classes enclosing instance
>> be flag less ?
> 
> There seem to be two javac (or maybe javap) bugs here:
> 
> - The this$0 field and the this$0 formal parameter which supplies it are concerned with the immediately enclosing instance of the anonymous class's instance. Transmitting this instance to the anonymous class's instance is covered by point 2 in 8.8.9. Basically, it's not specified. As such, the this$0 field has been ACC_SYNTHETIC since forever, and that's a big hint that the this$0 formal parameter should be ACC_SYNTHETIC too.
> 
> - The x0 formal parameter is implicitly declared by 15.9.5.1 as having type Y, because the direct superclass Z of the anonymous class is inner. So, x0 should be flagged and displayed as mandated.
> 
> Alex


According to 8.8.9 (3) and 15.9.5.1(second bullet), x0 would have to an INITIAL / "the first" implicitly declared argument, so shouldn't javac also change the order of this$0 and x0 (even if the sole purpose of doing so is to provide it to Y$Z(Y) constructor).

But the thing I don't understand is why the spec bothers with specifying implicitly declared parameters for constructors for constructors of anonymous constructors when they generally fall into the category of 8.8.9 (2). Why can't the compiler simply take the synthetic x0 argument and use it as (the mandated) constructor for Z, which may indeed be supplied by a different compiler. Doing that shouldn't make x0 mandated, since no other compiler may emit a call to the X$1(X, Y) constructor.

In short, I don't see any practical need for 8.8.9 (3) -- did I miss something crucial?

-Jesper


From alex.buckley at oracle.com  Tue Sep  3 17:01:50 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 03 Sep 2013 17:01:50 -0700
Subject: enhanced-metadata-spec-discuss Digest, Vol 12, Issue 4
In-Reply-To: <961AE2BF-3E37-4428-93BE-F369ACA4A9BA@selskabet.org>
References: <mailman.45.1377284403.18218.enhanced-metadata-spec-discuss@openjdk.java.net>
	<OF59748B1B.0079169F-ON65257BD3.00611D19-65257BD3.00683BB3@in.ibm.com>
	<521BB587.4070207@oracle.com>
	<961AE2BF-3E37-4428-93BE-F369ACA4A9BA@selskabet.org>
Message-ID: <5226786E.4050802@oracle.com>

Hi Jesper,

On 9/3/2013 3:38 PM, Jesper Steen M?ller wrote:
>>> // --
>>> public class X {
>>>      void foo() {
>>>          new Y().new Z() {
>>>          };
>>>      }
>>> }
>>> class Y {
>>>      class Z {}
>>> }
>>> // --
>>>
>>>    final X this$0;
>>>      descriptor: LX;
>>>      flags: ACC_FINAL, ACC_SYNTHETIC
>>>
>>>    X$1(X, Y);
>>>      descriptor: (LX;LY;)V
>>>      flags:
>>>      Code:
>>>        stack=3, locals=3, args_size=3
>>>           0: aload_0
>>>           1: aload_1
>>>           2: putfield      #1                  // Field this$0:LX;
>>>           5: aload_0
>>>           6: aload_2
>>>           7: dup
>>>           8: invokevirtual #2                  // Method
>>> java/lang/Object.getClas
>>> s:()Ljava/lang/Class;
>>>          11: pop
>>>          12: invokespecial #3                  // Method
>>> Y$Z."<init>":(LY;)V
>>>          15: return
>>>        LineNumberTable:
>>>          line 3: 0
>>>      MethodParameters:
>>>        Name                           Flags
>>>        this$0                         final mandated
>>>        x0
>>>
>>> Why would the anonymous class's own enclosing instances be mandated
>>> while "x0" which I presume is the super classes enclosing instance
>>> be flag less ?
>>
>> There seem to be two javac (or maybe javap) bugs here:
>>
>> - The this$0 field and the this$0 formal parameter which supplies
>> it are concerned with the immediately enclosing instance of the
>> anonymous class's instance. Transmitting this instance to the
>> anonymous class's instance is covered by point 2 in 8.8.9.
>> Basically, it's not specified. As such, the this$0 field has been
>> ACC_SYNTHETIC since forever, and that's a big hint that the this$0
>> formal parameter should be ACC_SYNTHETIC too.
>>
>> - The x0 formal parameter is implicitly declared by 15.9.5.1 as
>> having type Y, because the direct superclass Z of the anonymous
>> class is inner. So, x0 should be flagged and displayed as
>> mandated.
>>
>> Alex
>
> According to 8.8.9 (3) and 15.9.5.1(second bullet), x0 would have to
> an INITIAL / "the first" implicitly declared argument, so shouldn't
> javac also change the order of this$0 and x0 (even if the sole
> purpose of doing so is to provide it to Y$Z(Y) constructor).

The ctor of X$1 is specified to have an initial implicitly declared
parameter to represent the immediately enclosing instance of the
anon.class object with respect to Z, i.e. the "new Y()" instance. But a
Java compiler is free to add synthetic parameters to the ctor of an
anonymous class, because (per 8.8.9 (2)) no other compiler will ever
compile code which references the anonymous class. So, the ctor ends up
having the descriptor X$1(X, Y); - the first parameter descriptor is the
synthetic this$0 of type X, and the second parameter descriptor is the
mandated x0 of type Y.

> But the thing I don't understand is why the spec bothers with
> specifying implicitly declared parameters for constructors for
> constructors of anonymous constructors when they generally fall into
> the category of 8.8.9 (2). Why can't the compiler simply take the
> synthetic x0 argument and use it as (the mandated) constructor for Z,
> which may indeed be supplied by a different compiler. Doing that
> shouldn't make x0 mandated, since no other compiler may emit a call
> to the X$1(X, Y) constructor.

What's the point of an anon.class's constructor ever having a mandated 
parameter, whether the anon.class's superclass is inner or not? The 
answer is: there is no point, but the JLS was written to require the 
parameter anyway. 15.9.5.1 has specified since JLS2 that an anon.class's 
constructor has an implicit first parameter (yeah yeah it ends up being 
the second), while 15.9.3 has specified since JLS2 the argument to be 
passed to that parameter. Given these rules, I think "the right thing" 
is to flag the parameter as mandated in the MethodParameters attribute.

One could argue that an anon.class's constructor should be synthetic
because of the rule in 13.1 about not corresponding to something in
source code; and then argue that all of its parameters should be
synthetic, with none mandated. But we've evolved our understanding of
class file contents since the 13.1 rule was written in the 1990s.
Notably, JLS3 specified that an enum type has values() and valueOf()
methods - you can't write them by hand, so they must be emitted into the
class file without corresponding to anything in source code, yet they
cannot be synthetic because they ought to show up in core reflection
(synthetic methods don't show up). We have a whole family of bugs about
this, which led to a better understanding of synthetic v. mandated.
Eventually I would like to flag an anon.class's constructor as mandated
rather than synthetic, while will require an ACC_MANDATED flag for
classes, fields, or methods.

> In short, I don't see any practical need for 8.8.9 (3) -- did I miss
> something crucial?

It would have been better if JLS2 had said how to determine the
immediately enclosing instance with respect to the superclass, and then
- rather than calling for "automatically generated" arguments and
parameters - not specified how to transmit the instance to the new
anon.class object. The JLS could have decreed that a newly constructed
anon.class object simply knows of the instance. But it's too late to
change that now, since compilers emit the anon.class constructor
specified in 15.9.5.1. For the sake of full information, the policy in 
8.8.9 (3) should remain.

Alex

From joe.darcy at oracle.com  Wed Sep  4 21:24:16 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 04 Sep 2013 21:24:16 -0700
Subject: Method Parameter Reflection spec
In-Reply-To: <5214D6EB.2020007@oracle.com>
References: <521294AC.2090807@oracle.com> <5212986A.6040704@oracle.com>
	<5213BF1F.6050502@oracle.com> <5213C5B3.9010609@oracle.com>
	<5213D47E.9040607@oracle.com> <5213E944.7050401@oracle.com>
	<5214D6EB.2020007@oracle.com>
Message-ID: <52280770.9040008@oracle.com>

Hello,

On 8/21/2013 8:04 AM, Eric McCorkle wrote:
> I will give Joe a day to add his comments.

For large values of a day, here are a few comments.

I agree the sort of cases below due to corrupt / inconsistent class 
files are closer in flavor to error conditions than to exceptional ones. 
An end user program "shouldn't" have to worry about recovering from 
corrupt class files.

In the annotations space, the annotation information was defined as 
meta-data and therefore less essential to the integrity of the class 
file than other attributes; hence, a fail-lazily approach in that regard.

HTH,

-Joe

>
> Here's a list of all the ways MethodParameters attributes could go wrong:
>
> (i) Actual length does not match attribute_length
> (ii) The number of parameters (parameter_count) is wrong for the method
> (iii) A constant pool index is out of bounds.
> (iv) A constant pool index does not refer to a UTF-8 entry
> (v) A parameter's name is "", or contains an illegal character [0]
> (vi) The flags field contains an illegal flag (something other than
> FINAL, SYNTHETIC, or MANDATED)
>
> (i) causes a ClassFileFormatError when parsing the class file (as it
> should).  Right now, (iii) and (iv) cause an IllegalArgumentException to
> be thrown.
>
> I am working on a patch to correct the behavior for (ii)-(vi), so I can
> have Executable.getParameters() throw whatever exception you choose (ie.
> this is one of those rare moments of freedom).
>
>
> [0]: I seem to recall there being some discussion about backspaces, but
> the current version doesn't seem to rule them out.  Has this been changed?
>
> On 08/20/13 18:10, Alex Buckley wrote:
>> Sounds good. I'd wait a day in case Joe has a comment, then do it.
>> Please send a summary to this list of which exceptions are thrown by
>> Executable#getParameters and for what reasons. This will let me record
>> some more color in section 2.3 of 8misc.pdf, above and beyond the change
>> from:
>>
>> Methods of class java.lang.reflect.Parameter must throw
>> ReflectiveOperationException if ...
>>
>> to:
>>
>> java.lang.reflect.Executable#getParameters must throw
>> ReflectiveOperationException if ...
>>
>> Alex
>>
>> On 8/20/2013 1:41 PM, Eric McCorkle wrote:
>>> getAnnotations for each of these calls out to AnnotationParser, which
>>> does indeed throw an AnnotationFormatError in a variety of cases
>>> (duplicated annotations, malformed or incomplete annotations, etc).  In
>>> other cases (ie type mismatches), it delays throwing of exceptions.
>>> Exceptions coming from the VM (illegal access, bad constant pool
>>> indexes, parameter mismatches, class casts, and the like) are caught and
>>> rethrown as AnnotationFormatErrors.
>>>
>>> In light of this, I'm going to argue the precedent's there.  General
>>> formatting issues (which I'll argue covers bad names and wrong numbers
>>> of parameters) cause errors to be thrown immediately, and the completely
>>> analogous case of a bad constant pool index does cause an error to be
>>> thrown immediately.
>>>
>>> I'll also put forward that parameters are a bit different, and favor the
>>> approach of having Executable.getParameters() be able to throw
>>> exceptions for bad formatting.  Annotations are generally complex, with
>>> far more complex correctness conditions, and far higher cost to
>>> transform them from their storage format to reflective objects.  It
>>> makes sense to defer some of this processing.  MethodParameters, on the
>>> other hand, are very simple, and the main use case is to get the names
>>> of parameters.  Therefore, the spec ought to imply, or at least allow
>>> for an implementation that makes a single trip to the VM per method,
>>> after which the names are immediately available.  (Also, there are
>>> several practical advantages to allowing Parameter to be an immutable
>>> object that cannot be subclassed...)
>>>
>>> On 08/20/13 15:38, Alex Buckley wrote:
>>>> The precedent is AnnotatedElement#getAnnotations as found in Class,
>>>> Field, Executable, etc. Do those methods validate the
>>>> RuntimeVisibleAnnotations attribute before returning an array of
>>>> Annotation objects? I think they do. Can you describe the validation
>>>> they do which may cause an AnnotationTypeMismatchException or
>>>> IncompleteAnnotationException?
>>>>
>>>> If their validation is "equivalent" to what Executable#getParameters
>>>> would do, then it would be acceptable to change the spec and
>>>> implementation of Executable#getParameters and
>>>> Parameter#getName/Type/etc at this late stage. Please comment ASAP.
>>>>
>>>> Alex
>>>>
>>>> On 8/20/2013 12:10 PM, Eric McCorkle wrote:
>>>>> Okay, strike #2 from my requests.  What about having
>>>>> Executable.getParameters() throw ReflectiveOperationException
>>>>> instead of
>>>>> methods in Parameter, for the reasons I discuss?
>>>>>
>>>>> On 08/19/13 18:12, Alex Buckley wrote:
>>>>>> The 8misc.pdf file doesn't say anything about bad constant pool
>>>>>> indexes.
>>>>>>
>>>>>> If MethodParameters was an attribute that the JVM is required to
>>>>>> recognize and correctly read, then the JVM would be required to throw
>>>>>> ClassFormatError for bad constant pool indexes. But since
>>>>>> MethodParameters is an attribute that the class libraries of the
>>>>>> Java SE
>>>>>> platform - as opposed to the JVM - are required to recognize and
>>>>>> correctly read, it's the responsibility of the class libraries to
>>>>>> throw
>>>>>> something which is a) useful and b) consistent with bad constant pool
>>>>>> indexes for similar situations such as AnnotatedElement#getAnnotations
>>>>>> on a RuntimeVisibleAnnotations attribute.
>>>>>>
>>>>>> How the class libraries interact with a JVM implementation to
>>>>>> determine
>>>>>> good or bad constant pool entries (e.g. private functions of the JVM
>>>>>> implementation throw IllegalArgumentException, which
>>>>>> AnnotatedElement#getAnnotations then wraps as a FooBarException) is
>>>>>> not
>>>>>> a matter for the SE API specification. The only thing that matters for
>>>>>> the SE API specification is what something like
>>>>>> AnnotatedElement#getAnnotations is specified to throw today.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> On 8/19/2013 2:57 PM, Eric McCorkle wrote:
>>>>>>> The current version of the spec indicates that methods in
>>>>>>> java.lang.reflect.Parameter should throw ReflectiveOperationException
>>>>>>> for several cases (wrong number of parameters, bad parameter name,
>>>>>>> bad
>>>>>>> constant pool index).
>>>>>>>
>>>>>>> I'd like to suggest two (separate) minor revisions:
>>>>>>>
>>>>>>> 1) Executable.getParameters() should throw the
>>>>>>> ReflectiveOperationException in the case of an invalid name or the
>>>>>>> wrong
>>>>>>> number of parameters.  The rationale is as follows:
>>>>>>>
>>>>>>>      * Doing it this way makes it straightforward to implement
>>>>>>> j.l.r.Parameter as an immutable object.  Having methods in Parameter
>>>>>>> throw the exception means Parameter objects will have to remember
>>>>>>> whether or not they have verified their name (or else verify the name
>>>>>>> every time they are called).
>>>>>>>
>>>>>>>      * Having every single method in Parameter possibly check
>>>>>>> whether the
>>>>>>> number of parameters that were returned from the VM is correct seems
>>>>>>> rather awkward, as opposed to having a single check when Executable
>>>>>>> obtains the Parameter array back from the VM.
>>>>>>>
>>>>>>> 2) In the event of a bad constant pool index, an
>>>>>>> IllegalArgumentException.
>>>>>>>
>>>>>>>      * The current behavior of hotspot whenever it expects a UTF-8
>>>>>>> constant
>>>>>>> pool entry, but sees either an out-of-bounds index or something other
>>>>>>> than a UTF-8 is to throw an IllegalArgumentException.
>>>>>>>


From eric.mccorkle at oracle.com  Mon Sep  9 12:02:58 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 09 Sep 2013 15:02:58 -0400
Subject: Method Parameter Reflection spec
In-Reply-To: <52280770.9040008@oracle.com>
References: <521294AC.2090807@oracle.com> <5212986A.6040704@oracle.com>
	<5213BF1F.6050502@oracle.com> <5213C5B3.9010609@oracle.com>
	<5213D47E.9040607@oracle.com> <5213E944.7050401@oracle.com>
	<5214D6EB.2020007@oracle.com> <52280770.9040008@oracle.com>
Message-ID: <522E1B62.30305@oracle.com>

On 09/05/13 00:24, Joe Darcy wrote:
> Hello,
> 
> On 8/21/2013 8:04 AM, Eric McCorkle wrote:
>> I will give Joe a day to add his comments.
> 
> For large values of a day, here are a few comments.
> 
> I agree the sort of cases below due to corrupt / inconsistent class
> files are closer in flavor to error conditions than to exceptional ones.
> An end user program "shouldn't" have to worry about recovering from
> corrupt class files.
> 
> In the annotations space, the annotation information was defined as
> meta-data and therefore less essential to the integrity of the class
> file than other attributes; hence, a fail-lazily approach in that regard.

Then it sounds like there's an agreement that the exception(s) should be
thrown from Executable.getParameters()  Good.

What remains at this point is to determine what exceptions should be
thrown for what cases.  I don't really have a strong opinion on the
matter; I'll happily leave that up to someone else.

>>
>> Here's a list of all the ways MethodParameters attributes could go wrong:
>>
>> (i) Actual length does not match attribute_length
>> (ii) The number of parameters (parameter_count) is wrong for the method
>> (iii) A constant pool index is out of bounds.
>> (iv) A constant pool index does not refer to a UTF-8 entry
>> (v) A parameter's name is "", or contains an illegal character [0]
>> (vi) The flags field contains an illegal flag (something other than
>> FINAL, SYNTHETIC, or MANDATED)
>>
>> (i) causes a ClassFileFormatError when parsing the class file (as it
>> should).  Right now, (iii) and (iv) cause an IllegalArgumentException to
>> be thrown.
>>
>> I am working on a patch to correct the behavior for (ii)-(vi), so I can
>> have Executable.getParameters() throw whatever exception you choose (ie.
>> this is one of those rare moments of freedom).
>>
>>
>> [0]: I seem to recall there being some discussion about backspaces, but
>> the current version doesn't seem to rule them out.  Has this been
>> changed?
>>
>> On 08/20/13 18:10, Alex Buckley wrote:
>>> Sounds good. I'd wait a day in case Joe has a comment, then do it.
>>> Please send a summary to this list of which exceptions are thrown by
>>> Executable#getParameters and for what reasons. This will let me record
>>> some more color in section 2.3 of 8misc.pdf, above and beyond the change
>>> from:
>>>
>>> Methods of class java.lang.reflect.Parameter must throw
>>> ReflectiveOperationException if ...
>>>
>>> to:
>>>
>>> java.lang.reflect.Executable#getParameters must throw
>>> ReflectiveOperationException if ...
>>>
>>> Alex
>>>
>>> On 8/20/2013 1:41 PM, Eric McCorkle wrote:
>>>> getAnnotations for each of these calls out to AnnotationParser, which
>>>> does indeed throw an AnnotationFormatError in a variety of cases
>>>> (duplicated annotations, malformed or incomplete annotations, etc).  In
>>>> other cases (ie type mismatches), it delays throwing of exceptions.
>>>> Exceptions coming from the VM (illegal access, bad constant pool
>>>> indexes, parameter mismatches, class casts, and the like) are caught
>>>> and
>>>> rethrown as AnnotationFormatErrors.
>>>>
>>>> In light of this, I'm going to argue the precedent's there.  General
>>>> formatting issues (which I'll argue covers bad names and wrong numbers
>>>> of parameters) cause errors to be thrown immediately, and the
>>>> completely
>>>> analogous case of a bad constant pool index does cause an error to be
>>>> thrown immediately.
>>>>
>>>> I'll also put forward that parameters are a bit different, and favor
>>>> the
>>>> approach of having Executable.getParameters() be able to throw
>>>> exceptions for bad formatting.  Annotations are generally complex, with
>>>> far more complex correctness conditions, and far higher cost to
>>>> transform them from their storage format to reflective objects.  It
>>>> makes sense to defer some of this processing.  MethodParameters, on the
>>>> other hand, are very simple, and the main use case is to get the names
>>>> of parameters.  Therefore, the spec ought to imply, or at least allow
>>>> for an implementation that makes a single trip to the VM per method,
>>>> after which the names are immediately available.  (Also, there are
>>>> several practical advantages to allowing Parameter to be an immutable
>>>> object that cannot be subclassed...)
>>>>
>>>> On 08/20/13 15:38, Alex Buckley wrote:
>>>>> The precedent is AnnotatedElement#getAnnotations as found in Class,
>>>>> Field, Executable, etc. Do those methods validate the
>>>>> RuntimeVisibleAnnotations attribute before returning an array of
>>>>> Annotation objects? I think they do. Can you describe the validation
>>>>> they do which may cause an AnnotationTypeMismatchException or
>>>>> IncompleteAnnotationException?
>>>>>
>>>>> If their validation is "equivalent" to what Executable#getParameters
>>>>> would do, then it would be acceptable to change the spec and
>>>>> implementation of Executable#getParameters and
>>>>> Parameter#getName/Type/etc at this late stage. Please comment ASAP.
>>>>>
>>>>> Alex
>>>>>
>>>>> On 8/20/2013 12:10 PM, Eric McCorkle wrote:
>>>>>> Okay, strike #2 from my requests.  What about having
>>>>>> Executable.getParameters() throw ReflectiveOperationException
>>>>>> instead of
>>>>>> methods in Parameter, for the reasons I discuss?
>>>>>>
>>>>>> On 08/19/13 18:12, Alex Buckley wrote:
>>>>>>> The 8misc.pdf file doesn't say anything about bad constant pool
>>>>>>> indexes.
>>>>>>>
>>>>>>> If MethodParameters was an attribute that the JVM is required to
>>>>>>> recognize and correctly read, then the JVM would be required to
>>>>>>> throw
>>>>>>> ClassFormatError for bad constant pool indexes. But since
>>>>>>> MethodParameters is an attribute that the class libraries of the
>>>>>>> Java SE
>>>>>>> platform - as opposed to the JVM - are required to recognize and
>>>>>>> correctly read, it's the responsibility of the class libraries to
>>>>>>> throw
>>>>>>> something which is a) useful and b) consistent with bad constant
>>>>>>> pool
>>>>>>> indexes for similar situations such as
>>>>>>> AnnotatedElement#getAnnotations
>>>>>>> on a RuntimeVisibleAnnotations attribute.
>>>>>>>
>>>>>>> How the class libraries interact with a JVM implementation to
>>>>>>> determine
>>>>>>> good or bad constant pool entries (e.g. private functions of the JVM
>>>>>>> implementation throw IllegalArgumentException, which
>>>>>>> AnnotatedElement#getAnnotations then wraps as a FooBarException) is
>>>>>>> not
>>>>>>> a matter for the SE API specification. The only thing that
>>>>>>> matters for
>>>>>>> the SE API specification is what something like
>>>>>>> AnnotatedElement#getAnnotations is specified to throw today.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> On 8/19/2013 2:57 PM, Eric McCorkle wrote:
>>>>>>>> The current version of the spec indicates that methods in
>>>>>>>> java.lang.reflect.Parameter should throw
>>>>>>>> ReflectiveOperationException
>>>>>>>> for several cases (wrong number of parameters, bad parameter name,
>>>>>>>> bad
>>>>>>>> constant pool index).
>>>>>>>>
>>>>>>>> I'd like to suggest two (separate) minor revisions:
>>>>>>>>
>>>>>>>> 1) Executable.getParameters() should throw the
>>>>>>>> ReflectiveOperationException in the case of an invalid name or the
>>>>>>>> wrong
>>>>>>>> number of parameters.  The rationale is as follows:
>>>>>>>>
>>>>>>>>      * Doing it this way makes it straightforward to implement
>>>>>>>> j.l.r.Parameter as an immutable object.  Having methods in
>>>>>>>> Parameter
>>>>>>>> throw the exception means Parameter objects will have to remember
>>>>>>>> whether or not they have verified their name (or else verify the
>>>>>>>> name
>>>>>>>> every time they are called).
>>>>>>>>
>>>>>>>>      * Having every single method in Parameter possibly check
>>>>>>>> whether the
>>>>>>>> number of parameters that were returned from the VM is correct
>>>>>>>> seems
>>>>>>>> rather awkward, as opposed to having a single check when Executable
>>>>>>>> obtains the Parameter array back from the VM.
>>>>>>>>
>>>>>>>> 2) In the event of a bad constant pool index, an
>>>>>>>> IllegalArgumentException.
>>>>>>>>
>>>>>>>>      * The current behavior of hotspot whenever it expects a UTF-8
>>>>>>>> constant
>>>>>>>> pool entry, but sees either an out-of-bounds index or something
>>>>>>>> other
>>>>>>>> than a UTF-8 is to throw an IllegalArgumentException.
>>>>>>>>
> 

From alex.buckley at oracle.com  Mon Sep  9 13:15:22 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 09 Sep 2013 13:15:22 -0700
Subject: Method Parameter Reflection spec
In-Reply-To: <522E1B62.30305@oracle.com>
References: <521294AC.2090807@oracle.com> <5212986A.6040704@oracle.com>
	<5213BF1F.6050502@oracle.com> <5213C5B3.9010609@oracle.com>
	<5213D47E.9040607@oracle.com> <5213E944.7050401@oracle.com>
	<5214D6EB.2020007@oracle.com> <52280770.9040008@oracle.com>
	<522E1B62.30305@oracle.com>
Message-ID: <522E2C5A.5060906@oracle.com>

On 9/9/2013 12:02 PM, Eric McCorkle wrote:
> On 09/05/13 00:24, Joe Darcy wrote:
>> I agree the sort of cases below due to corrupt / inconsistent class
>> files are closer in flavor to error conditions than to exceptional ones.
>> An end user program "shouldn't" have to worry about recovering from
>> corrupt class files.
>
> Then it sounds like there's an agreement that the exception(s) should be
> thrown from Executable.getParameters()  Good.
>
> What remains at this point is to determine what exceptions should be
> thrown for what cases.  I don't really have a strong opinion on the
> matter; I'll happily leave that up to someone else.

First, we should stop using ReflectiveOperationException for 
reflection-time detection of malformed MethodParameters. While ROE 
itself is new, it represents the legacy checked exceptions from 
j.l.Class. For j.l.r.Parameter, it would be better to throw unchecked 
exceptions, in line with j.l.r.Field/Executable.

Second, we all agree that the unchecked exceptions should be runtime 
exceptions rather than Errors. (When Joe said "closer in flavor to error 
conditions than to exceptional ones", I don't believe he intended "error 
conditions" to mean java.lang.Error. I think he meant "closer in flavor 
to problematic conditions than to truly exceptional, program-stopping 
ones.")

I suggest MalformedParametersException, a subclass of RuntimeException, 
for cases (ii)-(vi). (Inspired by MalformedParameterizedTypeException.)

Alex

>>> Here's a list of all the ways MethodParameters attributes could go wrong:
>>>
>>> (i) Actual length does not match attribute_length
>>> (ii) The number of parameters (parameter_count) is wrong for the method
>>> (iii) A constant pool index is out of bounds.
>>> (iv) A constant pool index does not refer to a UTF-8 entry
>>> (v) A parameter's name is "", or contains an illegal character [0]
>>> (vi) The flags field contains an illegal flag (something other than
>>> FINAL, SYNTHETIC, or MANDATED)
>>>
>>> (i) causes a ClassFileFormatError when parsing the class file (as it
>>> should).  Right now, (iii) and (iv) cause an IllegalArgumentException to
>>> be thrown.
>>>
>>> I am working on a patch to correct the behavior for (ii)-(vi), so I can
>>> have Executable.getParameters() throw whatever exception you choose (ie.
>>> this is one of those rare moments of freedom).
>>>
>>>
>>> [0]: I seem to recall there being some discussion about backspaces, but
>>> the current version doesn't seem to rule them out.  Has this been
>>> changed?
>>>
>>> On 08/20/13 18:10, Alex Buckley wrote:
>>>> Sounds good. I'd wait a day in case Joe has a comment, then do it.
>>>> Please send a summary to this list of which exceptions are thrown by
>>>> Executable#getParameters and for what reasons. This will let me record
>>>> some more color in section 2.3 of 8misc.pdf, above and beyond the change
>>>> from:
>>>>
>>>> Methods of class java.lang.reflect.Parameter must throw
>>>> ReflectiveOperationException if ...
>>>>
>>>> to:
>>>>
>>>> java.lang.reflect.Executable#getParameters must throw
>>>> ReflectiveOperationException if ...
>>>>
>>>> Alex
>>>>
>>>> On 8/20/2013 1:41 PM, Eric McCorkle wrote:
>>>>> getAnnotations for each of these calls out to AnnotationParser, which
>>>>> does indeed throw an AnnotationFormatError in a variety of cases
>>>>> (duplicated annotations, malformed or incomplete annotations, etc).  In
>>>>> other cases (ie type mismatches), it delays throwing of exceptions.
>>>>> Exceptions coming from the VM (illegal access, bad constant pool
>>>>> indexes, parameter mismatches, class casts, and the like) are caught
>>>>> and
>>>>> rethrown as AnnotationFormatErrors.
>>>>>
>>>>> In light of this, I'm going to argue the precedent's there.  General
>>>>> formatting issues (which I'll argue covers bad names and wrong numbers
>>>>> of parameters) cause errors to be thrown immediately, and the
>>>>> completely
>>>>> analogous case of a bad constant pool index does cause an error to be
>>>>> thrown immediately.
>>>>>
>>>>> I'll also put forward that parameters are a bit different, and favor
>>>>> the
>>>>> approach of having Executable.getParameters() be able to throw
>>>>> exceptions for bad formatting.  Annotations are generally complex, with
>>>>> far more complex correctness conditions, and far higher cost to
>>>>> transform them from their storage format to reflective objects.  It
>>>>> makes sense to defer some of this processing.  MethodParameters, on the
>>>>> other hand, are very simple, and the main use case is to get the names
>>>>> of parameters.  Therefore, the spec ought to imply, or at least allow
>>>>> for an implementation that makes a single trip to the VM per method,
>>>>> after which the names are immediately available.  (Also, there are
>>>>> several practical advantages to allowing Parameter to be an immutable
>>>>> object that cannot be subclassed...)
>>>>>
>>>>> On 08/20/13 15:38, Alex Buckley wrote:
>>>>>> The precedent is AnnotatedElement#getAnnotations as found in Class,
>>>>>> Field, Executable, etc. Do those methods validate the
>>>>>> RuntimeVisibleAnnotations attribute before returning an array of
>>>>>> Annotation objects? I think they do. Can you describe the validation
>>>>>> they do which may cause an AnnotationTypeMismatchException or
>>>>>> IncompleteAnnotationException?
>>>>>>
>>>>>> If their validation is "equivalent" to what Executable#getParameters
>>>>>> would do, then it would be acceptable to change the spec and
>>>>>> implementation of Executable#getParameters and
>>>>>> Parameter#getName/Type/etc at this late stage. Please comment ASAP.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> On 8/20/2013 12:10 PM, Eric McCorkle wrote:
>>>>>>> Okay, strike #2 from my requests.  What about having
>>>>>>> Executable.getParameters() throw ReflectiveOperationException
>>>>>>> instead of
>>>>>>> methods in Parameter, for the reasons I discuss?
>>>>>>>
>>>>>>> On 08/19/13 18:12, Alex Buckley wrote:
>>>>>>>> The 8misc.pdf file doesn't say anything about bad constant pool
>>>>>>>> indexes.
>>>>>>>>
>>>>>>>> If MethodParameters was an attribute that the JVM is required to
>>>>>>>> recognize and correctly read, then the JVM would be required to
>>>>>>>> throw
>>>>>>>> ClassFormatError for bad constant pool indexes. But since
>>>>>>>> MethodParameters is an attribute that the class libraries of the
>>>>>>>> Java SE
>>>>>>>> platform - as opposed to the JVM - are required to recognize and
>>>>>>>> correctly read, it's the responsibility of the class libraries to
>>>>>>>> throw
>>>>>>>> something which is a) useful and b) consistent with bad constant
>>>>>>>> pool
>>>>>>>> indexes for similar situations such as
>>>>>>>> AnnotatedElement#getAnnotations
>>>>>>>> on a RuntimeVisibleAnnotations attribute.
>>>>>>>>
>>>>>>>> How the class libraries interact with a JVM implementation to
>>>>>>>> determine
>>>>>>>> good or bad constant pool entries (e.g. private functions of the JVM
>>>>>>>> implementation throw IllegalArgumentException, which
>>>>>>>> AnnotatedElement#getAnnotations then wraps as a FooBarException) is
>>>>>>>> not
>>>>>>>> a matter for the SE API specification. The only thing that
>>>>>>>> matters for
>>>>>>>> the SE API specification is what something like
>>>>>>>> AnnotatedElement#getAnnotations is specified to throw today.
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> On 8/19/2013 2:57 PM, Eric McCorkle wrote:
>>>>>>>>> The current version of the spec indicates that methods in
>>>>>>>>> java.lang.reflect.Parameter should throw
>>>>>>>>> ReflectiveOperationException
>>>>>>>>> for several cases (wrong number of parameters, bad parameter name,
>>>>>>>>> bad
>>>>>>>>> constant pool index).
>>>>>>>>>
>>>>>>>>> I'd like to suggest two (separate) minor revisions:
>>>>>>>>>
>>>>>>>>> 1) Executable.getParameters() should throw the
>>>>>>>>> ReflectiveOperationException in the case of an invalid name or the
>>>>>>>>> wrong
>>>>>>>>> number of parameters.  The rationale is as follows:
>>>>>>>>>
>>>>>>>>>       * Doing it this way makes it straightforward to implement
>>>>>>>>> j.l.r.Parameter as an immutable object.  Having methods in
>>>>>>>>> Parameter
>>>>>>>>> throw the exception means Parameter objects will have to remember
>>>>>>>>> whether or not they have verified their name (or else verify the
>>>>>>>>> name
>>>>>>>>> every time they are called).
>>>>>>>>>
>>>>>>>>>       * Having every single method in Parameter possibly check
>>>>>>>>> whether the
>>>>>>>>> number of parameters that were returned from the VM is correct
>>>>>>>>> seems
>>>>>>>>> rather awkward, as opposed to having a single check when Executable
>>>>>>>>> obtains the Parameter array back from the VM.
>>>>>>>>>
>>>>>>>>> 2) In the event of a bad constant pool index, an
>>>>>>>>> IllegalArgumentException.
>>>>>>>>>
>>>>>>>>>       * The current behavior of hotspot whenever it expects a UTF-8
>>>>>>>>> constant
>>>>>>>>> pool entry, but sees either an out-of-bounds index or something
>>>>>>>>> other
>>>>>>>>> than a UTF-8 is to throw an IllegalArgumentException.
>>>>>>>>>
>>

From alex.buckley at oracle.com  Mon Sep  9 17:32:46 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 09 Sep 2013 17:32:46 -0700
Subject: Method Parameter Reflection spec
In-Reply-To: <522E2C5A.5060906@oracle.com>
References: <521294AC.2090807@oracle.com> <5212986A.6040704@oracle.com>
	<5213BF1F.6050502@oracle.com> <5213C5B3.9010609@oracle.com>
	<5213D47E.9040607@oracle.com> <5213E944.7050401@oracle.com>
	<5214D6EB.2020007@oracle.com> <52280770.9040008@oracle.com>
	<522E1B62.30305@oracle.com> <522E2C5A.5060906@oracle.com>
Message-ID: <522E68AE.7030808@oracle.com>

I have updated the 8misc.pdf spec with the conditions for throwing 
MalformedParametersException.

Hopefully this will be the last update of the spec before it is 
integrated into the JLS and JVMS as part of their updates for the Public 
Review of JSR 337 in October.

Alex

On 9/9/2013 1:15 PM, Alex Buckley wrote:
> On 9/9/2013 12:02 PM, Eric McCorkle wrote:
>> On 09/05/13 00:24, Joe Darcy wrote:
>>> I agree the sort of cases below due to corrupt / inconsistent class
>>> files are closer in flavor to error conditions than to exceptional ones.
>>> An end user program "shouldn't" have to worry about recovering from
>>> corrupt class files.
>>
>> Then it sounds like there's an agreement that the exception(s) should be
>> thrown from Executable.getParameters()  Good.
>>
>> What remains at this point is to determine what exceptions should be
>> thrown for what cases.  I don't really have a strong opinion on the
>> matter; I'll happily leave that up to someone else.
>
> First, we should stop using ReflectiveOperationException for
> reflection-time detection of malformed MethodParameters. While ROE
> itself is new, it represents the legacy checked exceptions from
> j.l.Class. For j.l.r.Parameter, it would be better to throw unchecked
> exceptions, in line with j.l.r.Field/Executable.
>
> Second, we all agree that the unchecked exceptions should be runtime
> exceptions rather than Errors. (When Joe said "closer in flavor to error
> conditions than to exceptional ones", I don't believe he intended "error
> conditions" to mean java.lang.Error. I think he meant "closer in flavor
> to problematic conditions than to truly exceptional, program-stopping
> ones.")
>
> I suggest MalformedParametersException, a subclass of RuntimeException,
> for cases (ii)-(vi). (Inspired by MalformedParameterizedTypeException.)
>
> Alex
>
>>>> Here's a list of all the ways MethodParameters attributes could go
>>>> wrong:
>>>>
>>>> (i) Actual length does not match attribute_length
>>>> (ii) The number of parameters (parameter_count) is wrong for the method
>>>> (iii) A constant pool index is out of bounds.
>>>> (iv) A constant pool index does not refer to a UTF-8 entry
>>>> (v) A parameter's name is "", or contains an illegal character [0]
>>>> (vi) The flags field contains an illegal flag (something other than
>>>> FINAL, SYNTHETIC, or MANDATED)
>>>>
>>>> (i) causes a ClassFileFormatError when parsing the class file (as it
>>>> should).  Right now, (iii) and (iv) cause an
>>>> IllegalArgumentException to
>>>> be thrown.
>>>>
>>>> I am working on a patch to correct the behavior for (ii)-(vi), so I can
>>>> have Executable.getParameters() throw whatever exception you choose
>>>> (ie.
>>>> this is one of those rare moments of freedom).
>>>>
>>>>
>>>> [0]: I seem to recall there being some discussion about backspaces, but
>>>> the current version doesn't seem to rule them out.  Has this been
>>>> changed?

From joe.darcy at oracle.com  Tue Sep 10 17:04:03 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Tue, 10 Sep 2013 17:04:03 -0700
Subject: Method Parameter Reflection spec
In-Reply-To: <522E2C5A.5060906@oracle.com>
References: <521294AC.2090807@oracle.com> <5212986A.6040704@oracle.com>
	<5213BF1F.6050502@oracle.com> <5213C5B3.9010609@oracle.com>
	<5213D47E.9040607@oracle.com> <5213E944.7050401@oracle.com>
	<5214D6EB.2020007@oracle.com> <52280770.9040008@oracle.com>
	<522E1B62.30305@oracle.com> <522E2C5A.5060906@oracle.com>
Message-ID: <522FB373.6040308@oracle.com>

On 9/9/2013 1:15 PM, Alex Buckley wrote:
> On 9/9/2013 12:02 PM, Eric McCorkle wrote:
>> On 09/05/13 00:24, Joe Darcy wrote:
>>> I agree the sort of cases below due to corrupt / inconsistent class
>>> files are closer in flavor to error conditions than to exceptional 
>>> ones.
>>> An end user program "shouldn't" have to worry about recovering from
>>> corrupt class files.
>>
>> Then it sounds like there's an agreement that the exception(s) should be
>> thrown from Executable.getParameters()  Good.
>>
>> What remains at this point is to determine what exceptions should be
>> thrown for what cases.  I don't really have a strong opinion on the
>> matter; I'll happily leave that up to someone else.
>
> First, we should stop using ReflectiveOperationException for 
> reflection-time detection of malformed MethodParameters. While ROE 
> itself is new, it represents the legacy checked exceptions from 
> j.l.Class. For j.l.r.Parameter, it would be better to throw unchecked 
> exceptions, in line with j.l.r.Field/Executable.
>
> Second, we all agree that the unchecked exceptions should be runtime 
> exceptions rather than Errors. (When Joe said "closer in flavor to 
> error conditions than to exceptional ones", I don't believe he 
> intended "error conditions" to mean java.lang.Error. I think he meant 
> "closer in flavor to problematic conditions than to truly exceptional, 
> program-stopping ones.")
>
> I suggest MalformedParametersException, a subclass of 
> RuntimeException, for cases (ii)-(vi). (Inspired by 
> MalformedParameterizedTypeException.)
>
> Alex

Hello,

The conditions under discussion actually seem to me most like the 
conditions associated with true errors such as:

     java.lang.AnnotationFormatError
     java.lang.ClassFormatError (subclass of LinkageError)

Whatever Throwable subtype we use for corrupt parameters information, it 
should certainly not be a checked exception. I think using a error as 
opposed to a runtime exception would be more consistent, but I'm willing 
to be convinced otherwise.

-Joe

From alex.buckley at oracle.com  Tue Sep 10 17:30:40 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 10 Sep 2013 17:30:40 -0700
Subject: Method Parameter Reflection spec
In-Reply-To: <522FB373.6040308@oracle.com>
References: <521294AC.2090807@oracle.com> <5212986A.6040704@oracle.com>
	<5213BF1F.6050502@oracle.com> <5213C5B3.9010609@oracle.com>
	<5213D47E.9040607@oracle.com> <5213E944.7050401@oracle.com>
	<5214D6EB.2020007@oracle.com> <52280770.9040008@oracle.com>
	<522E1B62.30305@oracle.com> <522E2C5A.5060906@oracle.com>
	<522FB373.6040308@oracle.com>
Message-ID: <522FB9B0.3020301@oracle.com>

On 9/10/2013 5:04 PM, Joseph Darcy wrote:
> The conditions under discussion actually seem to me most like the
> conditions associated with true errors such as:
>
>      java.lang.AnnotationFormatError
>      java.lang.ClassFormatError (subclass of LinkageError)
>
> Whatever Throwable subtype we use for corrupt parameters information, it
> should certainly not be a checked exception. I think using a error as
> opposed to a runtime exception would be more consistent, but I'm willing
> to be convinced otherwise.

Sorry, I misunderstood your prior mail.

My skepticism about throwing an Error comes from the fact that using 
reflection to load a class causes ClassNotFoundException rather than 
NoClassDefFoundError. Similarly, using reflection to inspect a field 
causes NoSuchFieldException rather than NoSuchFieldError; and 
NoSuchMethodException rather than NoSuchMethodError for a method. That 
is, Errors come from the VM and Exceptions come from the Core Reflection 
API. An Error - especially from the VM! - means your program is dead in 
the water, but a client of the Core Reflection API should be able to 
handle a few little Exceptions because the members it thought were 
present are not.

(It's dumb that the Exceptions are checked, but that's orthogonal.)

This suggests throwing ClassFormatException (unchecked) when Core 
Reflection tries to read a malformed class file attribute. It's nothing 
like as serious as a LinkageError. A client of the Core Reflection API 
will simply act as if there are no annotations, parameters, whatever.

Then, dedicated Throwable subtypes for "Can't read 
RuntimeVisibleAnnotations attribute or its cpool entries" and "Can't 
read MethodParameters attribute or its cpool entries" would be unnecessary.

But I recognize that AnnotationFormatError may have set a precedent :-)

Alex

From pbenedict at apache.org  Fri Sep 13 13:39:04 2013
From: pbenedict at apache.org (Paul Benedict)
Date: Fri, 13 Sep 2013 15:39:04 -0500
Subject: Supertype of MalformedParametersException
Message-ID: <CABLGb9y7K39mVf4cnjof8Kk+v_WH1XNW_KMbc+vaDD6XWHuQ5w@mail.gmail.com>

I think the consistent exception hierarchy for reflective operations should
remain in tact. Although it's annoying checked exceptions exist, my
preference would be to extend from ReflectiveOperationException rather than
RuntimeException.

Thoughts?

-- 
Cheers,
Paul

From alex.buckley at oracle.com  Fri Sep 13 14:32:59 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 13 Sep 2013 14:32:59 -0700
Subject: Supertype of MalformedParametersException
In-Reply-To: <CABLGb9y7K39mVf4cnjof8Kk+v_WH1XNW_KMbc+vaDD6XWHuQ5w@mail.gmail.com>
References: <CABLGb9y7K39mVf4cnjof8Kk+v_WH1XNW_KMbc+vaDD6XWHuQ5w@mail.gmail.com>
Message-ID: <5233848B.1000502@oracle.com>

The general theme is that we do the "right thing" for new types like 
j.l.r.Executable, rather than going for consistency at all costs. So, 
we've decided to throw an unchecked exception class from getParameters() 
when the class file is bad.

The open issue is whether it should be a run-time exception class or an 
error class.

Alex

On 9/13/2013 1:39 PM, Paul Benedict wrote:
> I think the consistent exception hierarchy for reflective operations should
> remain in tact. Although it's annoying checked exceptions exist, my
> preference would be to extend from ReflectiveOperationException rather than
> RuntimeException.
>
> Thoughts?
>

From jesper at selskabet.org  Tue Sep 24 12:09:26 2013
From: jesper at selskabet.org (=?iso-8859-1?Q?Jesper_Steen_M=F8ller?=)
Date: Tue, 24 Sep 2013 21:09:26 +0200
Subject: Deprecated container annotations
Message-ID: <A1E9F3CD-3D9E-4438-B0D4-2F809C038A3D@selskabet.org>

Hi List

I'm implementing repeated annotations in the Eclipse Java compiler, and have come across a question as to the interpretation of the deprecation of the containing annotation. 

As I read the changes in 9.6.3.6, the following code:

@java.lang.annotation.Repeatable(FooContainer.class)
@interface Foo {
}

@Deprecated @interface FooContainer {
    Foo[] value();
}

@Foo @Foo public class Y {
}


... should this give a deprecation warning near the repeated usage of @Foo (which causes the implied declaration of @FooContainer), if compiling with -Xlint. Is this correct?

-Jesper

From alex.buckley at oracle.com  Wed Sep 25 11:14:39 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 25 Sep 2013 11:14:39 -0700
Subject: Deprecated container annotations
In-Reply-To: <A1E9F3CD-3D9E-4438-B0D4-2F809C038A3D@selskabet.org>
References: <A1E9F3CD-3D9E-4438-B0D4-2F809C038A3D@selskabet.org>
Message-ID: <5243280F.4010201@oracle.com>

Hi Jesper,

You are correct:

- By JLS8 9.6, Foo is a legal repeatable annotation type, and 
FooContainer is a legal containing annotation type of Foo, so the Java 
language has no warnings or errors for the declarations of Foo and 
FooContainer.

- By JLS8 9.6.3.6, the deprecated type FooContainer is used in the 
container annotation @FooContainer which is implicitly declared at the 
site of @Foo @Foo. So, a deprecation warning is due at @Foo @Foo. A note 
in 9.6.3.6 identifies the possibility of an "invisible" container 
annotation causing a warning.

Alex

On 9/24/2013 12:09 PM, Jesper Steen M?ller wrote:
> Hi List
>
> I'm implementing repeated annotations in the Eclipse Java compiler, and have come across a question as to the interpretation of the deprecation of the containing annotation.
>
> As I read the changes in 9.6.3.6, the following code:
>
> @java.lang.annotation.Repeatable(FooContainer.class)
> @interface Foo {
> }
>
> @Deprecated @interface FooContainer {
>      Foo[] value();
> }
>
> @Foo @Foo public class Y {
> }
>
>
> ... should this give a deprecation warning near the repeated usage of @Foo (which causes the implied declaration of @FooContainer), if compiling with -Xlint. Is this correct?
>
> -Jesper
>

From srikanth_sankaran at in.ibm.com  Wed Sep 25 20:06:52 2013
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Thu, 26 Sep 2013 08:36:52 +0530
Subject: enhanced-metadata-spec-discuss Digest, Vol 13, Issue 6
In-Reply-To: <mailman.39.1380135602.8046.enhanced-metadata-spec-discuss@openjdk.java.net>
References: <mailman.39.1380135602.8046.enhanced-metadata-spec-discuss@openjdk.java.net>
Message-ID: <OF239531D6.0B8532A2-ON65257BF2.00070E1B-65257BF2.00114455@in.ibm.com>

> From: enhanced-metadata-spec-discuss-request at openjdk.java.net
> Sent by: enhanced-metadata-spec-discuss-bounces at openjdk.java.net

> As I read the changes in 9.6.3.6, the following code:
> 
> @java.lang.annotation.Repeatable(FooContainer.class)
> @interface Foo {
> }
> 
> @Deprecated @interface FooContainer {
>     Foo[] value();
> }
> 
> @Foo @Foo public class Y {
> }
> 
> 
> ... should this give a deprecation warning near the repeated usage 
> of @Foo (which causes the implied declaration of @FooContainer), if 
> compiling with -Xlint. Is this correct?


[...]

> - By JLS8 9.6, Foo is a legal repeatable annotation type, and 
> FooContainer is a legal containing annotation type of Foo, so the Java 
> language has no warnings or errors for the declarations of Foo and 
> FooContainer.
> 
> - By JLS8 9.6.3.6, the deprecated type FooContainer is used in the 
> container annotation @FooContainer which is implicitly declared at the 
> site of @Foo @Foo. So, a deprecation warning is due at @Foo @Foo. A note 

> in 9.6.3.6 identifies the possibility of an "invisible" container 
> annotation causing a warning.


Alex, could you please recheck if 9.6.3.6 is clear enough - Everytime I
read it, I get confused, I grant that it could just be me.

"The only time a deprecation warning can occur for a construct which is 
implicitly declared
is if a container annotation (?9.7.5) has a containing annotation type 
which is deprecated."

Is this better worded as "... if a repeating (and repeatable) annotation 
has a container annotation type which is deprecated" ?"

or "declared is for container annotations which are deprecated"

The present wording "container annotation (?9.7.5) has a containing 
annotation type" 
seems to invoke images of container's container.

Srikanth

From alex.buckley at oracle.com  Thu Sep 26 10:35:21 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 26 Sep 2013 10:35:21 -0700
Subject: enhanced-metadata-spec-discuss Digest, Vol 13, Issue 6
In-Reply-To: <OF239531D6.0B8532A2-ON65257BF2.00070E1B-65257BF2.00114455@in.ibm.com>
References: <mailman.39.1380135602.8046.enhanced-metadata-spec-discuss@openjdk.java.net>
	<OF239531D6.0B8532A2-ON65257BF2.00070E1B-65257BF2.00114455@in.ibm.com>
Message-ID: <52447059.5080408@oracle.com>

On 9/25/2013 8:06 PM, Srikanth S Adayapalam wrote:
> Alex, could you please recheck if 9.6.3.6 is clear enough - Everytime
> I read it, I get confused, I grant that it could just be me.
>
> "The only time a deprecation warning can occur for a construct which
> is implicitly declared is if a container annotation (?9.7.5) has a
> containing annotation type which is deprecated."
>
> Is this better worded as "... if a repeating (and repeatable)
> annotation has a container annotation type which is deprecated" ?"
>
> or "declared is for container annotations which are deprecated"
>
> The present wording "container annotation (?9.7.5) has a containing
> annotation type" seems to invoke images of container's container.

I see what you mean. I will spell it out:

"The only implicitly declared construct that can cause a deprecation 
warning is a container annotation (9.7.5). Namely, if T is a repeatable 
annotation type and TC is its containing annotation type, and TC is 
deprecated, then repeating the @T annotation will cause a deprecation 
warning. The warning is due to the implicit @TC container annotation. No 
warnings are required for the declarations of T and TC, though it is 
strongly discouraged to deprecate a containing annotation type without 
also deprecating the repeatable annotation type."

Alex

From jesper at selskabet.org  Thu Sep 26 13:49:20 2013
From: jesper at selskabet.org (=?iso-8859-1?Q?Jesper_Steen_M=F8ller?=)
Date: Fri, 27 Sep 2013 00:49:20 +0400
Subject: enhanced-metadata-spec-discuss Digest, Vol 13, Issue 6
In-Reply-To: <52447059.5080408@oracle.com>
References: <mailman.39.1380135602.8046.enhanced-metadata-spec-discuss@openjdk.java.net>
	<OF239531D6.0B8532A2-ON65257BF2.00070E1B-65257BF2.00114455@in.ibm.com>
	<52447059.5080408@oracle.com>
Message-ID: <781AC713-8F40-4867-A904-5F476F1648C0@selskabet.org>


On 26/09/2013, at 21.35, Alex Buckley wrote:

> On 9/25/2013 8:06 PM, Srikanth S Adayapalam wrote:
>> Alex, could you please recheck if 9.6.3.6 is clear enough - Everytime
>> I read it, I get confused, I grant that it could just be me.
>> 
>> "The only time a deprecation warning can occur for a construct which
>> is implicitly declared is if a container annotation (?9.7.5) has a
>> containing annotation type which is deprecated."
>> 
>> Is this better worded as "... if a repeating (and repeatable)
>> annotation has a container annotation type which is deprecated" ?"
>> 
>> or "declared is for container annotations which are deprecated"
>> 
>> The present wording "container annotation (?9.7.5) has a containing
>> annotation type" seems to invoke images of container's container.
> 
> I see what you mean. I will spell it out:
> 
> "The only implicitly declared construct that can cause a deprecation warning is a container annotation (9.7.5). Namely, if T is a repeatable annotation type and TC is its containing annotation type, and TC is deprecated, then repeating the @T annotation will cause a deprecation warning. The warning is due to the implicit @TC container annotation. No warnings are required for the declarations of T and TC, though it is strongly discouraged to deprecate a containing annotation type without also deprecating the repeatable annotation type."
> 

Thanks for the clarification.
Nitpicking: The declaration of T would give a deprecation warning for the use of TC.class in @Repeatable(TC.class), but I guess this is unrelated to this clause.

By the way, javac b108 doesn't issue the use on repeated use of T, as in my original example. One for the compiler-dev list?

-Jesper

From alex.buckley at oracle.com  Fri Sep 27 09:59:14 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 27 Sep 2013 09:59:14 -0700
Subject: enhanced-metadata-spec-discuss Digest, Vol 13, Issue 6
In-Reply-To: <781AC713-8F40-4867-A904-5F476F1648C0@selskabet.org>
References: <mailman.39.1380135602.8046.enhanced-metadata-spec-discuss@openjdk.java.net>
	<OF239531D6.0B8532A2-ON65257BF2.00070E1B-65257BF2.00114455@in.ibm.com>
	<52447059.5080408@oracle.com>
	<781AC713-8F40-4867-A904-5F476F1648C0@selskabet.org>
Message-ID: <5245B962.9000105@oracle.com>

On 9/26/2013 1:49 PM, Jesper Steen M?ller wrote:
> Nitpicking: The declaration of T would give a deprecation warning for
> the use of TC.class in @Repeatable(TC.class), but I guess this is
> unrelated to this clause.

Nitpicking is good! You are right. While the "interesting" situation is 
a deprecation warning at the use site (@T @T), a warning is also due at 
the declaration site for T because of TC.class. I will not say "No 
warnings are required for the declarations of T and TC" in the text.

> By the way, javac b108 doesn't issue the use on repeated use of T, as
> in my original example. One for the compiler-dev list?

Yes, or file a bug at bugs.openjdk.java.net in the tools/javac areas.

Alex