Gradle daemon may run on an older jdk than the project's

[ben-manes]

In this case the Gradle daemon runs on jdk21, as defined by its toolchain in gradle-daemon-jvm.properties. While the Caffeine project normally uses jdk21 with --release 11, for its internal tooling that uses jdk24's Gatherers to replace its own batching with windowFixed. Gradle 8.13 does not yet support running on jdk24, but this all works itself out thanks to toolchain settings which auto bootstrap the jdks if absent.

Upgrading to v3.9 and re-enabling the task fails as below (./gradlew forbiddenApis -DforbiddenApis -q -). The Gatherers is not available in the daemon's jdk but is in the compiler's. It succeeds if using gradle nightly (8.14 pre-release) and a jdk24 daemon.

Caused by: de.thetaphi.forbiddenapis.ForbiddenApiException: Check for forbidden API calls failed while scanning class 'com.github.benmanes.caffeine.cache.simulator.Simulator' (Simulator.java): java.lang.ClassNotFoundException: java.util.stream.Gatherers (while looking up details about referenced class 'java.util.stream.Gatherers')
        at de.thetaphi.forbiddenapis.Checker.checkClass(Checker.java:458)
        at de.thetaphi.forbiddenapis.Checker.run(Checker.java:509)
        at de.thetaphi.forbiddenapis.gradle.CheckForbiddenApis.checkForbidden(CheckForbiddenApis.java:666)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
        ... 122 more
Caused by: java.lang.ClassNotFoundException: java.util.stream.Gatherers
        at de.thetaphi.forbiddenapis.Checker.getClassFromClassLoader(Checker.java:299)
        at de.thetaphi.forbiddenapis.Checker.lookupRelatedClass(Checker.java:311)
        at de.thetaphi.forbiddenapis.ClassScanner.checkClassUse(ClassScanner.java:109)
        at de.thetaphi.forbiddenapis.ClassScanner.checkClassUse(ClassScanner.java:123)
        at de.thetaphi.forbiddenapis.ClassScanner$3.checkMethodAccess(ClassScanner.java:399)
        at de.thetaphi.forbiddenapis.ClassScanner$3.visitMethodInsn(ClassScanner.java:569)
        at de.thetaphi.forbiddenapis.asm.ClassReader.readCode(ClassReader.java:2447)
        at de.thetaphi.forbiddenapis.asm.ClassReader.readMethod(ClassReader.java:1512)
        at de.thetaphi.forbiddenapis.asm.ClassReader.accept(ClassReader.java:745)
        at de.thetaphi.forbiddenapis.asm.ClassReader.accept(ClassReader.java:425)
        at de.thetaphi.forbiddenapis.Checker.checkClass(Checker.java:444)
        ... 127 more

[dweiss]

Hi @ben-manes. It's a pleasure - big fan.

I think the forbiddenapi's checker has always worked with whatever gradle runs with (the daemon or no-daemon mode). It never forked a worker according to the toolchain spec and it loads the signatures of the jvm it's running with. I recall we had to conditionally disable the task on newer JVMs until signatures were available.

[ben-manes]

Thanks Dawid!

Yep, this is not critical by any means and was flagging for awareness. It’s perfectly reasonable to disable while things catch up and simply nicer when more transparently handled.

[uschindler]

Hi Ben,
sorry for you hoping that forbiddenapis 3.9 would solve the toolchain issues. Actually the statement "works with JDK 24 + 25" in the release notes was about forbiddenapis ability to scan class files and ships with with signatures for Java 24. Unfortunately forbiddenapis has no support for toolchains and the task always runs in the Gradle JVM. Normally this is no problem, but for resolving classes it needs them on some kind of classpath. Basically there are 2 solutions for that:

• execute forbiddenapis in a toolchain's JVM. This requires a new and rewritten Gradle Task which can call the CLI (theres an issue about it: Use Gradle toolchains to avoid signature parsing errors #248). Unfortunately the CLI is limited and does not support everything that Gradle/Maven does. We may needs som CLI which can communicate with the caller in a better way its options.
• use toolchains to get the "rt.jar/modules JRT" to add it to some kind of "signature/scanning bootclasspath" but still run in Gradle JVM. I prefer this approach, but still needs "complicated" changes in code.

For your case, the easiest workaround is to pass the option failOnMissingClasses = false in the task's config. It will then just print a warning and the checker won't work 100% correct when it encounters missing classes. In normal cases this won't cause issues unless you have very complicated signatures which check that the code called by the scanned class hits a method which is defined in a superclass (e.g., scanned code uses a new class in JDK which is a subclass of some previouly existing class, e.g. you disallow a method call to InputStream#read and JDK 24 has a subclass of InputStream that is called from the scanned code. In this case forbiddenapis won't be able to figure out that it's an input stream and can't fail build).

[uschindler]

Duplicate of #248.

[ben-manes]

Oh failOnMissingClasses is the perfect answer that I had overlooked, thanks!

[dweiss]

What I did was dynamically turn off the task on unsupported jvms. Something like this:

    def gradleJvm = JavaLanguageVersion.of(Jvm.current().javaVersion.majorVersion)
    if (!gradleJvm.canCompileOrRun(toolchainJvm)) {
      task jvmInsufficientForForbiddenApis() {
        doFirst {
          logger.warn("Skipping forbiddenapis because gradle's" +
              " Java version is not sufficient to run it: ${gradleJvm}.")
        }
      }

      tasks.matching { name.startsWith("forbiddenApis") }.configureEach { task ->
        task.enabled(false)
        task.dependsOn jvmInsufficientForForbiddenApis
      }

[uschindler]

Hey @dweiss,
this check is cool, but I would not let it disable the task and instead set the failOnMissingClasses = false property. The task runs with all JDK versions, it only might not work 100% correct (detect not all issues). Therefore defaulting failOnMissingClasses to false is not a good idea.

Maybe I reopen this issue to add your code from above into the task initialization (with guards for older Gradle versions where Toolchains are not available).

[uschindler]

My idea is to add the above check around here:

forbidden-apis/src/main/groovy/de/thetaphi/forbiddenapis/gradle/ForbiddenApisPlugin.groovy

Line 84 in b58e15c

targetCompatibility = targetCompatibilityGetter

Here the taskData could default failOnMissingClasses to false, if the current JVM cant compile/run the targetCompatibility setting. It would - of course - also print a warning. Basically this resolves the targetCompatibility and could also set the other property's default.