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

[David Holmes]

On 5/12/2017 7:22 AM, Paul Sandoz wrote:
>> On 3 Dec 2017, at 13:13, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Paul,
>>
>> Don't you also need to update:
>>
>> jdk/src/java.base/share/native/include/classfile_constants.h
>>
>> #define JVM_CLASSFILE_MAJOR_VERSION 53
>>
> 
> I cannot find any usages for this constant, nor JVM_CLASSFILE_MINOR_VERSION. I will remove them.

Okay. I don't know the history or use of this file, other than it gets 
included into jvm.h to export the jvm interface to the jdk.

>>> The only relevant test i could find was the specific test added to HS for the 53 change:
>>>   test/hotspot/jtreg/runtime/classFileParserBug/Class53.jasm
>>> but how valuable is such a test? I did not think it terribly useful so i did not add one for 54.
>>
>> It is the validation test for the change made in
>>
>> hotspot/src/share/vm/classfile/classFileParser.cpp
>>
>> It's a sanity check to ensure we can actually read the new classfile version and haven't made a silly mistake somewhere. Here's one I prepared earlier for the nestmates work in the Valhalla project: :)
>>
> 
> Rethinking this... the value of such a test is not for the current version, since javac will be producing 54 versioned class files as part of the build well before this test is run by our infrastructure. It is of value when we increase the version and ensure HotSpot does not barf with prior versions.

Not quite. On the day we edit classFileParser.cpp to increase the 
version number, and we add this jasm test, we immediately test that the 
VM doesn't barf on the new classfile version. This generally 
(previously?) happens well in advance of javac being changed to generate 
new version class files. But yes once that happens the test is somewhat 
less useful - but does later serve as a sanity check that we didn't 
break older version classfile support.

Thanks,
David

> I will include that Class54 test. Thanks!
> 
> Paul.
> 
>> http://cr.openjdk.java.net/~dholmes/8187302/webrev/hotspot/test/runtime/classFileParserBug/Class54.jasm.html
>>
>> Cheers,
>> David
>>
>> On 2/12/2017 9:32 AM, Paul Sandoz wrote:
>>> Hi,
>>> This is an initial review request to increment the class file version of 10 from 53 to 54.
>>>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>>> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>>> 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). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>>> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back” in light of the new release process and deal with that separately from any version change.
>>> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>>> Thanks,
>>> Paul.
>