On Mon, 2 Dec 2024 23:55:00 GMT, Chen Liang <li...@openjdk.org> wrote:
> The java.lang.classfile.components package was underused and had almost no > usage feedback; as a result, it did not caught attention during the preview > process of the Class-File API, until the late adoption when Class-File API is > sure to become finalized. > > To compensate in such a short time to the stabilization of JDK 24, we propose > to temporarily move this package to jdk.internal instead. This allows us to > better consider the role of this package and its members. > > See > https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html > for initial problem discovery and > https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html > for revision proposal. `java.lang.classfile.components.ClassPrinter` received significant positive feedback in the recent years, it became an essential debugging and logging tool. `java.lang.classfile.components.ClassRemapper` has been designed based on user requests, it received positive feedback in the recent years and it is an essential component for class instrumentation. `java.lang.classfile.components.CodeLocalsShifter` and `java.lang.classfile.components.CodeRelabeler` are essential components for class instrumentation and other advanced transformations, they have been designed based on the feedback from JFR class instrumentation conversion from ASM to Class-File API. `java.lang.classfile.components.CodeStackTracker` has been designed as standalone component (out of the core Class-File API) for performance reasons. It has been strongly requested by users and it has been applied in a prototype of javac using Class-File API to generate classes. There is no real justification for this change and I suggest to close it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22503#issuecomment-2514149797
