From markro at cs.washington.edu  Sun Feb  9 18:47:53 2025
From: markro at cs.washington.edu (Mark Roberts)
Date: Sun, 9 Feb 2025 10:47:53 -0800
Subject: ClassPrinter
Message-ID: <a373dabab96160c44a118b4342edc627@mail.gmail.com>

With the removal of ?components? to jdk/internal what is the best way to
get the functionality of ClassPrinter?



Thank you, Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250209/87af0a1c/attachment.htm>

From markro at cs.washington.edu  Mon Feb 10 00:22:22 2025
From: markro at cs.washington.edu (Mark Roberts)
Date: Sun, 9 Feb 2025 16:22:22 -0800
Subject: problems with ldc on 24.36
Message-ID: <2b6470d6a896ae60fbd41625d4ffd379@mail.gmail.com>

I just changed from 24-ea+22-2649 to 24+36-3646 and almost all my test
cases worked fine.  However, I ran into a problem with ldc:



ConstantInstruction.ofLoad(Opcode.LDC,
poolBuilder.stringEntry(binaryClassName))



This used to work if the constant pool entry for binaryClassName was >256 ?
it would automatically generate a ldc_w.



Now it generates a ldc and uses just the lower 8 bits of the offset.  This
seems like a problem as a user is not expected to know the constant pool
offset, are they?



Thank you,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250209/249b01a9/attachment.htm>

From liangchenblue at gmail.com  Mon Feb 10 00:42:52 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Sun, 9 Feb 2025 18:42:52 -0600
Subject: problems with ldc on 24.36
In-Reply-To: <2b6470d6a896ae60fbd41625d4ffd379@mail.gmail.com>
References: <2b6470d6a896ae60fbd41625d4ffd379@mail.gmail.com>
Message-ID: <CABe8uE0Txkar_eHrv43Yw0KMCyr-79if8oK2V2hH8-40QYn8Hg@mail.gmail.com>

Hello Mark,
This indeed is a bug; we can change this in 25 to make any entry with LDC
that has a pool entry with index over 0xFF throw IllegalArgumentException,
and add a new ofLoad and ofArgument factories that do not require the
Opcode (ClassFile API can choose a suitable opcode in these cases). We
anticipate users to call CodeBuilder.loadConstant(ConstantDesc) or
loadConstant(LoadableConstantEntry) so we did not enhance this more
complicated API.

This behavior exists so we allow specifying the Opcode, so that you can use
LDC_W for small index constants; before we automatically converted those
LDC_W to LDC even if the entry is from the same CP as the CodeBuilder; see
https://github.com/openjdk/jdk/blob/8f6ccde9829ea0e4fe1c087e68bec4d9efb55c64/src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java#L1352

A similar truncation issue was noted in
https://bugs.openjdk.org/browse/JDK-8341277 and fixed; but it didn't handle
CP indices, and this indeed is a good bug to fix for 25.

Regards, Chen

On Sun, Feb 9, 2025 at 6:22?PM Mark Roberts <markro at cs.washington.edu>
wrote:

> I just changed from 24-ea+22-2649 to 24+36-3646 and almost all my test
> cases worked fine.  However, I ran into a problem with ldc:
>
>
>
> ConstantInstruction.ofLoad(Opcode.LDC,
> poolBuilder.stringEntry(binaryClassName))
>
>
>
> This used to work if the constant pool entry for binaryClassName was >256
> ? it would automatically generate a ldc_w.
>
>
>
> Now it generates a ldc and uses just the lower 8 bits of the offset.  This
> seems like a problem as a user is not expected to know the constant pool
> offset, are they?
>
>
>
> Thank you,
>
> Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250209/e5c12cf5/attachment-0001.htm>

From liangchenblue at gmail.com  Mon Feb 10 00:53:48 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Sun, 9 Feb 2025 18:53:48 -0600
Subject: ClassPrinter
In-Reply-To: <a373dabab96160c44a118b4342edc627@mail.gmail.com>
References: <a373dabab96160c44a118b4342edc627@mail.gmail.com>
Message-ID: <CABe8uE1DRAchiJ6nH9bFH1Wk9HMPxQLLJQQVvVkHEbiR99iw=A@mail.gmail.com>

Hello Mark,
You can use the toDebugString defined on CompoundElement. Note that
ClassModel, FieldModel, MethodModel, CodeModel are CompoundElement.
https://bugs.openjdk.org/browse/JDK-8345774

We found that debug printing is necessary, but formatting them to json or
yaml consistently doesn't make so much sense as the print output is really
for human consumption. For programs, just work on the ClassFile API model
objects.

Regards,
Chen

On Sun, Feb 9, 2025 at 12:48?PM Mark Roberts <markro at cs.washington.edu>
wrote:

> With the removal of ?components? to jdk/internal what is the best way to
> get the functionality of ClassPrinter?
>
>
>
> Thank you, Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250209/b1b2dbe8/attachment.htm>

From chen.l.liang at oracle.com  Thu Feb 27 19:03:15 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 27 Feb 2025 19:03:15 +0000
Subject: Testing whether constant pool entries match nominal descriptor objects
Message-ID: <SJ2PR10MB76698CCC255E397C5E2FBDE0A2FD2@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi all,
I observed that a frequent pattern in class file transformation is that we test if a call matches given descriptors, and we subsequently replace it with a new call. For example, we might want to redirect calls to MethodHandle.Lookup to a proxy class that performs run-time remapping of incoming class, method, or field names.

Currently, the best way to test for such call patterns is to examine their owner class, name, and type individually. For example, user would check:

owner.name().equalsString("java/lang/invoke/MethodHandles$Lookup")

Which has these problems:

  1.
Users might not be aware of this approach; they might do things like
owner.asInternalName().equals(...)
which will suffer from performance penalties due to the eager evaluation of internal names.
  2.
Users might get the internal name wrong, or confuse internal names with descriptors.

As a consequence, I propose addition of "equalsSymbol" method to these classes:
 - ClassEntry::equalsSymbol(ClassDesc)
 - MethodTypeEntry::equalsSymbol(MethodTypeDesc)
 - ModuleEntry::equalsSymbol(ModuleDesc)
 - PackageEntry::equalsSymbol(PackageDesc)
 - StringEntry::equalsString(String)
 - Utf8Entry::equalsSymbol(ClassDesc) // Might consider rename to "equalsTypeSymbol" to avoid confusion with ClassEntry?
 - Utf8Entry::equalsSymbol(MethodTypeDesc)

With the following purposes:

  1.
To help such usages of descriptor matching tests to be less error-prone
  2.
To allow faster comparison with reduced processing on many constant pool entries

Please don't hesitate to share your thoughts about this proposal, such as renaming suggestions or problems with these new APIs.

Regards,
Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250227/a6d3be5b/attachment.htm>

From chen.l.liang at oracle.com  Thu Feb 27 20:44:38 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 27 Feb 2025 20:44:38 +0000
Subject: Proposal: Start delivering CustomAttribute and UnknownAttribute in
 CodeModel traversal as CompoundModel
Message-ID: <SJ2PR10MB7669947A84EBE78392A55DC9A2CD2@SJ2PR10MB7669.namprd10.prod.outlook.com>

In the recent documentation cleanup for the ClassFile API, I noted there are a few inconsistencies in the handling of attributes on the Code attribute.

  1.
CustomAttribute or UnknownAttribute are not streamed; they can only be discovered via AttributedElement methods.
  2.
While most attributes with LABELS AttributeStability is not directly writable, StackMapTable is; yet it does not recompute the BCI offsets if they are no longer compatible.
  3.
Type annotations in Code are not streamed if debug elements are off; yet CodeBuilder accepts them if users provide them. Other debug elements like local vars are dropped on both sides.

Here are my proposals:

  1.
To make both CustomAttribute and UnknownAttribute CodeElement, and deliver them in traversals, like as if they are class, method, or field elements.
  2.
Inflate and recompute offsets if a bound StackMapTable is written to another code body (such as one with head injection)
  3.
Do nothing for type annotation inconsistency for now. This one is a bit hard to determine the best course of action.

What do you think of my proposals for #1 and #2? FYI I have a pull request open for the proposals at https://github.com/openjdk/jdk/pull/23521, feel free to review.

Also, I understand there is a demand for Labels in user attributes. That topic is a bit more complex, and I wish to address in another mail thread. (Feel free to start a thread about it, too!)

Regards,
Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250227/a0988c2e/attachment-0001.htm>

From brian.goetz at oracle.com  Thu Feb 27 20:52:17 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 27 Feb 2025 15:52:17 -0500
Subject: Proposal: Start delivering CustomAttribute and UnknownAttribute
 in CodeModel traversal as CompoundModel
In-Reply-To: <SJ2PR10MB7669947A84EBE78392A55DC9A2CD2@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <SJ2PR10MB7669947A84EBE78392A55DC9A2CD2@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <bea32d73-40d3-49e0-acf1-e90ee5f7f90b@oracle.com>

I think there really is nothing to be done about type annotation 
consistency, and the cost of trying to do so would be really high (both 
in effort and in runtime cost.)

On 2/27/2025 3:44 PM, Chen Liang wrote:
> In the recent documentation cleanup for the ClassFile API, I noted 
> there are a few inconsistencies in the handling of attributes on the 
> Code attribute.
>
> 1.
>     CustomAttribute or UnknownAttribute are not streamed; they can
>     only be discovered via AttributedElement methods.
> 2.
>     While most attributes with LABELS AttributeStability is not
>     directly writable, StackMapTable is; yet it does not recompute the
>     BCI offsets if they are no longer compatible.
> 3.
>     Type annotations in Code are not streamed if debug elements are
>     off; yet CodeBuilder accepts them if users provide them. Other
>     debug elements like local vars are dropped on both sides.
>
> Here are my proposals:
>
> 1.
>     To make both CustomAttribute and UnknownAttribute CodeElement, and
>     deliver them in traversals, like as if they are class, method, or
>     field elements.
> 2.
>     Inflate and recompute offsets if a bound StackMapTable is written
>     to another code body (such as one with head injection)
> 3.
>     Do nothing for type annotation inconsistency for now. This one is
>     a bit hard to determine the best course of action.
>
> What do you think of my proposals for #1 and #2? FYI I have a pull 
> request open for the proposals at 
> https://github.com/openjdk/jdk/pull/23521, feel free to review.
>
> Also, I understand there is a demand for Labels in user attributes. 
> That topic is a bit more complex, and I wish to address in another 
> mail thread. (Feel free to start a thread about it, too!)
>
> Regards,
> Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250227/785208eb/attachment.htm>

From chen.l.liang at oracle.com  Thu Feb 27 20:54:45 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 27 Feb 2025 20:54:45 +0000
Subject: Proposal: Start delivering CustomAttribute and UnknownAttribute
 in CodeModel traversal as CompoundModel
In-Reply-To: <bea32d73-40d3-49e0-acf1-e90ee5f7f90b@oracle.com>
References: <SJ2PR10MB7669947A84EBE78392A55DC9A2CD2@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <bea32d73-40d3-49e0-acf1-e90ee5f7f90b@oracle.com>
Message-ID: <SJ2PR10MB766925990963BD0E6A827550A2CD2@SJ2PR10MB7669.namprd10.prod.outlook.com>

Ah, for "consistency" I do not mean their structural consistency, but the consistency of the ClassFile.DebugElementsOption policy. For other debug like locals and CRT they are dropped both from reading and writing; type annotations are only dropped from reading, but not for writing.
________________________________
From: Brian Goetz <brian.goetz at oracle.com>
Sent: Thursday, February 27, 2025 2:52 PM
To: Chen Liang <chen.l.liang at oracle.com>; classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: Re: Proposal: Start delivering CustomAttribute and UnknownAttribute in CodeModel traversal as CompoundModel

I think there really is nothing to be done about type annotation consistency, and the cost of trying to do so would be really high (both in effort and in runtime cost.)

On 2/27/2025 3:44 PM, Chen Liang wrote:
In the recent documentation cleanup for the ClassFile API, I noted there are a few inconsistencies in the handling of attributes on the Code attribute.

  1.
CustomAttribute or UnknownAttribute are not streamed; they can only be discovered via AttributedElement methods.
  2.
While most attributes with LABELS AttributeStability is not directly writable, StackMapTable is; yet it does not recompute the BCI offsets if they are no longer compatible.
  3.
Type annotations in Code are not streamed if debug elements are off; yet CodeBuilder accepts them if users provide them. Other debug elements like local vars are dropped on both sides.

Here are my proposals:

  1.
To make both CustomAttribute and UnknownAttribute CodeElement, and deliver them in traversals, like as if they are class, method, or field elements.
  2.
Inflate and recompute offsets if a bound StackMapTable is written to another code body (such as one with head injection)
  3.
Do nothing for type annotation inconsistency for now. This one is a bit hard to determine the best course of action.

What do you think of my proposals for #1 and #2? FYI I have a pull request open for the proposals at https://github.com/openjdk/jdk/pull/23521, feel free to review.

Also, I understand there is a demand for Labels in user attributes. That topic is a bit more complex, and I wish to address in another mail thread. (Feel free to start a thread about it, too!)

Regards,
Chen Liang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250227/740f01d0/attachment-0001.htm>