Update CI for Java 23

[niloc132]

No description provided.

[niloc132]

For this to pass, we need a newer errorprone build - minimum of 2.28.0. If we go as high as 2.32.0, support for running on Java 11 is dropped. This means that while there is a window we currently can fit through, when Java 24 is released we'll have the following choices:

• Stop using ErrorProne
• Drop builds on Java 11 (can still test on Java 11, using something like Gradle's toolchains)
• Don't build on Java 24 (as above, can still test on Java 24, using something like Gradle's toolchains)

[tbroyer]

If what you want is to test the runtime compatibility of GWT with different JDKs (to make sure users will be able to use GWT with those JDKs), then there's no need to build GWT with several JDKs: build it once, then test with whatever you want to test against. That way, you can chose to use JDK 21 as the baseline, with the appropriate --release flag, and thus pick an ErrorProne version that matches that choice (and later on when updating to JDK 25, then update ErrorProne).

Actually building (and this includes "running Ant", as there could be JDK compatibility issues as well) with multiple JDKs is only needed if what you want to check is that contributors will indeed be able to use of those JDKs, rather than mandating a specific version.

[niloc132]

Right, and with Gradle/Maven that's decently straightforward, but a little less so with Ant as far as I'm aware (especially given all of the customization we have in place now). I'm more inclined to put the effort into outright switching to a better build system than Ant (which effectively requires modularizing dev/ into separate classpaths), as that will pay off in other ways too.

It is also worth noting that historically we have had users who want to build GWT itself on particular JDKs. That can't really be an explicit goal of the project, but would be nice to remain as flexible as we can.

I have a long-running branch that tries to modularize (with the intention of moving from ant to maven or gradle), along with many other cleanups, and it builds and can compile most samples, but no tests are run yet and there's yet no way to produce the same shaded jars that we ship as part of the SDK zip. Many of the assorted deprecations/removals/cleanups that I merge are in the service of someday landing this branch, but it is not a very high priority given that things function correctly today.

[tbroyer]

With Ant isn't it just a matter of passing the path to the java executable to <junit>'s jvm=?

[niloc132]

Of course, but whereas gradle can both auto-detect existing installs and even go and get them for you, here we need to add build goo to install them, pass env vars with them, etc. Not impossible or even hard, but worth it? Maybe eventually, if no one is interested in good gradle/maven support, but as above, I have working-but-incomplete maven support to replace ant.

[jnehlmeier]

Can't we make the usage of errorprone configurable via env variables? Maybe it already is? On Github we build with newest Java + Errorprone and if anyone wants to build on a different JDK version that errorprone does not support, they can disable errorprone.