SafeVarargs classfile encoding
forax at univ-mlv.fr
Fri Jan 21 11:53:16 PST 2011
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:
> 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.
> 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.
>>> 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.
>> By example, Synthetic attribute is not visible using reflection API.
> Some synthetic information is exposed in core reflection:
Ok, bad example.
More information about the coin-dev