The check for JDK-8195129 can cause a library to be prematurely/duplicately loaded in a different ClassLoader

[magneticflux-]

Environment

• LWJGL version: 3.2.2
• LWJGL build #: 10
• Java version: 1.8.0_292 AdoptOpenJDK
• Platform: Windows
• Module: core

Description

When in a complex classpath environment (such as the FabricMC KnotClassLoader which loads nested jar files), the check for JDK-8195129 causes the native library in question to be loaded during the "extraction" phase and before the "loading" phase. Crucially, the library isn't even loaded with the supplied class loader, it's loaded with the class loader of the SharedLibraryLoader class.

This has the effect of throwing an UnsatisfiedLinkError during the "loading" phase since the library has already been loaded.

The check in question:

lwjgl3/modules/lwjgl/core/src/main/java/org/lwjgl/system/SharedLibraryLoader.java

Lines 279 to 286 in e4a6cc8

	if (workaroundJDK8195129(file)) {
	// We have full access, the JVM has locked the file, but System.load can still fail if
	// the path contains unicode characters, due to JDK-8195129. Test for this here and
	// return false if it fails to try other paths.
	try (FileChannel ignored = extract(file, resource)) {
	System.load(file.toAbsolutePath().toString());
	}
	}

I propose ideally the check for JDK-8195129 should search the string for Unicode characters. If that isn't possible, then it should at least try to load the library using the class loader supplied to SharedLibraryLoader::load.

[Spasi]

Thanks @magneticflux-!

I tried to be clever about this and avoid System.load completely, but it became too involved. In the end, it's a JVM bug and the implementation details may change in the future, so the only way to be sure is to actually call System.load. The fix propagates the lambda passed to Library.loadSystem down to the SharedLibraryLoader, so the call should now happen in the correct ClassLoader.

Please try the next 3.3.0 snapshot and let me know how it works.