lesto
Senior Newbie 
|
 |
«
Posted
2011-10-27 01:22:36 » |
|
hi, I can't understand why this doesn't work: 1 2 3
| String jinput = System.getProperty("java.library.path")+File.pathSeparator+ new File(System.getProperty("user.dir").toString()+ File.separator+"lib" + File.separator + "dist"); System.out.println("Loading native library from: " + jinput); System.setProperty("java.library.path", jinput); |
it has worked for lwjgl (but instead of "java.library.path" was "org.lwjgl.librarypath") i've take a look in the forum, and many link directly the DLL file. I don't like this approach, as it isn't platform independent, so java loose it's greatest quality. using the -Djava.library.path with the PATH created above everything works. please tell me how solve this. thank you
|
|
|
|
endolf
|
 |
«
Reply #1 - Posted
2011-10-27 06:52:43 » |
|
The jinput plugins for each platform load the library as soon as they are loaded by the JVM (done in a static block). So if any of the classes you import in your main app, or any they import etc are jinput ones, the library is loaded before you change the library path.
The way I'd solve this is with reflection, my launcher class doesn't import anything directly to do with the rest of my game or jinput, it sets the library path, then gets the main program class from the string classname, then it constructs an instance of that and off it goes with the new library path.
HTH
Endolf
|
|
|
|
cylab
|
 |
«
Reply #2 - Posted
2011-10-27 08:17:36 » |
|
|
Mathias - I Know What [you] Did Last Summer!
|
|
|
Games published by our own members! Check 'em out!
|
|
R.D.
|
 |
«
Reply #3 - Posted
2011-10-27 09:08:10 » |
|
I usally do this likt this: 1 2
| System.setProperty("org.lwjgl.librarypath",new File(new File(System.getProperty("user.dir"), "native"), LWJGLUtil.getPlatformName()).getAbsolutePath()); System.setProperty("net.java.games.input.librarypath", System.getProperty("org.lwjgl.librarypath")); |
These are the first lines in my Main and I just copy the native folder next to ma jar (or in eclipse in the project path)  You know, JInput provides it's own Property too  (Not sure but maybe there is lacking documantation here  )
|
|
|
|
endolf
|
 |
«
Reply #4 - Posted
2011-10-27 09:31:07 » |
|
You know, JInput provides it's own Property too It does indeed, but this again would need to be set before any of the JInput classes are loaded by the JVM, which means before any class is loaded that imports them or uses them. And before any classes that import or use the classes that import or use jinput etc etc. Unless you do it via reflection or some other class loader. Endolf
|
|
|
|
R.D.
|
 |
«
Reply #5 - Posted
2011-10-27 09:52:42 » |
|
You just provide these to lines I posted in your main at the very beginning. So you don't need to use reflection  Or ist this another case of "How a programmer should handle things and how he does in in a real application?"
|
|
|
|
endolf
|
 |
«
Reply #6 - Posted
2011-10-27 09:55:57 » |
|
Like I said, jinput loads the libs up statically as the class is loaded, so anything that causes the classes to be loaded *before* the properties are set will cause JInput to not have the new value of the properties.
Imports or uses of the class in code will cause it to get loaded (at least on some JVMs if not all).
Endolf
|
|
|
|
Riven
|
 |
«
Reply #7 - Posted
2011-10-27 13:51:36 » |
|
So if any of the classes you import in your main app, or any they import etc are jinput ones, the library is loaded before you change the library path. Imports or uses of the class in code will cause it to get loaded (at least on some JVMs if not all).
Imports do *not* load the class. Imports are a language level construct and do not exists in bytecode. Classes only get loaded once they are used. AFAIK the only way a class can get loaded before the first line of the main-method, is a static block in that very same class. You can verify this by using -verbose:class
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
endolf
|
 |
«
Reply #8 - Posted
2011-10-27 13:58:51 » |
|
Importing was perhaps the wrong wording. If you use any class, except through reflection, the JVM seemed to load this, upfront, before any code was executed. I'm guessing it was just an optimisation that was done, preloading all the classes it knew about. The only way round this was to create a wrapper class with a main that changed the property values, and then using the thread context class loader, to load the main class of the program from it's string name. This meant that the JVM did not preload the JInput classes and did not execute their static blocks *before* the properties were set.
Endolf
|
|
|
|
Riven
|
 |
«
Reply #9 - Posted
2011-10-27 14:19:34 » |
|
I've never seen the JVM load classes upfront.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
Games published by our own members! Check 'em out!
|
|
R.D.
|
 |
«
Reply #10 - Posted
2011-10-27 15:28:21 » |
|
Like I said, jinput loads the libs up statically as the class is loaded, so anything that causes the classes to be loaded *before* the properties are set will cause JInput to not have the new value of the properties.
Imports or uses of the class in code will cause it to get loaded (at least on some JVMs if not all).
Endolf
Don't get me wrong, I know what you mean but where is the problem in setting the first two lines of code in Main to the ones I posted? I want to be "loaded" anyway so why not doing this?
|
|
|
|
endolf
|
 |
«
Reply #11 - Posted
2011-10-27 17:14:22 » |
|
It's just the order that things get done. I found that the classes were getting loaded and the static methods called before the main was executed, so changing the values of properties in the main method had no effect.
Endolf
|
|
|
|
endolf
|
 |
«
Reply #12 - Posted
2011-10-27 17:20:21 » |
|
In java 1.6.0_23 on windows it does not seem to load the classes up front like it used too. So feel free to ignore everything I've said if you are aiming at 1.6+  Endolf
|
|
|
|
Riven
|
 |
«
Reply #13 - Posted
2011-10-27 18:37:32 » |
|
In java 1.6.0_23 on windows it does not seem to load the classes up front like it used too. So feel free to ignore everything I've said if you are aiming at 1.6+  Which version did?
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
endolf
|
 |
«
Reply #14 - Posted
2011-10-27 18:48:12 » |
|
What ever it was I tested a few years back, no idea which version. I don't have old jdks installed to try  Endolf
|
|
|
|
lesto
Senior Newbie 
|
 |
«
Reply #15 - Posted
2011-10-27 19:37:59 » |
|
maybe your main class was extend (like mine) another class with global jinput's class. maye this is why static setting isn't working. Now I'm going to put the main in another class (with the static classpath set and everything). lets see if this does the trick. BTW linux 32bit and oracle JVM 1.7
edit: haven't changed main but tested "System.setProperty("net.java.games.input.librarypath", jinput);" in static, and everything works now! thanks!
|
|
|
|
Riven
|
 |
«
Reply #16 - Posted
2011-10-27 19:50:17 » |
|
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
ra4king
|
 |
«
Reply #17 - Posted
2011-10-27 20:42:44 » |
|
That could solve a lot of our pain!!!
|
|
|
|
|