Try a different strategy for Java versions

[gbrail]

Always build using Java 11, and rely on Gradle to make that happen. Support tests running on different versions via an environment variable.

This is an experiment to see what GitHub Actions does.

[p-bakker]

Not been able yet to try this out in my setup to might have a m moment over the weekend

[gbrail]

FWIW this works fine in the CI/CD pipeline, and it makes the overall CI/CD pipeline run about two minutes faster. (Out of nearly 45 minutes.) The main impact of this is that if you have multiple JVMs on your machine, Gradle will always pick Java 11 to build and test unless you ask for a different JVM for testing. The downside is that if you don't have Java 11, I believe that Gradle will not build.

…

On Fri, Sep 13, 2024 at 8:58 AM Paul Bakker ***@***.***> wrote: Not been able yet to try this out in my setup to might have a m moment over the weekend — Reply to this email directly, view it on GitHub <#1627 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I23YWP7N42VNBEN52MLZWMDTZAVCNFSM6AAAAABOELQCMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBZGI4DENBXGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[p-bakker]

Little later, but got around to it now.

The altered setup results in all projects being setup by Gradle to use Java 11 now in Eclipse, including the test project.

So the test project will compile with Java 11, but when runnign the tests, it'll run with another Java version if RHINO_TEST_JAVA_VERSION is set, but only if the tests are executed through Gradle.

Personally I setup (JUnit) Test Configurations in Eclipse manually and when I do that I specify the Java version to use anyway, so that works as well.

So I think this PR works as intended :-)

Only question I have left is whether the usage of java > toolchain requires anything else from devs checking out Rhino? For me it worked out of the box, but I've done some stuff with toolchains in the past, so maybe I've already got some stuff configured on my machine and therefor it worked straight away

[p-bakker]

Another Q: when running the Test262 Test Suite with the -DupdateTest262properties parameter, should it maybe also block if not running on Java 11, because if run with a newer Java version, it may mark tests as passing, while they wouldn't on Java 11, for example tests in the area of language/identfiiers/...

[gbrail]

OK -- this is an entirely different approach now, inspired by this article, which points out, among other things, that running Gradle and compiling on the latest JDK is a good idea:

https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/

The idea is this:

• Build and compile with whatever Java version the user has, whether it's from the path or from JAVA_HOME
• Set the "--release" flag on the compiler so that we build for the right bytecode version
• Use the RHINO_TEST_JAVA_VERSION to test with each JVM

To make this work, since "google-java-format" (used by Spotless) is still sensitive, I had to upgrade it to the latest version, which does not run on Java 11. And the new version requires that we reformat some stuff, so the yak is being shaved here.

So the upside of all this is the following:

• You can build Rhino with whatever Java you have
• However, to properly build and test it you need at least Java 17
• We will test with older Java versions to ensure compatibility before release

[gbrail]

The latest version will fail to run the tests if "updateTest262properties" is set and we're not testing on Java 11. Given that, I'd like to go ahead and merge this as letting people use Java 21-based build tools is a nice improvement.

[p-bakker]

Unfortunately haven't gotten around to testing it, but just looking at the changes it looks good to me!

[gbrail]

Merging this -- it means that we can now all build with newer Java versions but still should use Java 11 before updating test262 -- if that causes confusion we may have to address it in the test262 infrastructure.