I was able to reproduce this and it is indeed a problem with Class.getResource() that breaks the SharedLibraryLoader. Using context.getClassLoader().getResource() fixes it, the next snapshot (3.1.4 build 3) will work with all JARs in the module path. Details:
The Class.getResource() method has been revised in Java 9 to not return any non-class resources, unless they belong to the same module as the module that defines the receiver class (+ access restrictions based on the caller and whether the module is open or not). When the LWJGL JAR files are added to the module path, they become automatic modules, they can access all other automatic modules and the unnamed module, and everything else can access them. The problem is that the natives JAR is a different module from the corresponding classes JAR. So, Class.getResource() cannot access the native libraries, because it doesn't look anywhere else other than the module of the class. Going through the ClassLoader bypasses this restriction, it is able to look into all open modules and find the resource.
There are two workarounds that can make it work with the current binaries:
- Use the classpath instead of the module path for LWJGL.
- Use the new --patch-module parameter for all LWJGL modules. For example:
java -cp <classpath> -p <module path> --add-modules ALL-MODULE-PATH \
--patch-module org.lwjgl=lwjgl-natives-windows.jar \
--patch-module org.lwjgl.glfw=lwjgl-glfw-natives-windows.jar \
...more here.. \
my.main.Class