LWJGL Forum

Programming => Lightweight Java Gaming Library => Topic started by: Spezi on January 14, 2007, 17:20:21

Title: OS-dependent library loading
Post by: Spezi 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.
Title: Re: OS-dependent library loading
Post by: kappa on January 14, 2007, 18:01:35
haven't tried it but it might work if you do

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

let me know if it does :)
Title: Re: OS-dependent library loading
Post by: Spezi 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.
Title: Re: OS-dependent library loading
Post by: stramit 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.
Title: Re: OS-dependent library loading
Post by: Matzon 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
Title: Re: OS-dependent library loading
Post by: princec 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 :)
Title: Re: OS-dependent library loading
Post by: Spezi on January 15, 2007, 12:12:09
Quote from: Matzon 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?
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.

Quote from: princec 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.
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.
Title: Re: OS-dependent library loading
Post by: Kylearan on January 15, 2007, 16:35:07
Hi,

Quote from: princec on January 15, 2007, 11:21:17If 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
Title: Re: OS-dependent library loading
Post by: kappa on January 15, 2007, 17:30:16
Quote from: Spezi on January 15, 2007, 12:12:09
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?

Quote from: Kylearan on January 15, 2007, 16:35:07
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.
Title: Re: OS-dependent library loading
Post by: Spezi on January 15, 2007, 17:54:14
Quote from: javalwjgl on January 15, 2007, 17:30:16
Quote from: Spezi on January 15, 2007, 12:12:09
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.

Quote from: Spezi on January 15, 2007, 12:12:09
Quote from: Matzon 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?

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.
Title: Re: OS-dependent library loading
Post by: Kylearan on January 16, 2007, 06:45:36
Hi,

Quote from: javalwjgl on January 15, 2007, 17:30:16
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
Title: Re: OS-dependent library loading
Post by: Spezi on January 16, 2007, 08:56:33
What happened to the classloader posted here yesterday? Did an admin delete the post?
Title: Re: OS-dependent library loading
Post by: Matzon on January 16, 2007, 12:15:34
well, I know I didn't ... - and I saw the post too
Title: Re: OS-dependent library loading
Post by: oNyx on January 17, 2007, 07:59:57
Quote from: Kylearan on January 16, 2007, 06:45:36
[...]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.
Title: Re: OS-dependent library loading
Post by: Jon 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...

Title: Re: OS-dependent library loading
Post by: Matzon on January 17, 2007, 08:47:42
a stripped jre isn't legal yet, though many people dont care about that :)

You basically copy your JRE dir and remove anything that isn't used. Its a trial and error process where you remove some files, and test your app. The actual removal of class files from jre can be automated somewhat, since you can ask the VM to spit out the class names as they're loaded.
Title: Re: OS-dependent library loading
Post by: Matzon on January 17, 2007, 08:49:34
Quote from: Spezi on January 16, 2007, 08:56:33
What happened to the classloader posted here yesterday? Did an admin delete the post?
As I already mentioned, I saw the post too. I have been unable to locate it in the DB.
So either it was removed accidentally without neither your knowledge nor mine, or there is a bug in SMF. Either way, you will have to repost it :/
Title: Re: OS-dependent library loading
Post by: Spezi on January 17, 2007, 09:56:38
Quote from: Matzon on January 17, 2007, 08:49:34
Quote from: Spezi on January 16, 2007, 08:56:33
What happened to the classloader posted here yesterday? Did an admin delete the post?

As I already mentioned, I saw the post too. I have been unable to locate it in the DB.
So either it was removed accidentally without neither your knowledge nor mine, or there is a bug in SMF. Either way, you will have to repost it :/

This wasn't my post and unfortunately I cannot remember the author's name. Maybe he deleted it himself.
Title: Re: OS-dependent library loading
Post by: oNyx on January 17, 2007, 12:09:31
Quote from: Eliwood 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...

Since you're using swing/awt you won't be able to save that much, but you might be able to get it down to like 5mb jre overhead perhaps.

Well, it's sorta complicated to create such a thing. I used Filemon and ProcessExplorer (both from microsoft), bootstrapping of an extracted jre and lots of regex search n replace over in textpad.

That worked fine for a small demo (the gears demo... 1.6mb in size for everything), but it would be better to use some specialized tool (no one wrote one so far) or a custom jre with a specific set of classes (the absolute minimum + the shizzle you need... like java.util).

Quote from: Matzon on January 17, 2007, 08:47:42
a stripped jre isn't legal yet, though many people dont care about that :)
[...]

LALALA I CANT HEAR YOU! ;)
Title: Re: OS-dependent library loading
Post by: cornholio on January 17, 2007, 15:42:41
sorry for the befuddlement, guys - the classloader post was by me.

it worked like a charm until i tried an AWT app using 'jgoodies looks':
http://www.jgoodies.com/freeware/looks/ (http://www.jgoodies.com/freeware/looks/)

now i was having a strange delay of 5-10 secs when using any combobox
for the first time. this problem occured with WinXP but not with Ubuntu.

anyway ... i decided to delete my post until i would have found time to
resolve this issue and post a working version.

since it might work fine if you don't use strange libraries like i do here is
my initial post again (reconstructed by brain).

does anyone have any idea what could cause the delay with jgoodies ?

---------------------------------------------------------------------------

this could be solved with a custom classloader:

when starting your application supply this JVM-parameter:
-Djava.system.class.loader=foo.CustomClassLoader
(source code below)

this parameter will be consistent across all platforms. the CustomClassLoader will
check which OS it is running on and then load the required native libraries from the
appropriate folder. just modify the values in CustomClassLoader.getLibraryPath()
to match your directory-layout...




package foo;

import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;

public class CustomClassLoader extends URLClassLoader {

private static final int OS_TYPE_LINUX = 1;

private static final int OS_TYPE_MACOSX = 2;

private static final int OS_TYPE_WINDOWS = 3;

private static final int OS_TYPE;

static {

String osName = System.getProperty("os.name");

if (osName.startsWith("Windows")) {
OS_TYPE = OS_TYPE_WINDOWS;
} else if (osName.startsWith("Linux") || osName.startsWith("FreeBSD") || osName.startsWith("SunOS")) {
OS_TYPE = OS_TYPE_LINUX;
} else if (osName.startsWith("Mac OS X")) {
OS_TYPE = OS_TYPE_MACOSX;
} else {
throw new LinkageError("Unknown platform: " + osName);
}
}

public CustomClassLoader(ClassLoader parent) {
super(getClasspath(), null);
}

protected String findLibrary(String libName) {

String[] libNames = getLibraryNames(libName);
for (int i = 0; i < libNames.length; i++) {
File libFile = new File(getLibraryPath(), libNames[i]);
if (libFile.isFile())
return libFile.getAbsolutePath();
}

return super.findLibrary(libName);
}

public static final URL[] getClasspath() {

String[] tk = System.getProperty("java.class.path").split(File.pathSeparator);

try {

URL[] urls = new URL[tk.length];
for (int i = 0; i < urls.length; i++) {
boolean isJar = tk[i].toLowerCase().endsWith(".jar");
urls[i] = new URL("file", "localhost", tk[i] + (isJar ? "" : "/"));
}

return urls;

} catch (MalformedURLException e) {
throw new RuntimeException("malformed classpath");
}
}

public static final String[] getLibraryNames(String libName) {

switch (OS_TYPE) {
case OS_TYPE_LINUX:
return new String[] { "lib" + libName + ".so" };
case OS_TYPE_MACOSX:
return new String[] { "lib" + libName + ".dylib", "lib" + libName + ".jnilib" };
case OS_TYPE_WINDOWS:
return new String[] { libName + ".dll" };
default:
throw new LinkageError("Unknown platform: " + System.getProperty("os.name"));
}
}

public static final String getLibraryPath() {

switch (OS_TYPE) {
case OS_TYPE_LINUX:
return "lib/linux";
case OS_TYPE_MACOSX:
return "lib/macosx";
case OS_TYPE_WINDOWS:
return "lib/windows";
default:
throw new LinkageError("Unknown platform: " + System.getProperty("os.name"));
}
}

}

Title: Re: OS-dependent library loading
Post by: Spezi on January 17, 2007, 16:16:11
Very nice, thank you.
But I still get "UnsatisfiedLinkError: no lwjgl in java.library.path" after setting -Djava.system.class.loader and modifying the paths.

Edit:

Ahh, my mistake, I tried to return "lib/lwjgl/native/win32;lib/qtjava" in the OS_TYPE_WINDOWS case.
With just "lib/lwjgl/native/win32" it works but how can I add more than one path?
Title: Re: OS-dependent library loading
Post by: cornholio on January 17, 2007, 16:35:32
Quote from: Spezi on January 17, 2007, 16:16:11
but how can I add more than one path?

here you go ...




package foo;

import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;


public class CustomClassLoader extends URLClassLoader {

private static final int OS_TYPE_LINUX = 1;

private static final int OS_TYPE_MACOSX = 2;

private static final int OS_TYPE_WINDOWS = 3;

private static final int OS_TYPE;

static {

String osName = System.getProperty("os.name");

if (osName.startsWith("Windows")) {
OS_TYPE = OS_TYPE_WINDOWS;
} else if (osName.startsWith("Linux") || osName.startsWith("FreeBSD") || osName.startsWith("SunOS")) {
OS_TYPE = OS_TYPE_LINUX;
} else if (osName.startsWith("Mac OS X")) {
OS_TYPE = OS_TYPE_MACOSX;
} else {
throw new LinkageError("Unknown platform: " + osName);
}
}

public CustomClassLoader(ClassLoader parent) {
super(getClasspath(), null);
}

protected String findLibrary(String libName) {

String[] libPaths = getLibraryPaths();
String[] libNames = getLibraryNames(libName);
for (int p = 0; p < libPaths.length; p++) {
for (int n = 0; n < libNames.length; n++) {
File libFile = new File(libPaths[p], libNames[n]);
if (libFile.isFile())
return libFile.getAbsolutePath();
}
}

return super.findLibrary(libName);
}

public static final URL[] getClasspath() {

String[] tk = System.getProperty("java.class.path").split(File.pathSeparator);

try {

URL[] urls = new URL[tk.length];
for (int i = 0; i < urls.length; i++) {
boolean isJar = tk[i].toLowerCase().endsWith(".jar");
urls[i] = new URL("file", "localhost", tk[i] + (isJar ? "" : "/"));
}

return urls;

} catch (MalformedURLException e) {
throw new RuntimeException("malformed classpath");
}
}

public static final String[] getLibraryNames(String libName) {

switch (OS_TYPE) {
case OS_TYPE_LINUX:
return new String[] { "lib" + libName + ".so" };
case OS_TYPE_MACOSX:
return new String[] { "lib" + libName + ".dylib", "lib" + libName + ".jnilib" };
case OS_TYPE_WINDOWS:
return new String[] { libName + ".dll" };
default:
throw new LinkageError("Unknown platform: " + System.getProperty("os.name"));
}
}

public static final String[] getLibraryPaths() {

switch (OS_TYPE) {
case OS_TYPE_LINUX:
return new String[] { "lib/linux" };
case OS_TYPE_MACOSX:
return new String[] { "lib/macosx" };
case OS_TYPE_WINDOWS:
return new String[] { "lib/lwjgl/native/win32", "lib/qtjava" };
default:
throw new LinkageError("Unknown platform: " + System.getProperty("os.name"));
}
}

}

Title: Re: OS-dependent library loading
Post by: Spezi on January 17, 2007, 16:57:50
Alright, now I get "NoClassDefFoundError: quicktime/QTException" :D
I don't even get this while starting with the usual method after deleting the additional QTJava.dll from /lib/qtjava.
So what could be wrong there?

Edit:
I also get this if I use -Djava.library.path=lib/qtjava  and the classloader with just "lib/lwjgl/native/win32".
Title: Re: OS-dependent library loading
Post by: cornholio on January 18, 2007, 13:34:04
hm ... seems like there is a problem finding 'quicktime.jar'. i played around
with QTJava and it seems to work for me even with the crappy classloader.

QTJava does some really nasty things in order to find the native libraries. just
check out the sourcecode of 'quicktime.jdirect.JDirectLinker'. for example there
is a native method for loading the native libraries:
private static native int loadNativeLibrary(String s);   ???
Title: Re: OS-dependent library loading
Post by: Spezi on January 19, 2007, 01:27:31
There is no quicktime.jar. Only QTJava.dll and QTJava.zip.
QTJava.dll is only needed on Windows and QTJava.zip is loaded into eclipse as jar-package.
Title: Re: OS-dependent library loading
Post by: cornholio on January 19, 2007, 12:16:16
you have to rename 'QTJava.zip' to 'quicktime.jar' or 'something.jar'
and make it available on the classpath (e.g. adding it to the build
path in eclipse) ...
Title: Re: OS-dependent library loading
Post by: Spezi on January 19, 2007, 13:27:03
Quote from: cornholio on January 19, 2007, 12:16:16
you have to rename 'QTJava.zip' to 'quicktime.jar' or 'something.jar'
and make it available on the classpath (e.g. adding it to the build
path in eclipse) ...

OK, I'll try this, but in past it ran perfectly in Windows with -Djava.library.path=lib/lwjgl/native/win32;lib/qtjava.
Title: Re: OS-dependent library loading
Post by: cornholio on January 19, 2007, 16:51:06
you could also change the following line


boolean isJar = tk[i].toLowerCase().endsWith(".jar");



to
         


boolean isJar = (tk[i].toLowerCase().endsWith(".jar") || tk[i].toLowerCase().endsWith(".zip"));


         
if you you want to keep offending a JAR by calling it '.zip' ...  ;)
Title: Re: OS-dependent library loading
Post by: Spezi on January 19, 2007, 17:01:42
Alright, now it's working as desired. :D
Sorry for the trouble, but since I just used the 2 files from an actual QuickTime installation and that didn't raise any problems I wanted to continue using the files as they are.

Thank you. :)
Title: Re: OS-dependent library loading
Post by: Spezi on January 19, 2007, 17:34:33
Seems I was a bit overhasty. Now there's another problem.
In the release build (not run from eclipse) I get:

Exception in thread "main" java.lang.NoClassDefFoundError: org/lwjgl/opengl/AWTGLCanvas
   at java.lang.ClassLoader.defineClass1(Native Method)
   at java.lang.ClassLoader.defineClass(Unknown Source)
   at java.security.SecureClassLoader.defineClass(Unknown Source)
   at java.net.URLClassLoader.defineClass(Unknown Source)
   at java.net.URLClassLoader.access$100(Unknown Source)
   at java.net.URLClassLoader$1.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(Unknown Source)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClassInternal(Unknown Source)


So the custom classloader is not involved at all although I added -Djava.system.class.loader=game.lwjgl.CustomClassLoader to the call.
Title: Re: OS-dependent library loading
Post by: cornholio on February 01, 2007, 02:46:52
i sent you a mail explaining what to do...
Title: Re: OS-dependent library loading
Post by: cornholio on February 01, 2007, 19:31:56
here is a new version of my CustomClassLoader. now it recursively adds JARs or folders
to the classpath which have been defined in manifest-files (MANIFEST.MF). hope you
understand what i'm talking about...

spezi: this should work with the test-case you sent me by email...



package foo;

import java.io.File;
import java.io.IOException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.LinkedList;
import java.util.jar.Attributes;
import java.util.jar.JarFile;
import java.util.jar.Manifest;
import java.util.jar.Attributes.Name;

public class CustomClassLoader extends URLClassLoader {

private static final int OS_TYPE_LINUX = 1;

private static final int OS_TYPE_MACOSX = 2;

private static final int OS_TYPE_WINDOWS = 3;

private static final int OS_TYPE;

static {

String osName = System.getProperty("os.name");

if (osName.startsWith("Windows")) {
OS_TYPE = OS_TYPE_WINDOWS;
} else if (osName.startsWith("Linux") || osName.startsWith("FreeBSD") || osName.startsWith("SunOS")) {
OS_TYPE = OS_TYPE_LINUX;
} else if (osName.startsWith("Mac OS X")) {
OS_TYPE = OS_TYPE_MACOSX;
} else {
throw new LinkageError("Unknown platform: " + osName);
}
}

public CustomClassLoader(ClassLoader parent) {
super(buildClasspath(), null);
}

public static final URL[] buildClasspath() {

LinkedList urls = new LinkedList();

String[] tk = System.getProperty("java.class.path").split(File.pathSeparator);

try {

buildClasspath(urls, tk);

} catch (IOException e) {
throw new RuntimeException("buildClasspath() error: " + e.getMessage());
}

URL[] urlArray = new URL[urls.size()];
for (int i = 0; i < urls.size(); i++)
urlArray[i] = (URL) urls.get(i);

return urlArray;
}

public static final void buildClasspath(LinkedList urls, String[] tk) throws IOException {

for (int i = 0; i < tk.length; i++) {

boolean isJar = (tk[i].toLowerCase().endsWith(".jar") || tk[i].toLowerCase().endsWith(".zip"));

if (isJar) {

File jarFile = new File(tk[i]);
if (jarFile.exists()) {

tk[i] = jarFile.getAbsolutePath();

JarFile jar = new JarFile(tk[i]);
if (jar != null) {

Manifest jarMf = jar.getManifest();
if (jarMf != null) {

Attributes jarAttr = jarMf.getMainAttributes();
if (jarAttr != null) {

String jarCp = jarAttr.getValue(Name.CLASS_PATH);
if (jarCp != null)
buildClasspath(urls, jarCp.split("\\s+"));
}
}
}

urls.add(new URL("file", "localhost", tk[i]));
}

} else
urls.add(new URL("file", "localhost", tk[i] + "/"));
}
}

protected String findLibrary(String libName) {

String[] libPaths = getLibraryPaths();
String[] libNames = getLibraryNames(libName);
for (int p = 0; p < libPaths.length; p++) {
for (int n = 0; n < libNames.length; n++) {
File libFile = new File(libPaths[p], libNames[n]);
if (libFile.isFile())
return libFile.getAbsolutePath();
}
}

return super.findLibrary(libName);
}

public static final String[] getLibraryNames(String libName) {

switch (OS_TYPE) {
case OS_TYPE_LINUX:
return new String[] { "lib" + libName + ".so" };
case OS_TYPE_MACOSX:
return new String[] { "lib" + libName + ".dylib", "lib" + libName + ".jnilib" };
case OS_TYPE_WINDOWS:
return new String[] { libName + ".dll" };
default:
throw new LinkageError("Unknown platform: " + System.getProperty("os.name"));
}
}

public static final String[] getLibraryPaths() {

switch (OS_TYPE) {
case OS_TYPE_LINUX:
return new String[] { "lib/linux" };
case OS_TYPE_MACOSX:
return new String[] { "lib/macosx" };
case OS_TYPE_WINDOWS:
return new String[] { "lib/windows" };
default:
throw new LinkageError("Unknown platform: " + System.getProperty("os.name"));
}
}

}

Title: Re: OS-dependent library loading
Post by: Spezi on February 01, 2007, 23:32:57
OK, the test case is running fine but now I stumble on the next problem: the ResourceBundle can't be found. :-\

Exception in thread "main" java.util.MissingResourceException: Can't find bundle for base name game.lang.Language, locale de
   at java.util.ResourceBundle.throwMissingResourceException(Unknown Source)
   at java.util.ResourceBundle.getBundleImpl(Unknown Source)
   at java.util.ResourceBundle.getBundle(Unknown Source)
   at game.lang.Language.getResourceBundle(Language.java:33)

I'm sure I have to add something to the manifest but don't know what.
I feel so stupid. ;D
Title: Re: OS-dependent library loading
Post by: cornholio on February 02, 2007, 00:20:31
just add the ResourceBundle ( game.lang.Language_de.properties or whatever ) to your Game.jar

here is an excellent free online-book for german java-developers:
http://www.galileocomputing.de/openbook/javainsel6/ (http://www.galileocomputing.de/openbook/javainsel6/)

Title: Re: OS-dependent library loading
Post by: Spezi on February 02, 2007, 01:55:17
Quote from: cornholio on February 02, 2007, 00:20:31
just add the ResourceBundle ( game.lang.Language_de.properties or whatever ) to your Game.jar

But it's already in there.
The Exception is thrown just about 12 seconds after launching the game. During this time nothing else appears and CPU or HD aren't used intensely.
And as before, everything runs fine starting from eclipse.
Title: Re: OS-dependent library loading
Post by: Shadowritter on January 09, 2008, 11:49:25
Hello I'm bringing back this topic cause I'm using the CustomClassLoader of Cornholio and it's working fine.

But I've tried DevIL in my project and got UnsatisfiedLinkError with DevIL fonctions (no errors when I'm writing them)

So I suppose the CustomClassLoader don't work with DevIL and I'm trying to now why or if I'm missing a little something

Any help would be appreciate.

I'm french, please excuse my english

EDIT : dammit I forgot the IL.create() fonction, problem solved sorry