More last minute changes for the ClassFile API

[Chen Liang]

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/f9491130/attachment.htm>