On Fri, 31 Jul 2026 06:21:27 GMT, David Holmes <[email protected]> wrote:
>> Please review this simple change to give a more informative error message >> for `UnsupportedClassVersionError` when trying to load a recent classfile on >> an older VM. The wording used has already been finalized - see JBS. >> >> Testing: >> >> - Updated test runtime/ClassFile/UnsupportedClassFileVersion.java. >> - Added a new test case to >> `test/hotspot/jtreg/runtime/ClassFile/PreviewVersion.java` to show preview >> classfiles are also handled as expected >> >> Tier 1 sanity testing. >> >> Thanks >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > David Holmes has updated the pull request incrementally with one additional > commit since the last revision: > > Update existing UnsupportedClassFileVersion test with new message. > Restore Versions.java as no change needed. Thanks for doing these changes, they make sense and it seems like it's very helpful for an end-user trying to get a Java program running. src/hotspot/share/classfile/classFileParser.cpp line 162: > 160: #define JAVA_28_VERSION 72 > 161: > 162: #define JDK_VERSION (7 + > (JVM_CLASSFILE_MAJOR_VERSION - JAVA_7_VERSION)) I feel a bit uneasy about having classfile arithmetic here, and then never validating the output in the unit tests as we use wildcards. I would prefer to use `JDK_Version` for the error message, or to sanity test that the output in the error message is in fact the version we expect. ------------- PR Review: https://git.openjdk.org/jdk/pull/32117#pullrequestreview-4827539217 PR Review Comment: https://git.openjdk.org/jdk/pull/32117#discussion_r3689666937
