OpenJDK proposal would supply Java class file API

Java would get an API for processing Java class information, beneath a proposal afoot within the Java neighborhood.

The draft classfile API proposal requires provision of an API for parsing, producing, and remodeling Java class information. This classfile library initially would function an inside substitute for the ASM Java bytecode manipulation framework. Ultimately, ASM can be eliminated completely from the JDK.

The classfile API proposal notes that class file era, parsing, and instrumentation are ubiquitous within the Java ecosystem, with many instruments and libraries needing to course of class information. Frameworks usually carry out on-the-fly bytecode instrumentation. The JDK, the proposal states, ought to present an correct, full, up-to-date, performant API for studying, writing, and remodeling Java class information.

Design targets and ideas for the API embrace having all class file entities, comparable to strategies and fields, represented by immutable objects. Consumer-driven navigation is also a aim. Motivating the decision for a Java classfile library are elements together with:

• JDK consolidation, with the JDK itself vital in coping with class information. And there’s a delay inherent within the JDK’s use of ASM.
• Model skew between frameworks and operating the JDK. Purposes and frameworks processing class information often bundle a classfile library comparable to ASM. However as a result of new class file options can seem in any launch of the JDK, functions and frameworks are extra regularly encountering class information which can be newer than the library they’re bundled with, leading to runtime errors or in frameworks making an attempt to parse class file codecs from the long run. Builders need a classfile library that shall be up-to-date with operating the JDK.
• The JVM and sophistication file format now are evolving quicker than earlier than. Whereas some evolutions are easy, others are extra complicated, comparable to Venture Valhalla bringing forth new bytecodes, subject descriptors, and verification guidelines.
• The language has improved considerably since ASM was written.

Plans name for initially changing ASM as a runtime dependency of the JDK with out unacceptable lack of efficiency. One other aim can be to switch the inner classreader library utilized by the compiler and JDK instruments. Ultimately, a variety of frameworks and functions ought to have the ability to use the library as a substitute for ASM, cglib, and different bytecode libraries.