Thank you for providing a valid reproducer.

The issue is in the backlog of the relevant team and is prioritized by them.

Hey! We are looking into fixing this here. In the meantime, here are some comments on the issue.

First, setting the javaCompiler to null straight up does not work anymore.

This is intentional, because javaCompiler is not an optional property anymore. However, setting it to null should not be required, as the compiler property gets inferred from the forkOptions.javaHome or forkOptions.executable if those are configured. The fork options paths take priority even if the project level java { toolchain { ... } } is configured.

the purpose of forkOptions.executable as the value is forced match the value of the javaCompiler property. However, it is not deprecated which leads me to believe that something is incorrect here.

For the majority of cases, if a build configures javaCompiler on the compilation task directly, there is no reason to configure the executables as well. Therefore, having both is most likely an error, as one will be ignored. If a build does end up having both configured, they should either agree on the value or the conflict should be resolved by the user. Normally that would be removing the usage of forkOptions and relying directly on toolchains.

The reason it is not deprecated is that most builds that do use the executable (without migrating to toolchains) simply point it to a javac in the existing JDK installation, which is the main use case and is supported.

First, setting the javaCompiler to null straight up does not work anymore.

This is intentional, because javaCompiler is not an optional property anymore.

But shouldn't setting to null then have been deprecated before?
As far as I understood it gave no deprecation warning in 7.6, yet breaks with 8.0 which is uncommon for Gradle.

After putting some more thought into it and running into a somewhat related issue, I agree with @Vampire here. I've filed #24055 to track this separately.

@TheMrMilchmann we merged the fix for this into the Gradle 8.0.x line and published a snapshot.
Could you please verify that it works for you now?

You can use the wrapper with 8.0.2-20230301020537 0000 version. Here is a command to update the wrapper:

gradle wrapper --gradle-version=8.0.2-20230301020537 0000

I can confirm that this does seem to work mostly. However, I have one remaining issue/question: In an attempt to prevent potential ordering issues, I have deferred the retrieval of the tool and, thus, the configuration of forkOptions.executable to the execution phase (via doFirst). This looks roughly as follows:

val javaLauncher = provider {
    if (java.toolchain.languageVersion.orNull?.canCompileOrRun(REQUIRED_JAVA_VERSION) == true) {
        javaToolchains.launcherFor(java.toolchain).orNull ?: error("Could not get launcher for toolchain: ${java.toolchain}")
    } else {
        javaToolchains.launcherFor {
            languageVersion.set(JavaLanguageVersion.of(PREFERRED_JAVA_VERSION))
        }.orNull ?: error("Could not provision launcher for Java $PREFERRED_JAVA_VERSION")
    }
}

inputs.property("javaLauncher", javaLauncher.map { it.metadata.languageVersion.asInt() })

/* See https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implementation_unknown */
@Suppress("ObjectLiteralToLambda")
doFirst(object : Action<Task> {
    override fun execute(t: Task) {
        options.forkOptions.executable = javaLauncher.get().executablePath.asFile.absolutePath
    }
})

This, too, works fine on Gradle 7.6.1 but fails on 8 (including 8.0.2-20230301020537 0000) in some cases. For example, if a project toolchain is available but incompatible). Since this is a somewhat hacky approach I'm wondering if it should be supported. However, I tend to believe it should until forkOptions.executable becomes or is replaced by a property.

I've updated the MCVE in TheMrMilchmann/MCVE@e195bf3 to reproduce this.

How about you set the toolchain you want to have on the JavaCompile task directly instead of adding it in a "sneaky" way via a new input property?

The following setup allows doing that. The only downside it has is that it selects the executable by path manipulation. Though I think it is much cleaner. The input tracking for the Java version works out of the box.

val currentJavaToolchain = provider {
    java.toolchain
}

val selectedCompiler = currentJavaToolchain.map { toolchain ->
    val currentCompiler = project.javaToolchains.compilerFor(toolchain).get()
    if (currentCompiler.metadata.languageVersion.canCompileOrRun(REQUIRED_JAVA_VERSION)) {
        currentCompiler
    } else {
        project.javaToolchains.compilerFor { languageVersion.set(JavaLanguageVersion.of(PREFERRED_JAVA_VERSION)) }.get()
    }
}

withType<JavaCompile>().configureEach {
    javaCompiler.set(selectedCompiler)

    /* ECJ does not support generating JNI headers. Make sure the property is not used. */
    options.headerOutputDirectory.set(provider { null })

    options.isFork = true
    options.forkOptions.jvmArgumentProviders.add(CommandLineArgumentProvider {
        mutableListOf("-cp", ecj.asPath, "org.eclipse.jdt.internal.compiler.batch.Main")
    })
    @Suppress("ObjectLiteralToLambda")
    doFirst(object : Action<Task> {
        override fun execute(t: Task) {
            val javacExecutable = javaCompiler.get().executablePath.asFile
            val javaExecutableName = javacExecutable.name.replace("javac", "java")
            val javaExecutablePath = javacExecutable.parentFile.resolve(javaExecutableName).absolutePath
            options.forkOptions.executable = javaExecutablePath
        }
    })

}

Thanks for the input, @wolfs! I've considered doing something similar before but it didn't cross my mind that manipulating the path like that is possible now. Given that this is possible, I think we can consider this issue to be fixed.