-
Bug
-
Resolution: Fixed
-
P4
-
9
-
None
JVMS 4.1 has this to say about version numbers:
"A Java Virtual Machine implementation can support a class file format of version v if and only if v lies in some contiguous range Mi.0 ≤ v ≤ Mj.m. The release level of the Java SE platform to which a Java Virtual Machine implementation conforms is responsible for determining the range."
This is followed by a non-normative description of the version numbers supported by "Oracle's Java Virtual Machine implementation".
Problems:
- It's not clear what "the release level of the Java SE platform" refers to, but there appear to be no additional documents describing ranges of supported versions.
- In the absence of any other constraints, there's no requirement that a JVM implementation support all the features in the latest class file version described in JVMS. They can just choose a different Mj.
- It's not obvious that a JVM implementation is not allowed to choose Mj=0xFFFF and then never throw UnsupportedClassVersionError
- It is useful to know that Java SE 9 supports version numbers up to 53.0, but it's hard for readers to find that information anywhere.
- 4.7 includes some (class file, Java SE) version pairs, but not all, and it clutters up those tables
- The non-normative description of Oracle's JVM refers to the outdated version number format "1.k"
"A Java Virtual Machine implementation can support a class file format of version v if and only if v lies in some contiguous range Mi.0 ≤ v ≤ Mj.m. The release level of the Java SE platform to which a Java Virtual Machine implementation conforms is responsible for determining the range."
This is followed by a non-normative description of the version numbers supported by "Oracle's Java Virtual Machine implementation".
Problems:
- It's not clear what "the release level of the Java SE platform" refers to, but there appear to be no additional documents describing ranges of supported versions.
- In the absence of any other constraints, there's no requirement that a JVM implementation support all the features in the latest class file version described in JVMS. They can just choose a different Mj.
- It's not obvious that a JVM implementation is not allowed to choose Mj=0xFFFF and then never throw UnsupportedClassVersionError
- It is useful to know that Java SE 9 supports version numbers up to 53.0, but it's hard for readers to find that information anywhere.
- 4.7 includes some (class file, Java SE) version pairs, but not all, and it clutters up those tables
- The non-normative description of Oracle's JVM refers to the outdated version number format "1.k"