javap with classfile API

[Rafael Winterhalter]

My bad, my simple reproduction was too simple. If I make it an abstract
super class with two subclasses, where one ("$Missing") is not available
during instrumentation (for example from a build plugin), then the
OpenJDK-generated byte code will be as follows:

  m(I)V
    ILOAD 1
    IFEQ L0
    NEW codes/rafael/asmjdkbridge/sample/FrameWithMissingType$Sub
    DUP
    INVOKESPECIAL
codes/rafael/asmjdkbridge/sample/FrameWithMissingType$Sub.<init> ()V
    ASTORE 2
    GOTO L1
   L0
   FRAME SAME
    NEW codes/rafael/asmjdkbridge/sample/FrameWithMissingType$Missing
    DUP
    INVOKESPECIAL
codes/rafael/asmjdkbridge/sample/FrameWithMissingType$Missing.<init> ()V
    ASTORE 2
   L1
   FRAME APPEND [codes/rafael/asmjdkbridge/sample/FrameWithMissingType$Sub]
// should be "$Base"
    ALOAD 2
    INVOKEVIRTUAL
codes/rafael/asmjdkbridge/sample/FrameWithMissingType$Base.m ()V
    RETURN

With ASM and explicit frame writing, the frames are issued correctly. With
the OpenJDK version, the verification error occurs at the frame location as
it might contain "$Missing" (which is now present again at runtime). I have
updated the code sample to represent this scenario.

Best regards, Rafael

Am Di., 12. Juli 2022 um 11:48 Uhr schrieb Adam Sotona <
adam.sotona at oracle.com>:

> 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/20220714/28ff054c/attachment-0001.htm>