LWJGL Native Library Selection

[Hydroque]

final String NATIVE_DIST = System.getProperty("os.name").split(" ")[0];
System.out.println("Attempting to use '" + NATIVE_DIST + "' from native folder.");
System.setProperty("org.lwjgl.librarypath", new File("native/" + NATIVE_DIST).getAbsolutePath());

This code I made works wonders. I get the prefix name (ignoring spaces) and calculate which one to use. I set it in the property to use it with RunnableJar situations.

Is there a more efficient way of doing this or am I missing something?

[abcdef]

There is a shared library loader in the api

https://github.com/LWJGL/lwjgl3/blob/master/modules/core/src/main/java/org/lwjgl/system/SharedLibraryLoader.java

This covers a lot more than you have. I haven't used this myself as I have my own loader so other maybe able to tell you how to use it

[Hydroque]

I don't like his loader at all it's overly complicated for no practical reason.

[abcdef]

What's so complicated about calling

SharedLibraryLoader.load();

?

[kappa]

infact you don't even need to do that, if nothing is specified manually for the natives the sharedloader is automatically triggered by LWJGL. All you need to make sure is that a jar/zip file containing the natives is on the classpath (it'll automatically only pick the ones for the current platform its running on).

[Kai]

@kappa is right! You don't even notice that the SharedLibraryLoader is doing its job.

And I am very happy with that SharedLibraryLoader !
It exactly suits the needs that it is specifically designed for, and it is not at all overly complex. Like I said, it is exactly right for the following needs:
- have a OS and arch-specific shared library at the root of the classpath
- extract the correct OS and arch-specific library at runtime into a user's temp folder
- don't extract it twice when there is already an extracted version of it which is the same file, which would endanger filling up your user directory with tmp files (CRC check)

Personally I use it very successfully with Maven projects, where the platform-specific jar files containing the shared libraries are fetched depending on the OS/arch via Maven profile activations.
But you can just as well keep a jar file around which contains all OS'es and arch's shared libraries. It doesn't matter. Which is the beauty of that loader.

[Hydroque]

There is not need to copy anything to %temp% when it's already existing. I like the style of jars - you can index and use it without having to extract it. As for the architecture, it's very easy to list the versions for download from a website. "Use this one for x86(x32) and this one for x64." No need to almost double the data (x32->x64), even zipped.

I don't like redundancy and feel the code could be written neater.