8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version

[dougxc]

There are plans to have libgraal be built for JDK master using a version of Native Image running on a JDK one version behind the current JDK. This Native Image execution needs to be able to load the JVMCI classes. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of the current JDK.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version (Enhancement - P4)

Reviewers

• Magnus Ihse Bursie (@magicus - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25494/head:pull/25494
$ git checkout pull/25494

Update a local copy of the PR:
$ git checkout pull/25494
$ git pull https://git.openjdk.org/jdk.git pull/25494/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25494

View PR using the GUI difftool:
$ git pr show -t 25494

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25494.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back dnsimon! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@dougxc This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version

Reviewed-by: ihse

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 203 new commits pushed to the master branch:

• af87035: 8355746: Start of release updates for JDK 26
• c59e44a: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual
• 23f1d4f: 8337666: AArch64: SHA3 GPR intrinsic
• ... and 200 more: https://git.openjdk.org/jdk/compare/39714b603040f1619f5e0e2a13ea8a90bb993c27...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@dougxc The following label will be automatically applied to this pull request:

• build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (739c5fb5)
• 00: Full (fb1adbe4)

[magicus]

I don't think this is a good way. We should not call to shell to make calculations in the makefiles; if that were needed, it should be done in configure. However, we are already doing this, or at least something very similar. Have a look at line 398 in boot-jdk.m4. We set up OLDEST_BOOT_JDK as the oldest JDK from the list in version-numbers.conf.

That should, I think, match your expectation of N-1. There is always a bit uncertainty how you want these things to be handled around the version rollover, and I'm not sure about your use case in those situations. But in general, the oldest boot JDK will match the version number actually used in the build as the boot JDK, that is, N-1.

Now, OLDEST_BOOT_JDK is not exported to make. But that is however:

BOOT_JDK_SOURCETARGET="-source $OLDEST_BOOT_JDK -target $OLDEST_BOOT_JDK -Xlint:-options"

which is almost, but not exactly, what you were planning to add. The added -Xlint:-options is harmless afaict, and I think was likely added at some point due to option mismatch between N and N-1 javac lint support, so I think it would make sense for you to use it as well.

So, in essense, my suggestion boils down to that you should only add $(BOOT_JDK_SOURCETARGET) to your command line.

[dougxc]

Thanks for the suggestion - I've applied it. I assume OLDEST_BOOT_JDK will always be at least one behind the current version so this looks future proof and should any manual adjustment during version rollover.

[jddarcy]

I don't think this is a good way. We should not call to shell to make calculations in the makefiles; if that were needed, it should be done in configure. However, we are already doing this, or at least something very similar. Have a look at line 398 in boot-jdk.m4. We set up OLDEST_BOOT_JDK as the oldest JDK from the list in version-numbers.conf.

That should, I think, match your expectation of N-1. There is always a bit uncertainty how you want these things to be handled around the version rollover, and I'm not sure about your use case in those situations. But in general, the oldest boot JDK will match the version number actually used in the build as the boot JDK, that is, N-1.

Now, OLDEST_BOOT_JDK is not exported to make. But that is however:

BOOT_JDK_SOURCETARGET="-source $OLDEST_BOOT_JDK -target $OLDEST_BOOT_JDK -Xlint:-options"

which is almost, but not exactly, what you were planning to add. The added -Xlint:-options is harmless afaict, and I think was likely added at some point due to option mismatch between N and N-1 javac lint support, so I think it would make sense for you to use it as well.

So, in essense, my suggestion boils down to that you should only add $(BOOT_JDK_SOURCETARGET) to your command line.

I don't know the particulars here, but using

`javac -source $OLD -target $OLD ..."

is almost never more appropriate than using

`javac --release $OLD ..."

The options warning would be noting the possible use of --release.

[dougxc]

is almost never more appropriate than using

`javac --release $OLD ..."

The options warning would be noting the possible use of --release.

I wanted to use --release initially but it is not configurable in a module's Java.gmk. That is, TARGET_RELEASE is not supported in CompileJavaModules.gmk.

However, thinking this through a little more, we really do need something closer to --release for the use case behind this PR. I'll postpone working on this PR and try capture the requirements in more detail in JDK-8357979.