RFR: 8328111: Convert Runtime tests to use the ClassFile API instead of ASM [v14]
Oussama Louati
duke at openjdk.org
Tue Mar 19 11:52:26 UTC 2024
On Tue, 19 Mar 2024 11:37:36 GMT, Oussama Louati <duke at openjdk.org> wrote:
>> The main goal pull request migrate the existing tests to utilize the new ClassFile API instead of the ASM library. The use of ASM has served us well in the past, but maintaining it has its costs and limitations.
>>
>> ### **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.
>
> Oussama Louati has updated the pull request incrementally with one additional commit since the last revision:
>
> convert IntfMethod test to use the classfile API
test/hotspot/jtreg/runtime/ConstantPool/IntfMethod.java line 1:
> 1: /*
Test Description:
The test attempts to invoke methods that call methods from an interface and the class itself and expects an IncompatibleClassChangeError to be thrown. This error is thrown when an incompatible class change has occurred, such as changing a class into an interface
Test Outcome:
The test is considered successful if all four method invocations throw the expected IncompatibleClassChangeError. If any other outcome occurs, the test is considered unsuccessful. This test is crucial for ensuring the JVM's correct handling of method calls in interfaces and classes, which could potentially lead to bugs or crashes if not handled properly.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18271#discussion_r1530217827
More information about the hotspot-runtime-dev
mailing list