Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8200338

4.1: Restrict the legal values of ClassFile.minor_version

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 11
    • Fix Version/s: 12
    • Component/s: specification
    • Labels:
    • Subcomponent:
      vm

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                abuckley Alex Buckley
                Reporter:
                abuckley Alex Buckley
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: