Test cases related to JSR 292

[forum at x9c.fr]

Le 22 avr. 2011 à 16:42, Rémi Forax a écrit :

> 
>>> This is a possibility, hoping that the entry ticket to the ASM API is not to high.
>>> 
>>> While developing the code to read/write a JDK7 class file, I noticed what I think
>>> is a typo on the "http://download.java.net/jdk7/docs/api/java/lang/invoke/package-summary.html"
>>> page. The line:
>>> 	u1 reference_kind;       // 1..8 (one of REF_invokeVirtual, etc.)
>>> should probably be:
>>> 	u1 reference_kind;       // 1..9 (one of REF_invokeVirtual, etc.)
>>> unless interface methods are explicitly forbidden. In the latter case, what is
>>> the motive?
>> Sorry for the noise, but I have another question regarding the aforementioned URL
>> that I use as a specification for JSR 292. It is not clear which elements can embed
>> a "BootstrapMethods" attribute, possible candidates being, at first sight:
>>   - a "Code" attribute;
>>   - a method;
>>   - a class.
>> 
>> My first move would be to regard this attribute as reserved to a "Code" attribute,
>> but it seems that data sharing would be increased by putting it a the class level.
> 
> The BootstrapMethods attribute is a class attribute.
> And you're right that this is not written anywhere :(
> We should fix that too.

Thanks for the clarification. This is what I figured out from an ancient hg commit,
but my intuition was conflicting with this fact...

Can you elaborate on the rationale behind this EG choice?
The only advantage I can think of is data sharing, but it seems more or less
done by the constant pool. I would have placed "BootstrapMethods" at the same
level as "LineNumberTable" or "StackMapTable", based on some kind of locality
property.


Xavier