More last minute changes for the ClassFile API

[Brian Goetz]

My main concern with the single-purpose components is that I think they are in the wrong place.  Co-locating them with the classfile API feels like it is promising more than we deliver, and users might feel they have to understand what they do.

I agree that the printing functionality is essential, and perhaps it doesn’t belong in components, especially if the rest off components is going away.



On Dec 2, 2024, at 2:51 AM, Adam Sotona <adam.sotona at oracle.com<mailto:adam.sotona at oracle.com>> wrote:

ClassRemapper, CodeLocalsShifter, CodeRelabeler and CodeStackTracker are single-purpose components standing on top of Class-File API and they have been carefully selected to support more complex use cases (like for example code instrumentation). I partly agree they may be turned into examples. However, the learning curve will be extremely steep for users forced to implement them first instead of just use them.

ClassPrinter is a different beast. This tool raised from serious needs and become significant complement to the API. It has been cleaned and simplified to its bare bones to avoid any confusion about its purpose. Maybe the components package location for ClassPrinter is not ideal however it works to differentiate it from the core API.

I have no objections to unify sub-int return types to int.

Thanks,
Adam


From: classfile-api-dev <classfile-api-dev-retn at openjdk.org<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Date: Monday, 2 December 2024 at 0:03
To: Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>>
Cc: classfile-api-dev <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: Re: More last minute changes for the ClassFile API
Hmm, for components package, I did a quick rundown in grep.app<http://grep.app/> search (previously used for terminally deprecating ZipError) and a search within JDK source:
1. A search on grep.app<http://grep.app/> shows there are no non-JDK usages of the components package; in contrast, all other classfile packages (attribute, instruction, constantpool) and the java.lang.constant package have usages beyond the JDK. A search on GitHub shows there is no actual usages of components package, yet ClassPrinter.ListNode is frequently used in imports due to the name similarity with a class offered by Leetcode.
2. A search within the JDK itself shows there is no use of these components, besides ClassPrinter in JFR, outside of ClassFile API and its tests.

I think the removal at this point is safe; even for the ClassPrinter, its huge amount of data exposed is very prone to unintended dependencies, which can turn it into a monolith that we cannot adjust at all later down the road.

Also for the 2 return types: Is it fine for us to promote the return types to `int` to promote consistency with the constant fields?

Chen

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