Fix JNI header location #5622
Open
Fix JNI header location #5622
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
troelsbjerre
requested review from
Badya
and removed request for
PavelPunegov and
projedi
projedi
requested changes
Jan 15, 2026
kotlin-native/build-tools/src/main/kotlin/org/jetbrains/kotlin/tools/NativePlugin.kt
Outdated
Show resolved
Hide resolved
The existing solution for finding the location of the JNI headers relies on the java.home of the running process. This can fail, when the gradle daemon is started from a JRE, which usually do not include the header files. This fix instead uses gradle's JavaToolChainService to find an appropriate JDK to access the headers from. #KT-82607 Fixed
This change modernizes JNI header discovery in the Kotlin/Native utilities while providing a smart bridge for the current bootstrap process. 1. Enhanced ClangArgs.Jni Discovery: Updated the low-level discovery logic in native/utils to look for a JDK in the following order: - The 'konan.jdk.home' property (passed by Gradle). - The 'JAVA_HOME' environment variable (for standalone/CLI usage). - The process's own 'java.home' (as a final fallback). 2. Gradle Toolchain Integration: Updated PlatformManagerProvider to obtain the JDK 11 path via Gradle's JavaToolchainService and inject it into the 'konan.jdk.home' property. 3. Intermediate Bootstrap Workaround: Since the current build uses a bootstrap version of ClangArgs that doesn't yet recognize the new property, a temporary 'jniHostCompilerArgs' bridge is added to NativeToolsExtension. This property detects if the bootstrap's default paths are "broken" (missing jni.h) and automatically hot-patches them with the correct Toolchain JDK paths. This allows tasks like :kotlin-native:Interop:Runtime:callbacks.o to succeed immediately, even on JRE-only Gradle daemons, while ensuring the underlying utilities are self-sufficient once bootstrapped. ^KT-82607
troelsbjerre
force-pushed
the
prr/troels/KT-82607
branch
from
60911fa to
d2fd9f7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The existing solution for finding the location of the JNI headers relies on the java.home of the running process. This can fail, when the gradle daemon is started from a JRE, which usually do not include the header files. This fix instead uses gradle's JavaToolChainService to find an appropriate JDK to access the headers from.
#KT-82607 Fixed