@Jendrik Johannes Whats your current approach to work around that ignored ticket about java toolchains? https://github.com/gradle/gradle/issues/16628#issuecomment-2654688452

@René depends on the needs of the project. In some, we accept that we cannot fully control the version. But we are waiting also to get this fixed to do better. In the project I mentioned in the issue, where we need full reproducibility including

module-info.class

files, we currently do not use toolchain auto-provisioning. In fact, you can say we do not use toolchains at all 😕. Instead, we use the Java version Gradle is started with. If the version does not fit the version we want, we print a big WARNING for the user with instructions on how to update the version on their machine. On CI, the version definition and JDK provisioning is done through GitHub actions. Which is quite a mess right now that currently that requires updating the version in multiple places. This is the code that checks and configures the version: https://github.com/hiero-ledger/hiero-gradle-conventions/blob/main/src/main/kotlin/org.hiero.gradle.feature.java-compile.gradle.kts#L9-L35

we fell back to our custom plugin implemenation to resolve jdks for now. i had that deprecated a while ago but had to resurrect it now