Test cases related to JSR 292

Rémi Forax forax at univ-mlv.fr
Thu Apr 21 12:36:06 PDT 2011


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).

Rémi



More information about the mlvm-dev mailing list