Work around reflective access errors on JVM 16+

[tadfisher]

Fixes #629

[wakingrufus]

I am not that familiar with the Worker API yet. are we sure this is the correct way to check the java versions?
ie. is it always inherited from the java version of the gradle process? or is there a toolchain/fork option we should be looking at?

[JLLeitschuh]

Good question. I don't think that, at this point, we are executing in the worker process. At this point we are still in the Gradle process, so it will be the JVM version of that process/classloader.

The workers are running in their own process/classloader, and static variables are unique-per-classloader hierarchy IIRC. As such, you can safely assume that any JavaVersion.current() calls will be accurate within the JVM classloader they are executing inside of.

[tadfisher]

Looking at Gradle's exec code, the default JavaForkOptions is set up here:

@Override
public JavaForkOptionsInternal newDecoratedJavaForkOptions() {
    JavaDebugOptions javaDebugOptions = objectFactory.newInstance(DefaultJavaDebugOptions.class, objectFactory);
    final DefaultJavaForkOptions forkOptions = instantiator.newInstance(DefaultJavaForkOptions.class, fileResolver, fileCollectionFactory, javaDebugOptions);
    forkOptions.setExecutable(Jvm.current().getJavaExecutable());
    return forkOptions;
}

So by default, Gradle appears to set the java executable for the child process to the same executable as the Gradle daemon. To override this, I believe we would need to call setExecutable ourselves with a path to some other Java toolchain's javac. Since we don't do that, JavaVersion.current() should be accurate for both the Gradle daemon process and the forked worker process.

[wakingrufus]

As for testing, if this does fix #629 can you increase the maximum gradle version to the latest 8.x?
If not, this seems like a worthwhile fix, even if it is not the only thing needed for gradle 8 support

[tadfisher]

Sure. I've been using this patch on Gradle 8, and I haven't seen any other showstoppers for Gradle 8 support.

[IvanPizhenko]

@wakingrufus @JLLeitschuh Hi, is there a chance for this to be merged and released anytime soon? We are also using ktlint and suffering from this issue.

[JLLeitschuh]

CI currently fails for this PR which is currently a non-starter for merging this PR at this moment

[tadfisher]

@JLLeitschuh Looks like CI is good to go. Let me know if the change to TestVersions.maxSupportedKotlinVersion makes sense; these are the versions listed in the Kotlin Gradle plugin documentation here. Without that change, our minimum Gradle version (currently 6.8) will fail with Kotlin 1.8.10, which requires Gradle 6.8.3.

[JLLeitschuh]

I'd like to wait for this if your fine with that

#642

[wakingrufus]

LGTM. ill merge my other PR, then we can do this one

[JLLeitschuh]

Just rebased the changes

[JLLeitschuh]

Thank you for your contribution!