OpenJDK proposal would provide a Java class file API
Java would get an API to process Java class files, as part of an ongoing proposal in the Java community.
The draft class file API proposal calls for providing an API for parsing, generating, and transforming Java class files. This class file library would initially serve as an internal replacement for the Java ASM bytecode manipulation framework. Eventually, ASM would be completely removed 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 deal with class files. Frameworks often perform on-the-fly bytecode instrumentation. The JDK, according to the proposal, should provide an accurate, comprehensive, up-to-date, and high-performance API for reading, writing, and transforming Java class files.
The design goals and principles of the API include that all class file entities, such as methods and fields, be represented by immutable objects. User-driven navigation is also a goal. The motivation for calling a Java class file library are factors such as:
- Consolidation of the JDK, with the JDK itself important in dealing with class files. And there is an inherent lag in the JDK’s use of ASM.
- Version bias between frameworks and JDK runtime. Applications and frameworks dealing with class files usually bundle a class file library such as ASM. But since new class file features can appear in any version of the JDK, applications and frameworks more frequently encounter class files that are newer than the library they come with, leading to errors in runtime or frameworks trying to parse class file formats from the future. Developers want a class file library that will be up to date with running the JDK.
- The JVM and class file format now scale faster than before. While some evolutions are simple, others are more complex, like the Valhalla project bringing new bytecodes, field descriptors and verification rules.
- The language has improved considerably since ASM was written.
Plans are to initially replace ASM as a runtime dependency of the JDK with no unacceptable performance loss. Another goal would be to replace the internal class reader library used by the JDK compiler and 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.
Copyright © 2022 IDG Communications, Inc.