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

[Paul Hohensee]

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. 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> 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> 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
>