OS-dependent library loading

[Spezi]

Is it possible to set the "-Djava.library.path" VM argument during runtime?

I'd like my program to figure out which OS is running and then set this argument.

[kappa]

haven't tried it but it might work if you do

System.setProperty("java.library.path", "c:\game");

let me know if it does

[Spezi]

No, that doesn't work.

I get "UnsatisfiedLinkError: no lwjgl in java.library.path" even with setting the same path as used before with -Djava.library.path.

[stramit]

I'm pretty sure the VM needs this argument at VM boot time. If you set it at runtime it will not work.

I am also looking for a workaround for this (mainly for my autobuild / test environment) and have done some research but have so far come up blank.

[Matzon]

is this a general issue about whether to append linux, macosx or win32 to the -Djava.library.path?
if so, we could think about solving it in lwjgl internally, by trying a path that has the current platform appended as the last path to search

[princec]

I can't see the need to complicate this further than it already is. If you must ship the same zip file for each OS - and that's really not advisable - put all the natives in the same directory, as they won't name clash and they are just data files to the other OS's and ignored.

Cas

[Spezi]

is this a general issue about whether to append linux, macosx or win32 to the -Djava.library.path?

Yes, but not only. It would also be nice to not need to apply the Djava.library.path param but set it dynamically in the first lines of the program.

I can't see the need to complicate this further than it already is. If you must ship the same zip file for each OS - and that's really not advisable - put all the natives in the same directory, as they won't name clash and they are just data files to the other OS's and ignored.

I also thought about it, but doesn't seem to be a nice solution since the folder structure doesn't match the one from the lwjgl-optional zip file.

[Kylearan]

Hi,

If you must ship the same zip file for each OS - and that's really not advisable - [...]

I'm not sure I understand this comment - why is this not advisable? Having to ship one single jar file only that works on all platforms, instead of having to host three almost identical, sounds preferable to me? 

-Kylearan

[kappa]

I also thought about it, but doesn't seem to be a nice solution since the folder structure doesn't match the one from the lwjgl-optional zip file.

maybe just a change in the folder structure in the lwjgl-optional package will fix this?

I'm not sure I understand this comment - why is this not advisable? Having to ship one single jar file only

increases the downloads size and will have files you don't need, where as if you just choose your platform ou get a smaller download.

[Spezi]

I also thought about it, but doesn't seem to be a nice solution since the folder structure doesn't match the one from the lwjgl-optional zip file.

maybe just a change in the folder structure in the lwjgl-optional package will fix this?

But then you have the problem of selecting manually which files you need for a specific OS.

is this a general issue about whether to append linux, macosx or win32 to the -Djava.library.path?

Yes, but not only. It would also be nice to not need to apply the Djava.library.path param but set it dynamically in the first lines of the program.

The point was that this is not just meant for lwjgl files but also for other libraries.

[Kylearan]

Hi,

increases the downloads size and will have files you don't need, where as if you just choose your platform ou get a smaller download.

Most of the time, the difference in size will be insignificant. You'll save what, about 500kb, which doesn't yet take compression into account? Most projects are a lot larger than this, having a lot of graphics etc. In contrast, three different versions leads to bigger, more confusing websites and force users to read through the website and choose the correct version.

Nah, I still think one version for all platforms is the way to go. That was one of the ideas why they've created Java in the first place...

-Kylearan

[Spezi]

What happened to the classloader posted here yesterday? Did an admin delete the post?

[Matzon]

well, I know I didn't ... - and I saw the post too

[oNyx]

[...]Most of the time, the difference in size will be insignificant. You'll save what, about 500kb, which doesn't yet take compression into account? Most projects are a lot larger than this, having a lot of graphics etc. In contrast, three different versions leads to bigger, more confusing websites and force users to read through the website and choose the correct version.

Nah, I still think one version for all platforms is the way to go. That was one of the ideas why they've created Java in the first place[...]

With webstart you simply specify the jars you want for a specific platform... and thats it. One jnlp which works everywhere, but it requests different library jars for each platform.

If you do platform specific builds such as an exe installer for windows, a zip application bundle for mac and whatever for linux... why would you then include all that shit you don't need? It doesn't exactly save time to do so, but it wastes quite a lot of bandwidth (you want thousands of downloads each month).

You can put a really neat demo into 5mb (stripped jre included!) so why would you want to increase that by 10%? With a demo that small you might get quite a lot of 56k downloaders... in which case 0.5mb more would increase the number of incomplete downloads noticeable.

There are always easy ways to optimize the size (such as this one or choosing proper formats like DXTn for graphics, ogg for sound, pack200 for jars and installers with lzma compression). Take that opportunity. And there are complicated (low level) ones, which aren't worth the trouble. This way you can easily peel off half of the size without spending too much time.

[Jon]

Stripped JRE and a 5 MB demo? What exactly is "stripped" about this JRE, and how can I do this? If I can bundle a JRE with Stencyl for Windows users without a recent version of Java, that could save me a lot of trouble...