OpenJDK proposal will provide Java class file API

The Java community is working on a Classfile API proposal that aims to provide an API for parsing, generating, and converting Java class files; initially as an internal replacement for the ASM in the JDK, and later as a public API. It is planned that ASM will eventually be removed from the JDK entirely.

The proposal notes that class file generation, parsing, and detection are ubiquitous in the Java ecosystem; many tools and libraries need to be able to handle class files, and frameworks often perform on-the-fly bytecode instrumentation, transformation, and generation. The JDK should provide an accurate, complete, up-to-date, high-performance API for reading, writing, and converting Java class files.

The initial goal of this API is to replace the ASM as a runtime dependency of the JDK without unacceptable performance loss. As an extension, it is also desirable to further replace the internal “classreader” library used by the compiler and JDK tools. Ultimately, the expectation is that a large number of applications and frameworks will be able to use this library as an effective replacement for ASM, cglib, or other bytecode libraries. Design goals and principles include having all Class file entities (e.g., methods and fields) represented by immutable objects, user-driven navigation, etc.

classfile-api.png

The motivation for its genesis is.

  • JDK integration. The JDK itself is important in handling class files. there is an inherent delay in the JDK using ASM, and JDK developers need a bytecode library that keeps pace with JVMS.
  • Version deviations between the framework and the running JDK. Applications and frameworks that handle class files usually bundle a class file library, such as ASM, cglib, etc. But because new class file features can appear in any JDK version, and because the JDK has been released much faster since Java 9, applications and frameworks more frequently encounter newer class files than the libraries they bundle, leading to runtime errors (or worse, frameworks trying to parse the class file format). Developers need a class file library that keeps pace with the running JDK.
  • JVM evolution. Compared to the early days of Java, the JVM and class file formats are evolving much faster now. While some evolutions are simple, others are more complex, such as Project Valhalla brings new bytecode, field descriptors, and validation rules. At some point, improving existing libraries to support these new features may be costly or complex.
  • **Language Improvements.**The language has improved significantly since the ASM was written, meaning that what may have been the best API idiomatic usage in 2002 may not be ideal 20 years from now.

For more details see the proposal.