Gradle and Java versions (and Eclipse?)

[p-bakker]

Hi,

My setup to fiddle around with Rhino is using Eclipse and I'm using the Eclipse Gradle plugin to let Gradle setup everything accordingly.

However, Gradle consistently seems to setup each project to use JavaSE-18, while I think Rhino is to run against Java 11, no?

Not being a Gradle expert, I turned to the internet and there the suggestions seem to be to add something like:

plugins {
    id 'java'
}

java {
    sourceCompatibility = JavaVersion.VERSION_17  // Set to your desired version
    targetCompatibility = JavaVersion.VERSION_17  // Set to your desired version
}

So the question: is this something we ought to be adding or am I doing something wrong somewhere or?!?

@gbrail: tagging you, as you seem to be the Gradle guru here :-)

[gbrail]

We currently test with Java 11, 17, and 21 and intend for Rhino to work on all of them, so 18 should be OK too ;-) We do currently require Java 11 to actually build and run the CI tests because that's the lowest version right now. Gradle shouldn't be picking a Java version for you -- it should pick up whatever is in your environment -- that's what it does for me -- and it seems like you can almost always override that by setting JAVA_HOME before running it.

…

On Wed, Sep 11, 2024 at 8:54 AM Paul Bakker ***@***.***> wrote: Hi, My setup to fiddle around with Rhino is using Eclipse and I'm using the Eclipse Gradle plugin to let Gradle setup everything accordingly. However, Gradle consistently seems to setup each project to use JavaSE-18, while I think Rhino is to run against Java 11, no? Not being a Gradle expert, I turned to the internet and there the suggestions seem to be to add something like: plugins { id 'java' } java { sourceCompatibility = JavaVersion.VERSION_17 // Set to your desired version targetCompatibility = JavaVersion.VERSION_17 // Set to your desired version } So the question: is this something we ought to be adding or am I doing something wrong somewhere or?!? @gbrail <https://github.com/gbrail>: tagging you, as you seem to be the Gradle guru here :-) — Reply to this email directly, view it on GitHub <#1621>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I24MC6DU75VGZBZTZL3ZWBRUTAVCNFSM6AAAAABOBJBHRWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGE3DSNBTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[p-bakker]

My 'environnement' is used for more than just Rhino and other projects have other requirements.

I thought, with Rhino targeting Java 11, Gradle ought to be configured to use just Java 11, so when Gradle configures things, Java 11 will be used.

And Java 17 and 21 only come into play in the CI pipeline when running tests. Which also makes me wonder: should the CI pipeline not just check the source and build Rhino once, using Java 11 and then store artifacts and then use those artifacts in the actions that test Rhino on Java 17 and 21? To my knowledge the Java 17/21 runs redo stuff already done in the Java 11 run

But maybe my thinking is all wrong 😛

[p-bakker]

Did try and do the following:

• in rhino.library-conventions.gradle I added:

java {
    sourceCompatibility = JavaVersion.VERSION_11
    targetCompatibility = JavaVersion.VERSION_11
}

When I now run Refresh Gradle Project, Gradle correctly sets up all the projects (except tests and benchmarks) to use Java 11, which is I think what ought to happen, as our Rhino builds are targeting Java 11

The test and benchmarks projects are setup with whatever is the default Java version of my environment, which, when run in the CI pipelines is how it should be, so we can also test against Java 17, 21 or whichever version we'd like.

Adding this may break the current GitHub build pipeline, which uses matrix of Java versions and does a full build with each Java version, but I could argue that setup is not correct and/or less optimized. Shouldn't it run the code formatting checks once and then built the jars once and then use those same jars to run the tests on the different Java versions?

It would solve the Gradle setup problem (that at least I have :-) ), reduce the load a bit on CI and would in the process expose the jars as artifacts on the workflow

[tonygermano]

This change makes sense to me. If that's what directs Eclipse to download and build with java 11, great. I think in other environments it just sets javac options, even if you are building with a higher versioned JDK.

[gbrail]

I couldn't figure that out before but I'm willing to experiment and I'm always happy for someone else to fix this too ;-) It looks like we can use the Toolchains feature of Gradle to ensure that we always build with Java 11 but use a different JVM for the tests: Toolchains for JVM projects (gradle.org) <https://docs.gradle.org/current/userguide/toolchains.html> I think that it'd still be 10x easier to keep having the GitHub action run multiple times, and don't think that trying to optimize compiling and format-checking is likely to be a big time savings in the GitHub actions versus running the tests, and because it still seems to be trying to undo a bunch of stuff that Gradle is trying to do. But having Gradle download and run the right JVM (which is easy to set up) and having it try and use different JVMs for the different phases does make sense to me and let's try it.

…

On Thu, Sep 12, 2024 at 11:21 AM Paul Bakker ***@***.***> wrote: Did try and do the following: - in rhino.library-conventions.gradle I added: java { sourceCompatibility = JavaVersion.VERSION_11 targetCompatibility = JavaVersion.VERSION_11 } When I now run Refresh Gradle Project, Gradle correctly sets up all the projects (except tests and benchmarks) to use Java 11, which is I think what ought to happen, as our Rhino builds are targeting Java 11 The test and benchmarks projects are setup with whatever is the default Java version of my environment, which, when run in the CI pipelines is how it should be, so we can also test against Java 17, 21 or whichever version we'd like. Adding this may break the current GitHub build pipeline, which uses matrix of Java versions and does a full build with each Java version, but I could argue that setup is not correct and/or less optimized. Shouldn't it run the code formatting checks once and then built the jars once and then use those same jars to run the tests on the different Java versions? It would solve the Gradle setup problem (that at least I have :-) ), reduce the load a bit on CI and would in the process expose the jars as artifacts on the workflow — Reply to this email directly, view it on GitHub <#1621 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I2YU75TX756VYWSONXLZWHLSNAVCNFSM6AAAAABOBJBHRWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRSHE2DMOI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gbrail]

For those of you following along, I'm going to merge #1627, which changes the strategy in a way that I THINK will be easier for many of you:

• You can build Java with whatever version you have, as long as it's at least Java 11
• We'll use the "--release" flag in the compiler so that the code is only compatible with Java 11
• You will need to use Java 17 or higher to run Spotless.
• You can set the environment variable RHINO_TEST_JAVA_VERSION to have the tests run on a different version
• You'll need to test with this set to "11" if you want to update the test262.properties file automatically