SafeVarargs classfile encoding

Joe Darcy joe.darcy at
Fri Jan 21 12:03:53 PST 2011

Rémi Forax wrote:
> On 01/21/2011 08:34 PM, Joe Darcy wrote:
>> Rémi Forax wrote:
>>> On 01/21/2011 07:50 PM, Joe Darcy wrote:
>>>> Hi Rémi.
>>>> A few comments, in the entirety of the "jdk" repository, there were 
>>>> a total of five methods where it was appropriate to add this 
>>>> annotation, which is not a very high density!  For Coin, to keep 
>>>> the features small, we're avoiding JVM changes and defining a new 
>>>> attribute is a JVM changes of sorts.
>>> Here is the JVM spec change:
>> [snip]
>> The size of the JVM change is not the problem; the fact that 
>> potentially all class file consuming tools would need to know about 
>> the attribute is.
> No because it's an empty attribute. I will be ignored by classfile 
> reader, and copied by classfile read/writer.
> see section 4.7.1 of the VM spec.

Tools like pack200 would have to be updated to know to preserve the 
attribute as opposed to dropping it on the floor, etc.

>>   Additionally, this would be a new kind of side-effect of annotating 
>> a method.
> I don't understand your point here.
> SafeVarargs doesn't alter the semantics of a method for the VM,
> like Deprecated or Synthetic which are already defined as attribute.

Perhaps other than @Deprecated (I'm not going to look up to verify the 
situation right now), there is no case where putting an annotation on a 
method has the side-effect of altering the generated class file in a way 
other than having the annotation represented in the class file, if 

>>>> Using an annotation to store this information avoids the need to 
>>>> add a new core reflection API to access it, Method.isSafeVarargs, etc.
>>> Why SafeVarargs need to be visible using reflection API ?
>> Why should the information be excluded?  This annotation is a 
>> statement about the semantics of the method.
> This annotation doesn't alter the *runtime* semantics of a method.

However the annotation is an assertion about the runtime semantics of a 
method, an assertion someone introspecting on the method may be 
interested in knowing.


More information about the coin-dev mailing list