In a modular environment, if a dependent class cannot be found because of system misconfiguration, a spurious message can be emitted:

Error: A JNI error has occurred, please check your installation and try again

followed by an exception that gives the exact problem. This has nothing to do with JNI, and has nothing to do with the JDK installation. Instead, it's a misconfiguration of modules.

The attached test case is a bit cumbersome but it's the smallest I could get. There are three subdirs: src1 contains mod.a that exports a package; src2 contains mod.b that requires mod.a and that has a main-class; src3 is a modification of mod.a that doesn't export the necessary package.

The shell script run.sh compiles src1, then compiles src2, then runs the main program, which succeeds since it successfully depends on mod.a from src1. Then it compiles the variant version of mod.a in src3 and runs the main program again. This fails expectedly since mod.a no longer exports the package required. However, it gives the misleading JNI error message.

Full messages are shown below, including echoed commands from the run.sh script:

+ rm -rf classes1 classes2 classes3 modules
+ mkdir classes1 classes2 classes3 modules
+ javac -d classes1 src1/Foo.java src1/module-info.java
+ jar cf modules/mod.a.jar -C classes1 .
+ javac -d classes2 --module-path modules src2/Bar.java src2/module-info.java
+ jar cf modules/mod.b.jar -C classes2 .
+ java --module-path modules -m mod.b/pkg.b.Bar
Hello, Jigsaw!
+ javac -d classes3 src3/Foo.java src3/module-info.java
+ rm modules/mod.a.jar
+ jar cf modules/mod.a.jar -C classes3 .
+ java --module-path modules -m mod.b/pkg.b.Bar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.IllegalAccessError: superclass access check failed: class pkg.b.Bar (in module mod.b) cannot access class pkg.a.Foo (in module mod.a) because module mod.a does not export pkg.a to module mod.b
at java.lang.ClassLoader.defineClass1(java.base@9-ea/Native Method)
at java.lang.ClassLoader.defineClass(java.base@9-ea/ClassLoader.java:947)
at java.lang.ClassLoader.defineClass(java.base@9-ea/ClassLoader.java:1024)
at java.security.SecureClassLoader.defineClass(java.base@9-ea/SecureClassLoader.java:182)
at jdk.internal.loader.BuiltinClassLoader.defineClass(java.base@9-ea/BuiltinClassLoader.java:512)
at jdk.internal.loader.BuiltinClassLoader.lambda$findClassInModuleOrNull$2(java.base@9-ea/BuiltinClassLoader.java:449)
at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method)
at jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(java.base@9-ea/BuiltinClassLoader.java:450)
at jdk.internal.loader.BuiltinClassLoader.findClass(java.base@9-ea/BuiltinClassLoader.java:354)
at java.lang.ClassLoader.loadLocalClass(java.base@9-ea/ClassLoader.java:536)
at java.lang.Class.forName(java.base@9-ea/Class.java:446)
at sun.launcher.LauncherHelper.loadModuleMainClass(java.base@9-ea/LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(java.base@9-ea/LauncherHelper.java:496)