JDK-8190736 : 4.1: Identify supported version numbers
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-11-03
  • Updated: 2025-05-30
  • Resolved: 2017-11-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10Fixed
Related Reports
Relates :  
Description
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"
Comments
JEP 309 (JDK-8177279) introduces a table in 4.4 that, like 4.7, lists class file versions and Java SE versions. That could also be updated with this change.
21-11-2017

Some future-proofing here, compared to the old paragraph about JDK versions: - No dependency on the format of the version number, should some other pattern than 8, 9, 10, ... be adopted. - No dependency on the version number incrementing with each Java SE release The policy would be to update this part of the spec whenever a new version number is needed.
03-11-2017

Proposed new text for the description of "minor_version, major_version": ---- The values of the minor_version and major_version items are the minor and major version numbers of this class file. Together, a major and a minor version number determine the version of the class file format. If a class file has major version number M and minor version number m, we denote the version of its class file format as M.m. Thus, class file format versions may be ordered lexicographically, for example, 1.5 < 2.0 < 2.1. A Java Virtual Machine implementation can support a class file format of version v if and only if v lies in some contiguous range M ≤ v ≤ 53.0, where M ≥ 45.0, as chosen by the implementation. [non-normative] Support for new major version numbers was added by Java SE releases according to the following table: Version number Java SE version --------------- ---------------- 46 1.2 47 1.3 48 1.4 49 5.0 50 6 51 7 52 8 53 9 ---- 4.7 could also be updated to remove the Java SE columns from tables, maybe with a reference to 4.1.
03-11-2017