JEP 12: JVM version constraints

[Remi Forax]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Mardi 20 Mars 2018 17:48:44
> Objet: Re: JEP 12: JVM version constraints

> On Mar 5, 2018, at 2:57 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>> 
>> JEP 12, in describing the treatment of "preview" class files, requires that:
>> 
>>> A JVM implementation for Java SE $N must not define a class file that depends on
>>> the preview VM features of another platform version
>> 
>> In other words, where SE 11 class files have major version 55, an SE 12 JVM must
>> reject class files with version 55.65535.
>> 
>> This is a change in JVM behavior—currently the spec says:
>> 
>> "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."
>> (JVMS 4.1)
>> 
>> Note the word "contiguous".
>> 
>> Where is this change being tracked? Since it's not, itself, part of a preview
>> feature, it could easily be overlooked.
>> 
>> My two cents: we can carve out a really narrow range of prohibited version
>> numbers (55.65535, 56.65535, ...). But I'd rather make a breaking change:
>> enumerate all the actually-used version numbers since 1.0 (something like 45.*,
>> 46.0, 47.0, ..., 55.0), and reject the rest.
> 
> Has anybody seen a non-zero minor version in the wild, since 1.2?
> I'm going to guess the answer is "no".
> 
> I would prefer Dan's breaking change also, because the existing state of the
> spec.
> is too vague for anyone to get benefit from minor version numbers, and in its
> present state the minor version is useless.
> 
> The term "contiguous" can only mean, probably, that all minor versions are fair
> game, but it is vague enough that it would be reckless to actually use minor
> versions to carry more information than the the actual Java SE versions,
> as produced by the Java SE reference implementation (the "RI", which is
> the OpenJDK JDK artifact).
> 
> Has anybody seen any minor versions "in the wild" which differ from those
> produced by the reference implementation?  ASM folks, Eclipse folks, have
> you seem any non-RI minor versions?  What clever uses are out there?

No never seen a minor version different from 0 apart classes generated before Java 1.2,
most of the code that does a version check does a == on the version (major + minor), so the most of the code doesn't implement the JLS correctly but follow what the VM does.

> 
> I think there are no clever uses; maybe a few misguided or exploratory ones.
> The fact that the Hotspot JVM rejects non-RI minor versions *in the current
> release* is strong evidence that the road is clear to reject them in the spec.
> also, even for the current release.
> 
> ("In the current release" means that every new major SE version N since N=2
> rejects a non-zero minor version if the classfile major version is 44+N.
> If the major version is less, then non-zero minor versions could potentially
> creep in.  That's the effect of the word "contiguous", but I don't think it
> actually happens.)
> 
> If I'm right, there is no downside to Dan's proposal to recognize that the
> RI version scheme is the de facto standard, adjust the spec., and reject
> non-RI minor versions.
> 
> The benefit of this is we could begin using the minor versions to actually
> restrict the usage of classfiles in useful ways, such as marking them as
> previews or experiments.
> 
> At present, we can't touch minor versions because the spec. seems to
> allow anybody to generate a non-RI minor version at any moment for
> any reason.  But (uselessly) it allows random minor versions only in
> classfiles where the major version is not the current latest one.
> 
> If someone says, "yes, there's a current use for non-zero minor versions",
> we could in principle reserve some segment of minor versions for this
> valid use.  But Dan's proposal, to forbid non-zero values, is simpler.
> It's safer too, because the restriction can be walked back.  In fact, we
> should do it now, and walk it back later, but only if somebody shows up
> with a valid use of non-zero minor versions.
> 
> — John