Le 22 avr. 2011 à 07:42, fo...@x9c.fr a écrit : > > Le 21 avr. 2011 à 21:36, Rémi Forax a écrit : > >> On 04/21/2011 09:20 PM, fo...@x9c.fr wrote: >>> Le 21 avr. 2011 à 19:07, John Rose a écrit : >>> >>>> On Apr 21, 2011, at 9:41 AM, fo...@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
