[10] RFR 8191510: Bump classfile version number to 54

Paul Sandoz paul.sandoz at oracle.com
Mon Dec 4 23:21:54 UTC 2017

> On 4 Dec 2017, at 14:00, Paul Hohensee <paul.hohensee at gmail.com <mailto:paul.hohensee at gmail.com>> wrote:
> Just to nail this down (i.e., correct me if I'm wrong), this means there are two version numbers that change in lock step, namely the JDK major version for the language and libraries and the class file version (effectively the JVMS major version) for JVMs.


Note that there are other changes that are not included in this patch. You may have noticed that javac was already updated to support 1.10/10 (aliased to map to class file version 53) and symbol files were already present to support the —release flag.

For the next version bump it’s not clear to me yet how far we can go in one patch, updating all of javac too, that would be nice, but it might be preferable to separate some aspects out such as symbol file generation, which may require more time to complete. I hope we can finesse and optimize this process over the next couple iterations.


> A JVM executes class files, not Java per se, so it guess it makes sense for the JVMS to have its own version number.
> On Mon, Dec 4, 2017 at 12:59 PM, joe darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>> wrote:
> On 12/3/2017 11:20 PM, Remi Forax wrote:
> On December 4, 2017 2:53:40 AM GMT+01:00, Ryan Schmitt <rschmitt at pobox.com <mailto:rschmitt at pobox.com>> wrote:
> The intent is that the class file version will increment with every
> major
> release (regardless of if there are no features that mandate a class
> file
> change).
> What is the motivation for doing so?
> Having a simple bijection between the Java version and the class file version.
> This is not something new, the version 50 (I let you find the corresponding Java version :) ) has no new bytecode related feature by example.
> The policy of bumping the class file version with each major release provide a mechanism for applications and libraries to implicitly encode the minimum JDK version whose feature are needed to run the code in question.
> -Joe

More information about the jdk-dev mailing list