Le 21 avr. 2011 à 21:36, Rémi Forax a écrit : > On 04/21/2011 09:20 PM, [email protected] wrote: >> Le 21 avr. 2011 à 19:07, John Rose a écrit : >> >>> On Apr 21, 2011, at 9:41 AM, [email protected] 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? Regards, Xavier _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
