Support Java 16

[sbrannen]

Current attempts to use Gradle 6.5 with openjdk version "16-ea" 2021-03-16 result in a failure along the lines of:

> Task :buildSrc:validatePlugins FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':buildSrc:validatePlugins'.
> There was a failure while executing work items
   > A failure occurred while executing org.gradle.plugin.devel.tasks.internal.ValidateAction
      > Unsupported class file major version 60

Please add support for Java 16.

Note, however, that the above failure is due to lack of support for Java 16 in ASM.

[rdehuyss]

I would love to evaluate project loom for my library (https://github.com/jobrunr/jobrunr) but since that is only available in jdk 16 and I also use gradle this is difficult now.

[eskatos]

@rdehuyss you can use different JVMs for running Gradle and compiling/running tests, see https://docs.gradle.org/current/userguide/building_java_projects.html#sec:java_cross_compilation

[rdehuyss]

@eskatos , thanks! I did not know that...

[lppedd]

@rdehuyss were you able to test Loom using Gradle or did you switch to Maven?
Sorry for this small OT.

[rdehuyss]

I put it on my backlog for the moment...

[lppedd]

@rdehuyss I tested it. Instructions by @eskatos works perfectly. It's a matter of minutes.

[rdehuyss]

@lppedd Thx for your feedback. It indeed wasn't that much work. I'm testing JobRunr now with Project Loom and all seems ok. I still need to do further performance testing.

@eskatos I also have automated tests (it's a test where JobRunr is tested against 12 different JVM's - see also https://www.jobrunr.io/blog/testing-jobrunr-against-12-different-jvms/) where the approach mentioned above is difficult. Since ASM 9 is now available in beta with support for JDK 16, what are the plans for gradle?

[mikehearn]

This problem really needs to be fixed in a more general way than just bumping ASM versions and doing a new Gradle release.

The problem is that Gradle (sometimes via Groovy) really wants to analyse bytecode in various ways at various points, and pukes when it can't. This is very hard to fix directly because bytecode is not forwards compatible, so you can't analyse versions from the future.

There is therefore only one robust solution: javac must be told to emit old bytecode versions. This it can easily do via the -target and -source flags. Currently it doesn't work because Gradle is still living in a world where new Java versions were rare events, so it just blithely assumes that whatever Java version is running it is the version it should pass to -target/-source. It passes -target 16 -source 16 to javac as part of compiling some Java/Groovy together, the Groovy compiler tries to read the bytecode and can't, then the error gets partly swallowed and it's all a big mess.

This behaviour makes no sense. If Gradle must analyse bytecode then it has only one option it it wants to be compatible with the latest JVMs: it has to cap the target release of any non-user controlled javac invocations at whatever version of Java was the latest supported version at the time of release. This would allow it to be run with the JVM versions "from the future" and still be able to build projects.

That would stem the bleeding, but of course what people want is to be able to use new Java features with old Gradles. They could do so as long as the new feature didn't require new bytecode features (i.e. new APIs but usually not new language features). To support all new Java features with old Gradles implies one of two things:

1. Gradle must be able to optionally sacrifice its features that rely on reading bytecode (some stuff related to incremental builds, I think?)
2. Old Gradles must be able to upgrade themselves on the fly to new versions of ASM, because ASM is forwards compatible. This includes ASMs that are lurking, shaded inside Groovy or other dependencies.

The latter approach is definitely the most work, but it would kill the problem once and for all.

At any rate, I hope the Gradle team read this message and think about how to avoid this problem cropping up every six months. As Gradle is not always backwards compatible, the current approach is basically increasing the cost of Java upgrades for Gradle users - now a Java upgrade costs $JAVA_BACKCOMPAT_BREAKS + $GRADLE_BACKCOMPAT_BREAKS. Although I'm sure the Gradle team would love it if everyone upgraded Gradle immediately on upgrade, the world is full of old projects that are parked and no longer receiving significant work. Yet users wish to have a single JDK and still build and work on those old codebases, without upgrading that project's Gradle build. So this feature would help a lot of people over the coming years.