This message was deleted.

Same config and Gradle versions works fine against another project that specifies the same target Java versions

try using the java toolchain support; if separates the JVM version running Gradle from what is used to compile tasks / execute tests, etc. And it can install the correct JDK version if not found already.

its not my project though so cannot (or should not modify their build)

then set JAVA_HOME to Java 8.

😱

Yeah, if you build for jdk8 with jdk9+ with only source&target (without bootclasspath) you could get broken result which wouldn't run on real 1.8. IIRC, there were some incompatible changes. We were bitten by Buffer/ByteBuffer API changes (some methods changed final modifier) which produced bytecode incompatible with 1.8 when built with jdk11. You have to either use jdk8 or switch to release instead of source+target.

Interesting. I thought that any newer version of jvm can still generate old bytecode target

it’s pretty messy. safest options are to use the target JVM version directly (drawbacks as this is used for both Gradle and compiling, etc) or use Gradle java toolchain to separate Gradle JVM from compile (etc) JVM.

Jdk9+ have warning about that somewhere in docs. It was same for previous versions (like compiling for 1.5/1.6 with 1.8, I'm not old enough to be forced to live with 1.4.2 fortunately) but usually it worked without issues it you're lucky xD So javac was always that messy but with much slower changes in standard library APIs it wasn't that easy to run afoul of it. Release javac parameter in jdk9 actually simplified this since before you had to use 3 parameters (source, target and bcp for target jdk). Newer Java easily generates older bytecode for 1.8 but standard library classes changed a bit so if you compile

bb.flip()

where

bb

is a

ByteBuffer

against java.base in jdk11 it will generate invokevirtual for the

ByteBuffer#flip

instead of

Buffer#flip

(which was final method in jdk8 and will fail with no such method in runtime). But if you set either

--release

or

-source

+

-target

+ `-bootclasspath`/`--system` it would call

Buffer#flip

as it should.