Hey I am making a game in java using slick and run into all these errors. It works on my friend's computer but not on mine. I've tried on both mac and pc.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1119)
at org.lwjgl.Sys$1.run(Sys.java:73)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:95)
at org.lwjgl.Sys.<clinit>(Sys.java:112)
at org.lwjgl.opengl.Display.<clinit>(Display.java:135)
at Game.start(Game.java:37)
at Main.main(Main.java:5)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
What does above exception mean??
I do have it in my class path.
The error message explains it all, you dont have a LWJGL on your classpath. You need to install it so as to get it working on your system.
Also you need to point the jvm to the location where the native files are located using a command line parameter -Djava.library.path="path/to/natives". JarSplice is an alternative to this
You may check this for details
The lwgjl native library cannot be found and loaded. Set the path to the folder where lwjgl.dll (if on Windows, on Mac probably liblwjgl.so) is located, with -D, for instance
java -Djava.library.path=C:\Java\ljwgl\libs com.mypackage.MyProgram
The library files must have a permission to be executed. Some computers may be configured to suppress any execution from USB stick so check.
If still does not work, try to call System.load(String fullFilePath) from your code, pointing to the location where the file clearly exists. If this works at the end, you can use this function to load library without name alterations and path assumptions. If does not, it may be wrong achitecture (64 vs 32 bit, permission problems (not executable) or the library file is just broken.
Related
I'm trying to setup a new project in IntelliJ using LWJGL version 3. I just tried out this example: Whenever I try to run it,
I get a java.lang.ExceptionInInitializerError caused by a java.lang.NullPointerException while loading the library.
My natives are in project_root/lib/lwjgl/native/macosx/x64, so my vm argument is:
-Djava.library.path=lib/lwjgl/native/macosx/x64
I have also added lwjgl to the classpath.
The stack trace is:
Exception in thread "main" java.lang.ExceptionInInitializerError
at test.HelloWorld.execute(HelloWorld.java:18)
at test.HelloWorld.main(HelloWorld.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: java.lang.NullPointerException
at org.lwjgl.LWJGLUtil.loadLibrarySystem(LWJGLUtil.java:326)
at org.lwjgl.Sys$1.run(Sys.java:36)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:33)
... 7 more
The solution is to specify an absolute path for java.library.path, rather than a relative one.
On the LWJGL forums, there was a user with a similar problem (I found this by searching for the problematic line and doing some hunting on the forum). The relevant part of the conversation is:
lightbringer writes:
I think I figured it out. In LWJGLUtil.java I took out some code and ran it from my main()`. I got an
java.lang.UnsatisfiedLinkError: Expecting an absolute path of the library: lib/native\lwjgl.dll`
inside loadLibrary(). System.load() apparently needs an absolute path but you are passing it a relative path.
I tested with -Djava.library.path=E:\Dropbox\private\projects\solariad\redist\lib\native and this indeed did work as expected.
The root of the issue is LWJGL's use of System.load(), which is not problematic in itself, but it does requires an absolute path name to the libraries it loads (see source as well).
If you take a look at LWJGLUtil.java (although the version at the time of this writing does not correspond exactly to your stack trace) and Sys.doLoadLibrary(), you can see that it attempts to load libraries by going through all the path strings in java.library.path, appending the library name, and trying System.load() on those paths. Since load() requires an absolute path the implication is that java.library.path must contain the absolute path to the LWJGL libraries as well.
It is unfortunate that the root cause of the problem was muddled by the NPE but, you know, it's a hard knock life for us poor programmers!
I'm developing an application that makes use of libjahspotify. The program is running on my desktop (Windows 7), when attempting to run it on my laptop (Windows 8.1) or on my other Intel NUC (Windows 7) I am getting the below error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\temp\jahspotify.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1814)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1083)
at jahspotify.JahSpotifyNativeLoader.<init>(JahSpotifyNativeLoader.java:90)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:438)
at jahspotify.impl.JahSpotifyImpl.<clinit>(JahSpotifyImpl.java:730)
at jahspotify.services.JahSpotifyService.initialize(JahSpotifyService.java:56)
at jahspotify.services.JahSpotifyService.getInstance(JahSpotifyService.java:26)
at jahspotify.services.JahSpotifyService.initialize(JahSpotifyService.java:39)
at net.functionseven.divicantus.spotify.Spotify.init(Spotify.java:29)
at net.functionseven.divicantus.Divicantus.main(Divicantus.java:20)
The native-jar in libjahspotify is supposed to load the dlls automatically, but does not. At this point it seems that jahspotify.dll is not loading. If I manually copy jahspotify.dll to the folder the native-jar will delete it, as its supposed to.
I've recompiled libjahspotify several times and checked it multiple times that both java and the dlls are x86. I've also attempted to load it manually with System.load(), I get a similar error like below.
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: C:\temp\jahspotify.dll
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1083)
at net.functionseven.divicantus.Divicantus.main(Divicantus.java:24)
I'm at a loss to what is happening.
Most likely cause is that second system is missing some dlls that jahspotify.dll requires. You can check which dlls are required with Dependency Walker (http://www.dependencywalker.com/) and try manually putting these alongside jahspotify.dll. Commonly missing DLLs are from c++ redistributable packages and such.
Whenever I try to run a Java program using LWJGL, I end up with this error or some permutation of it:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl
in java.library.path at
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at
java.lang.Runtime.loadLibrary0(Runtime.java:845) at
java.lang.System.loadLibrary(System.java:1084) at
org.lwjgl.Sys$1.run(Sys.java:73) at
java.security.AccessController.doPrivileged(Native Method) at
org.lwjgl.Sys.doLoadLibrary(Sys.java:66) at
org.lwjgl.Sys.loadLibrary(Sys.java:95) at
org.lwjgl.Sys.<clinit>(Sys.java:112) at
org.lwjgl.opengl.Display.<clinit>(Display.java:135) at
org.newdawn.slick.AppGameContainer$1.run(AppGameContainer.java:37) at
java.security.AccessController.doPrivileged(Native Method) at
org.newdawn.slick.AppGameContainer.<clinit>(AppGameContainer.java:34)
at com.mojang.mojam.giraffe.Game.main(Game.java:220)
I have tried entering
-Djava.library.path="/Users/marcus888/Downloads/Giraffemacka/natives/" when running from commandline, but it still doesn't work. Help?
By the way, this doesn't have anything to do with the code of the program in question; this error happens for even full Java games like Minecraft.
To fix the java.lang.UnsatisfiedLinkError in LWJGL:
use this piece of code:
System.setProperty("org.lwjgl.librarypath", "\lib_folder");
replace "\lib_folder" with your natives/library's folder
I don't believe your path should be quoted there. Try using:
-Djava.library.path=/Users/marcus888/Downloads/Giraffemacka/natives/
For lack of mentioning which platform you are on and I realize this is an old post but I just had the same issue and resolved it so I wanted to add. I'm using windows, I had to copy and paste the filepath that the DLL files were actually in and that fixed it. It had to be exact including the drive letter for me to get it to work. so in my case it was (not under my main user path) "e:\LWJGL\lwjgl-2.9.3\natives\windows" (excluding the quotes unless you have spaces). Now it works fine.
I've looked through a number of the UnsatisfiedLinkError threads on here and nothing seems to quite fit my problem.
I am trying to get this api working: 7ZipBind
However I am having an issue, and cant get the thing to work. I am running some of its example code from the commandline like so:
C:>java -classpath
"/sevenzipTest.jar;/sevenzipjbinding-AllWindows.jar;\sevenzipjbinding.jar"
com.poc.sevenzip.SevenZipSimple c:\archive\test.zip
However when I try to run it I get the error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: D:\Users\XXXX\AppData\Local\Temp\SevenZipJBinding-9640553\lib7-Zip-JBinding.dll: Can't
find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at net.sf.sevenzipjbinding.SevenZip.initSevenZipFromPlatformJARIntern(SevenZip.java:428)
at net.sf.sevenzipjbinding.SevenZip.initSevenZipFromPlatformJAR(SevenZip.java:235)
at net.sf.sevenzipjbinding.SevenZip.ensureLibraryIsInitialized(SevenZip.java:578)
at net.sf.sevenzipjbinding.SevenZip.openInArchive(SevenZip.java:567)
at com.poc.sevenzip.SevenZipSimple.runZip(SevenZipSimple.java:25)
at com.poc.sevenzip.SevenZipSimple.main(SevenZipSimple.java:64
What I am confused about, is why it says it cant locate the libraries (dll files), when the libraries are stored within the <file_path>/sevenzipjbinding-AllWindows.jar file... I am obviously not doing something correct here, and was hoping some1 can give me some pointers.
Cheers
The bug fix was released. Please, use version 1.06rc or above.
Download URL:
All versions
4.65-1.06rc-extr-only
The following instructions are for Windows x86 and 7 Zip JBinding version 4.65-1.05 RC. Download the following DLLs.
libstdc++-6.dll
libgcc_s_dw2-1.dll
gpsvc.dll
sysntfy.dll
Add the DLLs into the Windows-x86 directory in sevenzipjbinding-AllPlatforms.jar. Then append the following lines to sevenzipjbinding-lib.properties in the Windows-x86 directory in the jar.
sevenzipjbinding.libname.3=gpsvc.dll
sevenzipjbinding.libname.4=libgcc_s_dw2-1.dll
sevenzipjbinding.libname.5=libstdc++-6.dll
sevenzipjbinding.libname.6=sysntfy.dll
Instead of modifying the jar file, one could put the DLLs in the PATH (not classpath).
In order to figure this out, I extracted lib7-Zip-JBinding.dll from sevenzipjbinding-AllPlatforms.jar. I then opened the file in Dependency Walker.
I'm trying to call JDIC from my application, but I can't get it to run. What files do I need and where? From what I've been able to gather from their site, I basically need to put jdic.jar in classpath... however there is also a lib folder with jdic.jar with a bit different size, and jdic_native_applet.jar, jdic_stub_unix.jar, jdic_stub_windows.jar and several folders with what I gather are platform specific files.
I get this exception when instantiating AssociationService:
java.lang.ClassNotFoundException: org.jdesktop.jdic.filetypes.internal.AppAssociationReaderFactory_windows
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at org.jdesktop.jdic.filetypes.AssociationService.<init>(Unknown Source)
at QuickTest.main(QuickTest.java:101)
I've tried last "official" release and last alpha release. I'm running Java 6 and Win7 64bit. Does JDIC even work under Win7 (or 64bit, although I use 32bit Java)? I see no release after 2006, and no activity in the project after about 2008... while Win7 came in 2009.
I know that parts of JDIC, like Desktop, were included in Java 6, however that doesn't seem to be the case with file associations.
And if it doesn't, are there any (hopefully cross-platform) alternatives for managing file associations? There are some things for Windows only that I tried, but that requires running native commands with administrator privileges which I don't know how to pull, apart from asking user to run my app as administrator and then use Runtime.exec()...
If there are no alternatives to JDIC, I'm interested if anyone has managed to handle file associations well with cross-platform installers?
UPDATE: OK, figured part of it... everything from windows folder needs to be in root folder. However now I get this exception which brings me back to my original question:
Exception in thread "main" java.lang.UnsatisfiedLinkError: D:\Sources\TheWorkspace\Test\jdic.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at org.jdesktop.jdic.init.JdicManager$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.jdesktop.jdic.init.JdicManager.loadLibrary(Unknown Source)
at org.jdesktop.jdic.filetypes.internal.WinRegistryWrapper.<clinit>(WinRegistryWrapper.java:36)
at org.jdesktop.jdic.filetypes.internal.WinRegistryUtil.isSubKeyExist(WinRegistryUtil.java:192)
at org.jdesktop.jdic.filetypes.internal.WinRegistryUtil.isFileExtExist(WinRegistryUtil.java:910)
at org.jdesktop.jdic.filetypes.internal.WinRegistryUtil.isFileExtExist(WinRegistryUtil.java:939)
at org.jdesktop.jdic.filetypes.internal.WinAppAssociationReader.isFileExtExist(WinAppAssociationReader.java:163)
at org.jdesktop.jdic.filetypes.AssociationService.getFileExtensionAssociation(Unknown Source)
at QuickTest.main(QuickTest.java:103)
Can you recheck the java you are using to run this? The error typically occurs when trying to load a 32-bit dll from a 64-bit java. jdic does work for us on 64-bit Windows 7 with 32-bit java.