Support Toolchains for JVM projects

[3flex]

Expected Behavior

If I am using Gradle's toolchain support for my Kotlin project, detekt should, by default, use the version of the JDK specified by the toolchain during execution. set the JDK target and JDK path as defined by the toolchain. The values can be overridden as needed.

I.e. if this configuration is in place:

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(11))
    }
}

Then detekt should setup its Kotlin compilation environment and perform its analysis against JDK 11, regardless of which JDK version was used to run Gradle itself.

Current Behavior

detekt runs using the same version of Java that is used to run Gradle.
detekt sets its own default for the JDK target, which can be manually overridden on individual tasks. It currently does not accept a custom JDK path as an input parameter.

Context

As an example, if Gradle is run with JDK 11, but toolchain support is enabled and configured with JDK version 16, there will be unresolved reference errors if the codebase uses any new APIs from Java 12-16. It would also prevent rules that are configured with references to Java 12+ APIs, like ForbiddenMethodCall, from working correctly.

Adding support mirrors the toolchain support added to Kotlin in 1.5.30.

I'm very happy to work on this one, but it will mean removing the classloader cache, or at least bypassing it, as detekt will have to execute outside of Gradle's process using Gradle's Worker API with process isolation or using JavaExec, so I am asking for feedback first.

My preference is removing the classloader cache for simplicity, and I also believe this will reduce Gradle daemon memory pressure.

Edit: Toolchains will help with #3396 as it would allow running the build on Java 8 while running detekt with Java 11.

[BraisGabin]

I just read about the Gradle¡s Worker API and I never use it directly. But I understood that we could use it and cache the class loader in it. I remember that it was like we could create our own daemon. Am I right? If we can do that, go ahead.

But I would vote against just removing the cache and going back to the old performance. It was really bad.

[3flex]

I'll start with a PR to switch to worker API, then if that goes well I'll follow up with a PR introducing toolchain support.

I believe worker API with process isolation will have better performance than using JavaExec like it did previously, though it might be a bit slower than the current implementation.

[BraisGabin]

That sounds good. We can make some benchmarks and compare the implementations. I'm not worried about loosing a bit of performance if we improve the correctness.

[cortinico]

execute outside of Gradle's process using Gradle's Worker API with process isolation or using JavaExec, so I am asking for feedback first.

A nice benefit of using the Workers API is that will mitigate the issues arising from misalignment of Kotlin version between our internal version and the version embedded with Gradle.

So ideally is something we should look into, even regardless of the toolchain support.

[chao2zhang]

There is known de/serialization overhead of Worker API - It sounds like we are using Worker API only for the process isolation rather than granular task parallelization.

• It looks like Worker API has some limitations as mentioned in Run detekt's Gradle tasks with Gradle's Worker API #4128
• It feels JavaExec is a better approach if we are only approaching the isolation issue.

[3flex]

Worker API starts daemons which are reused between tasks and builds, so the advantage is the JVM startup cost is only experienced when new daemons launch. This is favorable to JavaExec which starts a new JVM instance for every single task and doesn't reuse them.

On projects with many modules, or heavy use of KMM, there could be many detekt tasks so the total cost of starting new JVMs for each task can be significant. That's one of the reasons the custom classloader approach was introduced in the first place.

Both achieve process isolation. Worker API issues I mentioned should only be a factor if someone is actively working on the Gradle plugin.

[3flex]

I've updated the description given what I found out while implementing #5269.