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

Integration blocker

 ⚠️ Title mismatch between PR and JBS for issue JDK-8357979

Issue

• JDK-8357979: Compile jdk.internal.vm.ci targeting the Boot JDK version (Enhancement - P4) ⚠️ Title mismatch between PR and JBS.

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 is no longer ready for integration - check the PR body for details.

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

[bridgekeeper]

@dougxc This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[magicus]

@jddarcy I tried replacing the -source/-target with --release for the Boot JDK overall. However, I get this kind of errors:

error: exporting a package from system module java.base is not allowed with --release

I assume this is why we have still been using -source/-target. But maybe we should move to use --release instead, and figure out and fix this issue in a different way?

[magicus]

For another compilation, I got:

error: option --system cannot be used together with --release

I guess that even if the rule "-source/-target is almost never more appropriate than --release" applies to Java developers at large, building the JDK might be that small corner case where the "almost" actually applies.