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

Ryan Schmitt rschmitt at pobox.com
Mon Dec 4 01:53:40 UTC 2017


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

On Fri, Dec 1, 2017 at 3:32 PM, Paul Sandoz <paul.sandoz at oracle.com> 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