The JNI specification states that dynamically-loaded libraries are accepted by the JVM for any version of the JNI API (see JNI_OnLoad), while statically-linked libraries are rejected for versions less than 1.8 [0] (see JNI_OnLoad_L). GraalVM also has a mandatory minimum JNI API version of 1.8 [1].
I don't see any downside of bumping the JNI API version to 1.8, as JavaFX has had a higher minimum JDK version for a long time. [0] https://docs.oracle.com/en/java/javase/25/docs/specs/jni/invocation.html [1] https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jni/headers/JNIVersion.java On Sat, May 16, 2026 at 5:37 PM Marius Hanl <[email protected]> wrote: > > Hi all, > > I did some experiments with GraalVM recently and got to a point where I > got the following exception: > > Caused by: java.lang.UnsatisfiedLinkError: Unsupported JNI version > 0x10002, required by glass > > I then saw that there are still some locations in our code, e.g. > native-class\win\Utils.cpp where we return JNI_VERSION_1_2 on JNI_OnLoad > or use it in jvm->GetEnv(&env, JNI_VERSION_1_2);. > > It looks like that this does not work anymore on JDK-25. I updated it to > JNI_VERSION_1_8 and it worked again for me. Does it make sense to bump > it everywhere to JNI_VERSION_1_8? Is there any downside in not doing > that? Is there more I need to know? > > I can create an issue and a PR, but want to gather more information > about this first. > > -- Marius >
