JDK-8200338 : 4.1: Restrict the legal values of ClassFile.minor_version
- Type: Bug
- Component: specification
- Sub-Component: vm
- Affected Version: 11
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2018-03-27
- Updated: 2019-05-29
- Resolved: 2018-12-14
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.
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 12 |
|---|
12Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
During a discussion of how preview features will be realized (http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000992.html), it was pointed out that 4.1's traditional "contiguous range" rule is deficient in two ways, both involving a non-zero minor_version: 1. It forces an SE 13 JVM (57.0) to accept 56.65535. This forced acceptance is bad because 56.65535 indicates a class file that depends on preview features of SE 12 and hence is unsupportable on SE 13. 2. It forces an SE 13 JVM (57.0) to reject 57.65535. This forced rejection is bad because 57.65535 indicates a class file that depends on preview features of SE 13 and hence is of great interest to this JVM (assuming --enable-preview is also given). minor_version had a legacy purpose in JDK 1.0 and 1.1, but JDK 1.2 made it redundant. Since 1.2, compilers have set it to zero, and HotSpot has required it to be zero in "new" class files. For example, HotSpot in JDK 1.2 accepted 46.0 but not 46.<non-zero>; HotSpot in JDK 8 accepted 52.0 but not 52.<non-zero>. Formally, for every Java SE Platform N since N=2, the RI has rejected a non-zero minor_version if the major_version is 44+N. (This implies that JDK 8 accepts, say, 51.<non-zero> class files from the JDK 7 era, but this is not a concern because JDK 7 itself did not produce or accept them, instead producing and accepting only 51.0.) In SE 12 and beyond, minor_version will again have purpose. Preview features use it to denote class files that are release-bound, and it will be a useful field for experimental features too. Accordingly, it is helpful to constrain the values of minor_version for each major_version, rather than allowing the wide ranges found in Table 4.1-A of JVMS10 (https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-4.html#jvms-4.1-200-B.2). A possible way to specify this is to enumerate legal versions as follows: (platforms before SE 9 omitted for brevity) 9 45.*, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0 10 45.*, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, 54.0 11 45.*, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, 54.0, 55.0 12 45.*, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, 54.0, 55.0, 56.0, 56.65535 13 45.*, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, 54.0, 55.0, 56.0, 57.0, 57.65535
Comments
|