javap with classfile API

[Rafael Winterhalter]

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

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) but wanted to mention it if
anybody ran into the same issue.

Best regards, Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220712/eddac053/attachment.htm>