javap with classfile API

[Remi Forax]

> From: "Rafael Winterhalter" <rafael.wth at gmail.com>
> To: "classfile-api-dev" <classfile-api-dev at openjdk.org>
> Sent: Tuesday, July 12, 2022 12:09:06 AM
> Subject: javap with classfile API

> Hello,

> I completed a full round of comparing byte code output with ASM and OpenJDK's
> APIs and doing so, I was using the sandboxes version of javap. I found some
> errors in the tool doing so which I fixed for my own convenience on the way (if
> you wanted to adapt those fixes, [
> https://github.com/openjdk/jdk-sandbox/pull/21 |
> https://github.com/openjdk/jdk-sandbox/pull/21 ] , basically it makes the javap
> output identical to the ASM-based version).

> I was however wondering about printing dynamic constants:

> 1. For invokedynamic instructions,

> printConstantPoolRefAndValue(instr.invokedynamic(), 0)

> is used. I would not know why the 0 is printed here, but it was printed
> previously. Possibly, it was meant to yield an equivalent output for the
> "count" (JVMS 6.5) value of interface calls, but I do not see its value. Maybe
> this should be changed in javap.

invokedynamic format is 5 bytes with the same encoding as invokevirtual, the opcode, two bytes for the constant and two bytes that are 0. 
Those two bytes initially at 0 are used by the VM to reference the target of the CallSite once the BSM is executed. 

see https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-6.html#jvms-6.5.invokedynamic 

> 2. I changed the print of DynamicConstantPoolEntrys to

> print("#" + info.bootstrap().bsmIndex() + ":#" + info.nameAndType().index());

> , the same that is used in the string representation. Previously, the index was
> read via info.bootstrap().bootstrapMethod().index() - I do not quite understand
> why those two would be different, and bsmIndex seems to return 0 for lambda
> meta factory values, but it is indeed the old behavior. Maybe printing the
> reference to lambda meta factory would however be the better option. In this
> case, the string representation should however also be adjusted.

> 3. For handle types, the internal constant names were printed. Those are not
> part of the spec, so I changed it to print the documented REF_abc values. Those
> do however not indicate if a reference addresses an interface invocation; maybe
> this information should be included in javap.

> 4. I thought I found a row of issues with printing in-code type annotation type
> references, but it seems that javac has a row of issues with adding them to
> class files. So it's javac who gets those wrong, not javap. I validated that
> this has been an issue previously and is not related to the change in class
> file emitter. I reported these issues here ( [
> https://bugs.openjdk.org/browse/JDK-8290125 |
> https://bugs.openjdk.org/browse/JDK-8290125 ] ) but wanted to mention it if
> anybody ran into the same issue.

> Best regards, Rafael

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220712/47c65ff0/attachment.htm>