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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
