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

Paul Sandoz paul.sandoz at oracle.com
Mon Dec 4 21:22:55 UTC 2017



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


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

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.



More information about the jdk-dev mailing list