Test cases related to JSR 292

[forum at x9c.fr]

Le 22 avr. 2011 à 07:42, forum at x9c.fr a écrit :

> 
> Le 21 avr. 2011 à 21:36, Rémi Forax a écrit :
> 
>> On 04/21/2011 09:20 PM, forum at x9c.fr wrote:
>>> Le 21 avr. 2011 à 19:07, John Rose a écrit :
>>> 
>>>> On Apr 21, 2011, at 9:41 AM, forum at x9c.fr wrote:
>>>> 
>>>>> Thanks for the information.
>>>>> I wondered whether the EG had a "hidden" set of tests cases...
>>>> I think there are two "hidden" sets, neither of which are (AFAIK) open source:  There is an engineering group in Oracle which is developing JCK tests.  IBM's J9 group has their own implementation, which presumably has unit tests.  The EG as a whole has no access to these, though individual members do.
>>>> 
>>>> The EG's workflow is pretty simple:  We discuss the API, and I push the decisions (and sometimes suggestions under discussion) into the Reference Implementation javadoc.  The RI is staged on the mlvm-dev patch repo, and then into OpenJDK.
>>>> 
>>>> The reference implementation is in OpenJDK (7 not 6), which includes the unit tests Christian referred to.  They consist of JUnit files like "MethodHandlesTest.java".  Invokedynamic coverage goes through the "Indify" hack to generate the instructions from Java source.
>>>> 
>>>> Beyond that, invokedynamic is exercised vigorously by the language implementations which are beginning to use it, such as JRuby.
>>> Ho, yes I perfectly understand the workflow and do find it legitimate.
>>> I was not worried about the quality of others' work, and I use the
>>> information from the Javadoc as amendments to the class file
>>> format. Everything is fine on this side.
>>> 
>>> 
>>> As the developer of a class file manipulation library, I would like to
>>> test it over ".class" files using various flavors of "invokedynamic"
>>> settings. Just to verify that the library can successfully load classes
>>> with "invokedynamic" instructions, associated attributes, and constant
>>> pool elements.
>>> 
>>> Indeed, this is my work that I want to scrutinize!
>>> 
>>> 
>>> Regards,
>>> 
>>> Xavier
>> 
>> Xavier,
>> you can use ASM to generate your tests and your lib to read them (or 
>> vice versa).
> 
> 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.

Thanks for any insight.


Regards,

Xavier