JEP 12: JVM version constraints

[John Rose]

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?

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