-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
-
Cause Known
JDK contains multiple libraries for parsing, generating, and transforming class files. Classfile API project goal is to provide JDK-based, accurate, complete, up-to-date, performant API for reading, writing and transforming Java class files.
Cost of Maintaining ASM Library:
- Risk of Changes: The ASM library is an external dependency, and updates or changes in its APIs can introduce unforeseen issues or require significant code modifications in our tests.
- Lack of Reviewers: As the ASM library evolves, finding reviewers familiar with its intricacies becomes challenging, leading to delays in reviewing and merging changes.
Reasons for Migration:
- Stability and Consistency: Utilizing the ClassFile API ensures stability and compatibility with the Java platform, reducing the risk of compatibility issues due to external library changes.
- Sustainability: The ClassFile API is a standard part of Java, making it easier to find reviewers and maintain code consistency across test suites.
Future Compatibility: As Java evolves, relying on native Java APIs like the ClassFile API ensures future compatibility and reduces technical debt.
Concerns Addressed:
- Risk of Changes: By migrating to a standard Java API, we mitigate the risks associated with external library changes and ensure smoother maintenance and updates in the future.
- Backporting and Compatibility: The use of native Java APIs allows for easier backporting of test fixes and ensures compatibility across Java versions, including preview releases.
This is an umbrella issue to collect and monitor JDK use cases; each under individual sub-task.
Cost of Maintaining ASM Library:
- Risk of Changes: The ASM library is an external dependency, and updates or changes in its APIs can introduce unforeseen issues or require significant code modifications in our tests.
- Lack of Reviewers: As the ASM library evolves, finding reviewers familiar with its intricacies becomes challenging, leading to delays in reviewing and merging changes.
Reasons for Migration:
- Stability and Consistency: Utilizing the ClassFile API ensures stability and compatibility with the Java platform, reducing the risk of compatibility issues due to external library changes.
- Sustainability: The ClassFile API is a standard part of Java, making it easier to find reviewers and maintain code consistency across test suites.
Future Compatibility: As Java evolves, relying on native Java APIs like the ClassFile API ensures future compatibility and reduces technical debt.
Concerns Addressed:
- Risk of Changes: By migrating to a standard Java API, we mitigate the risks associated with external library changes and ensure smoother maintenance and updates in the future.
- Backporting and Compatibility: The use of native Java APIs allows for easier backporting of test fixes and ensures compatibility across Java versions, including preview releases.
This is an umbrella issue to collect and monitor JDK use cases; each under individual sub-task.
- is blocked by
-
JDK-8294982 Implementation of Classfile API
- Resolved
- relates to
-
JDK-8280389 JEP 457: Class-File API (Preview)
- Closed
1.
|
Convert jdk.compiler javac to use the Classfile API for reading and writing classes | Open | Unassigned | ||
2.
|
test/hotspot 183 test classes use ASM | In Progress | Unassigned | ||
3.
|
Convert Indify tool to Classfile API | In Progress | Oussama Louati | ||
4.
|
Migrate CreateSymbols tool in make/langtools to Classfile API | Open | Qing Xiao (Inactive) | ||
5.
|
Convert Runtime tests to use the ClassFile API instead of ASM | In Progress | Chen Liang | ||
6.
|
Convert vm.runtime.defmeth related tests to use the ClassFile API | In Progress | Chen Liang |