Java evolves fast: changes and enhancements are introduced continuously with new releases coming out every six months. But some technologies cannot keep up with the language progression.
The new JEP draft: Classfile API is aimed at closing the growing gap between the JVM and the ASM library for working with Java classes. The goal is to replace ASM with an internal library providing a performant and up-to-date API for class file operations.
Motivation behind the new feature
Although there are a lot of libraries processing bytecode, Java will benefit from its own API for several reasons:
- A classfile library is usually bundled with an application or a framework. Newer JDK versions may contain class files unknown to the library bundled with an application resulting in runtime errors. It is easier to keep a library belonging to the JDK up-to-date with the JVM specification and JDK versions.
- New features and projects integrated into Java are associated with complex changes of the JVM, and existing libraries cannot mature so rapidly to support all the new features.
- It would be better to avoid integrating ASM into the JDK because it contains a lot of legacy code and its architecture doesn’t fit the principles of modern programming. A completely new library will be designed according to the modern software requirements.
The design of the new API will be based on the following principles:
- All class file entities will be represented as immutable objects
- The library shall take the tree structure of class files into consideration
- The navigation through class file tree should be user-driven, i.e., the library will parse only elements necessary to the user
- Both streaming and materialized views of the class file should be supported
- The library should generate the class entities derived from other class file elements based on the methods added to the file
- Instead of the obsolete Visitor approach, the API will be based on the modern and less verbose Java features such as lambdas, records, and pattern matching
- There are three key abstractions in the API design: element, builder, and transform. The element is an immutable description of class file elements. The builder has building methods and acts as a Consumer of a specific element type. The transform is a function for element transformation.
JEP developers have no intention of substituting all existing bytecode libraries. Rather, the new API will be an additional modern tool for writing, parsing, and transforming class files in Java reliably.
There is currently a draft of the API at the JEP’s page. The new library will have a large surface area, so multiple quality, performance, and conformance tests will be performed to avoid negative impacts on Java applications.