OpenJDK proposal would provide Java class file API

Java would get an API for processing Java class files, under a proposal afoot in the Java community.

The draft classfile API proposal calls for provision of an API for parsing, generating, and transforming Java class files. This classfile library initially would serve as an internal replacement for the ASM Java bytecode manipulation framework. Eventually, ASM would be removed entirely from the JDK.

The classfile API proposal notes that class file generation, parsing, and instrumentation are ubiquitous in the Java ecosystem, with many tools and libraries needing to process class files. Frameworks often perform on-the-fly bytecode instrumentation. The JDK, the proposal states, should provide an accurate, complete, up-to-date, performant API for reading, writing, and transforming Java class files.

Design goals and principles for the API include having all class file entities, such as methods and fields, represented by immutable objects. User-driven navigation also is a goal. Motivating the call for a Java classfile library are factors including:

• JDK consolidation, with the JDK itself significant in dealing with class files. And there is a delay inherent in the JDK’s use of ASM.
• Version skew between frameworks and running the JDK. Applications and frameworks processing class files usually bundle a classfile library such as ASM. But because new class file features can appear in any release of the JDK, applications and frameworks are more frequently encountering class files that are newer than the library they are bundled with, resulting in runtime errors or in frameworks trying to parse class file formats from the future. Developers want a classfile library that will be up-to-date with running the JDK.
• The JVM and class file format now are evolving faster than before. While some evolutions are simple, others are more complex, such as Project Valhalla bringing forth new bytecodes, field descriptors, and verification rules.
• The language has improved substantially since ASM was written.

Plans call for initially replacing ASM as a runtime dependency of the JDK without unacceptable loss of performance. Another goal would be to replace the internal classreader library used by the compiler and JDK tools. Eventually, a range of frameworks and applications should be able to use the library as an alternative to ASM, cglib, and other bytecode libraries.