javap with classfile API

[Adam Sotona]

Hi Rafael,
Could you, please, add tests cases where classfile-api-dev-branch javap output differs from standard javap?
These cases should be added into javap tests to cover backward compatibility of the output.

Thanks,
Adam

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Rafael Winterhalter <rafael.wth at gmail.com>
Date: Tuesday, 12 July 2022 0:09
To: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
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, 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/76add623/attachment-0001.htm>