Hello Guest

OS-dependent library loading

  • 35 Replies
  • 37376 Views
*

Offline Spezi

  • *
  • 43
OS-dependent library loading
« on: January 14, 2007, 17:20:21 »
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.

*

Offline kappa

  • *****
  • 1319
Re: OS-dependent library loading
« Reply #1 on: January 14, 2007, 18:01:35 »
haven't tried it but it might work if you do

Code: [Select]
System.setProperty("java.library.path", "c:\game");
let me know if it does :)
« Last Edit: January 14, 2007, 20:26:07 by javalwjgl »

*

Offline Spezi

  • *
  • 43
Re: OS-dependent library loading
« Reply #2 on: January 14, 2007, 22:51:10 »
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.

Re: OS-dependent library loading
« Reply #3 on: January 15, 2007, 02:58:50 »
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.

*

Offline Matzon

  • *****
  • 2242
Re: OS-dependent library loading
« Reply #4 on: January 15, 2007, 07:52:20 »
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

*

Offline princec

  • *****
  • 1933
    • Puppygames
Re: OS-dependent library loading
« Reply #5 on: January 15, 2007, 11:21:17 »
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 :)

*

Offline Spezi

  • *
  • 43
Re: OS-dependent library loading
« Reply #6 on: January 15, 2007, 12:12:09 »
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.
« Last Edit: January 15, 2007, 12:14:35 by Spezi »

Re: OS-dependent library loading
« Reply #7 on: January 15, 2007, 16:35:07 »
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

*

Offline kappa

  • *****
  • 1319
Re: OS-dependent library loading
« Reply #8 on: January 15, 2007, 17:30:16 »
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.
« Last Edit: January 15, 2007, 17:32:30 by javalwjgl »

*

Offline Spezi

  • *
  • 43
Re: OS-dependent library loading
« Reply #9 on: January 15, 2007, 17:54:14 »
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.
« Last Edit: January 15, 2007, 17:57:57 by Spezi »

Re: OS-dependent library loading
« Reply #10 on: January 16, 2007, 06:45:36 »
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

*

Offline Spezi

  • *
  • 43
Re: OS-dependent library loading
« Reply #11 on: January 16, 2007, 08:56:33 »
What happened to the classloader posted here yesterday? Did an admin delete the post?

*

Offline Matzon

  • *****
  • 2242
Re: OS-dependent library loading
« Reply #12 on: January 16, 2007, 12:15:34 »
well, I know I didn't ... - and I saw the post too

*

Offline oNyx

  • ***
  • 177
  • 弾幕
Re: OS-dependent library loading
« Reply #13 on: January 17, 2007, 07:59:57 »
[...]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.

*

Offline Jon

  • *
  • 14
Re: OS-dependent library loading
« Reply #14 on: January 17, 2007, 08:09:05 »
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...