More last minute changes for the ClassFile API

[Mark Roberts]

I have found the ClassPrinter to be a useful debugging tool.



Mark



*From:* classfile-api-dev <classfile-api-dev-retn at openjdk.org> *On Behalf
Of *Chen Liang
*Sent:* Sunday, December 1, 2024 3:03 PM
*To:* Brian Goetz <brian.goetz at oracle.com>
*Cc:* classfile-api-dev <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 search
(previously used for terminally deprecating ZipError) and a search within
JDK source:

1. A search on 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



On Sun, Dec 1, 2024 at 10:24 AM Brian Goetz <brian.goetz at oracle.com> wrote:

I have always been uncomfortable with the components package.  But it is
also pretty late in the cycle.

> On Dec 1, 2024, at 9:40 AM, Chen Liang <liangchenblue at gmail.com> wrote:
>
> 
> Hello,
> In the week before RDP 1, I think there are still a few enhancements that
require removal of existing APIs:
> 1. The components package.  The utilities in this package are often
inconsistent; for example, class name remapper does not remap simple names
in InnerClasses; the locals shifter shifts an arbitrary number of slots.
These inconsistent behaviors will have to be kept even if they make no
sense in the long run, because people might have dependencies on these
behaviors.  I think we should move these components to example snippets for
users, much like the System exit detection example in JEP 486.
> 2. The return types of PoolEntry::tag and AnnotationValue::tag.  They
currently return byte and char respectively while their constants are of
int type.  In addition, the byte tag can overflow if the constant pool tags
exceed 127, and by then the default Java widening conversion would be
erroneous for the constant pool tags.
>
> What do you think?
> Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20241201/e0bdd489/attachment-0001.htm>