I'm trying to use JVLC but I can't seem to get it work. I've downloaded the jar, I installed VLC and passed the -D argument to the JVM telling it where VLC is installed. I also tried:
NativeLibrary.addSearchPath("libvlc", "C:\\Program Files\\VideoLAN\\VLC");
with no luck. I always get:
Exception in thread "main"
java.lang.UnsatisfiedLinkError: Unable
to load library 'libvlc': The
specified module could not be found.
Has anyone made it work?
You can get that exception if the dll you are trying to load requires other dlls that are not available. Sorry I can't be of more specific help, but it is something to check out. You can use depends to walk the dll dependancies.
Not sure about that NativeLibrary class. Typically when using native libraries, you need to set the system property, "java.library.path", to the location of your native libraries. As suggested, if your native library (dll, so, etc) depends on additional native libraries then the OS will takeover to resolve these dependencies. The OS will have no clue about java.library.path and beging by searching the OS specific path for native libraries. On windows this includes the current PATH environment variable as well as System32 in the windows directory. On linux this is the LD_LIBRARY_PATH / ld.conf setup.
Try setting the PATH (LD_LIBRARY_PATH) to point to the same location as java.library.path. The only catch is that you can't set this one your process launches (the JVM), it's already too late. You need to have the environment set BEFORE the JVM launches. You can do this vis batch files, shell scripts, Ant, or directly from your IDE.
I had the same problem too and I noticed that it occured only with 64-bit jdk/jre.
Works like charm with 32-bit jdk under Win7 x64.
Have a nice coding!
-Sipe
You should try
System.load("C:\\Path\\To\\libvlc.dll");
at least to verify that your library can be loaded.
And if not, it may give you useful error messages (it did for me).
(And as Sipe mentioned, you may be using a 64 bits JRE/JDK, in which case libvlc will never be found (it's 32 bits only). In this case you must switch to using a 32 bits JRE/JDK.)
Related
Im running Java 1.8.0_065 (64 Bit) on Windows 10 (64 bit). I've downloaded the latest cmake version (3.4.0-rc2) for windows and the latest VTK sources (6.3.0). I generated a VS2015 solution via cmake and set up everything (seemingly!!) successfully using this tutorial:
https://www.particleincell.com/2011/vtk-java-visualization/
When I try to run the DemoJavaVTK.java which is provided by the tutorial I get linker errors in IntelliJ. (14.1.5) At apperently every VTK library that has to be loaded there is the same error:
java.lang.UnsatisfiedLinkError: C:\Program Files\VTK\bin\ANY_VTK_DLL.dll: Can't find dependent libraries at
java.lang.ClassLoader$NativeLibrary.load(Native Method) at
java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1938) at
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1854) at
java.lang.Runtime.loadLibrary0(Runtime.java:870) at
java.lang.System.loadLibrary(System.java:1122) at
vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:223) at
vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:158)
at sample.DemoJavaVTK.(DemoJavaVTK.java:54) at
java.lang.Class.forName0(Native Method) at
java.lang.Class.forName(Class.java:264) at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:122)
Mind that ANY_VTK_DLL is just a placeholder. Concrete examples would be: vtkViewsContext2DJava.dll or vtkRenderingVolumeOpenGLJava.dll.
The path should be correct. All the "versions" are 64 bit. I compiled VTK for 64 Bit. I'm running a 64 bit OS with 64 bit java.
The wierdest thing is: Using eclipse everything works fine and I can run the VTK-demo without any problems. Also I'm using VTK for a course at my university, I'm working on my project with a colleague who has the same java and intellij version. He also used the same tutorial to set up VTK/Java. And the example also works in IntelliJ for him. The only difference I can tell between his and my system is, that he is using Windows 8.1 and I am using windows 10.
I really don't know where to continue from here. What is IntelliJs problem?
Got it fixed out of pure randomness by manually setting the JRE via the Run-configurations:
http://puu.sh/l3315/7c1d5e3393.png
Why does this work?
Update:
The UnsatisfiedLinkError denotes that the Java Virtual Machine (JVM) cannot find an appropriate native-language definition of a method declared as native. Specifically, in order to find the required native library, the JVM looks in both the PATH environment variable and the java.library.path system property. (Got from this article)
I used to have this kind of problems mostly because two causes:
The native librarie cannot be found (i.e don't exist)
The library being linked is not the same (Debug vs Release, 32 bit
vs 64 bit, VC10 vs VC9, etc.)
The library is already loaded by your application and the application tries to load it again
The native library is present either in the java.library.path or in the PATH environment library of your application
In order to be sure to whom library you are linking use Dependency Walker. Using this tool will make you understand what's wrong by telling you to which native libraries you are linking to.
Download the tool and then open C:\Program Files\VTK\bin\ANY_VTK_DLL.dll to see to which library it's linking to and where they are in your machine. Then make sure that IntelliJ can find these paths.
Here is a good tuto on how to use this tool: http://www-archive.mozilla.org/quality/help/dependency-walker.html
If they are the correct ones, verify the class path that IntelliJ Idea uses to launch your application to check that the native libraries are there.
I could run using,
System.setProperty("vtk.lib.dir", YourBuildVTKLibPath);
I am new using VTK, took me a while to fix this, I am using eclipse ,
I added to the PATH environment variable the dll folder and the lib folder
My Java Application has JNI dll to be loaded at the beginning and we are using system.load() to load DLL with its full path. We have compiled the Java code with 64 bit JDK and dll we are trying to load is also compiled as 64 bit.
When i try to launch the Java application using java.exe at c:\windows\system32, it is successful in launching the application and when i try to launch the same Jar using the java.exe which is located in installed location i.e., %programfiles%\java\jre7\bin then it is failing with error "UnsatisfiedLinkError: The specified procedure could not be found".
Can anybody explain the difference between java.exe available in c:\windows\system32 and at installed location?
There is no difference between the two executables; They are one and the same. Your problem is your DLL location relevant to where you start the Java Environment.
The property java.library.path needs to modified to point to where your DLL is located. You can alter this property by passing -Djava.library.path=
Finally my problem is solved.
Actual problemis with libxml2. my applicat9on has dependency on libxml2. JRE 1.7.07 onards started using libxml2 and shipped into JRE location. hence there is conflict between different libxml2 DLLs. I have modified the application to load libxml2 dynamically and removed dependency.
I know JMF is pretty much dead and whatnot, but I do know that it can still be used.
I intend to use it for personal uses and don't expect that much from it.
I have managed to install the 32bit JMF and when I run JMStudio it somehow magically works even though all of my java jres and sdks are 64-bit.
I personally believe that this proves that it CAN work.
When creating a program importing the jmf.jar as a library, my code compiles perfectly.
Only at runtime do i get any form of error with the common:
Exception in thread "VFW Request Thread"
java.lang.UnsatisfiedLinkError: JMFSecurityManager:
java.lang.UnsatisfiedLinkError: C:\Program Files
(x86)\JMF2.1.1e\lib\jmvfw.dll: Can't load IA 32-bit .dll on a AMD
64-bit platform
Obviously there is a problem with using a 32bit dll on a 64bit system.
My question is if its not compatible:
how does JMStudio work perfectly fine (it definitely uses java)
how can I fix it so that my program can run without depending on this dll
or other workarounds
Thanks a ton to anyone who has ever tried this before.
Java is definitely lacking in native specific tools such as webcams.
I think the main issue is the 64bit Java JRE/JDK trying to use the 32bit JMF, and/or JMF having a problem with the path that Windows 7 chooses as a default to install it to.
I have had success following the instructions posted here:
Oracle Forums: Install JMF on Windows 7 64bit
It basically boils down to:
Install a 32bit JRE/JDK, and ensure that this is what your code uses.
Install JMF to simple directory in the root of C: (i.e. c:\JMF2.1.1e)
Good luck!
JMFStudio is 32 bit supporting software so we must install 32bit support JDK and also Eclipse then we not get any exceptions as you mentioned in above and errors.
For my case it works fine.
and also
Try to remove unused jdk path in environment variable, if duplicate path present then also it not works fine
other wise you should re-install OS.
First of all I program in Netbeans IDE on Windows 7 x64.
I am using a java native library with dll's.
I was implementing the librarys in Netbeans and everything works fine!
But when I compile the project and try to run it via the command prompt "java -path/file.jar"
I am getting errors like: java.lang.UnsatisfiedLinkError. Can't load library
I could fix that by loading the dll in the program either with System.loadLibrary("WiiUsej") where i have to put the dll in the system32 folder
or by System.load("path/WiiUseJ.dll"). My goal anyway is to load the dll's from the same folder where the .jar file is. Does anybody know how this works?
The next problem is that after including the dll i get an error when i try to run the program on my 64 bit machine. Can't load IA 32-bit .dll on a 64 bit platform.
I was checking already for a solution on the internet which was saying i have to install a java 32 bit client.
I did that and ran it via "java -path/file.jar -d32"
Error: This Java instance does not support a 32-bit JVM
Maybe the solution is quiet simple but I was checking for hours on the internet and I am desperate! I dont get why it works when I run it in Netbeans and not in via the console.
Best regards
Make sure you start the 32 bit java.exe, not the (default) 64 bit one.
I expect that you are still using the 64 bit JVM. Run this command in the same shell that you are trying (and failing) to launch your application.
java -version
This will tell you which version of Java you are actually running.
If you are seeing the 64-bit one, you either need to change your shell's %PATH% variable, or use the full pathname for the 32-bit Java executable.
I am JUST getting started with Xuggle and I downloaded everything into Eclipse and I included them in them in the Referenced Libraries but I made a really simple test,
package com.xuggle.xuggler.demos;
import com.xuggle.xuggler.IContainer;
public class getContainerInfo {
public static void main (String [] args){
IContainer myContainer = IContainer.make();
}
}
and it throws a bunch of errors,
2011-06-12 16:26:52,142 [main] ERROR com.xuggle.ferry.JNILibraryLoader - Could not load library: xuggle-xuggler; version: 3; Visit http://www.xuggle.com/xuggler/faq/ to find common solutions to this problem
Exception in thread "main" java.lang.UnsatisfiedLinkError: no xuggle-xuggler in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1734)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at com.xuggle.ferry.JNILibraryLoader.loadLibrary0(JNILibraryLoader.java:265)
at com.xuggle.ferry.JNILibraryLoader.loadLibrary(JNILibraryLoader.java:168)
at com.xuggle.xuggler.XugglerJNI.<clinit>(XugglerJNI.java:19)
at com.xuggle.xuggler.IContainer.<clinit>(IContainer.java:1457)
at com.xuggle.xuggler.demos.getContainerInfo.main(getContainerInfo.java:9)
Below is what I've found. There is confusion because as of Xuggler 5.2 and greater, you don't need to install it and set the environment variables.
When looking at the web for answers, you may be confused by finding a mixture of steps from old and new versions. The steps from (B) below, no longer apply.
I myself finally fixed the problem by making sure the jar was in the J2EE containers lib, and upgrading from Xuggler 5.2 to 5.4. Thereafter, the link error was gone.
(A) THIS APPLIES TO ALL VERSIONS
From the Xuggler Docs:
Using Xuggler with J2EE Containers
Xuggler contains Native Code and therefore requires special installation with J2EE containers such as Tomcat, Jetty or Glassfish. It must be installed in a location where the J2EE container loads it, rather than a specific web application (unless you can guarantee that your application is the only application in the server that will load Xuggler). You will have to look up the specific documentation for your specific container, but as an example, for Tomcat make sure you install xuggle-xuggler.jar file to $CATALINA_HOME/shared/lib. See tomcat JNI notes for the reason why.
(B) THIS APPLIES ONLY TO XUGGLER PRE 5.2
From: Xuggler Faq:
What's up with java.lang.UnsatisfiedLinkError?
It means that Java can't find the Xuggler native library. Check the following:
Did you install the Xuggler?
If not, follow the instructions here
Is the environment variable XUGGLE_HOME defined and pointing to your Xuggler install directory (usually C:\Program Files\Xuggle on Windows or /usr/local on Linux/Mac)?
If you installed on Windows, did you reboot after you installed?
Does your PATH environment variable include %XUGGLE_HOME%\bin on Windows or $XUGGLE_HOME/bin on Linux/Mac?
Does your PATH environment variable include %XUGGLE_HOME%\lib on Windows?
Does your LD_LIBRARY_PATH environment variable include $XUGGLE_HOME/lib on Linux?
Does your DYLD_LIBRARY_PATH environmentvariable include $XUGGLE_HOME/lib on Mac OS-X?
Are you using a 32-bit Java JVM, but a 64-bit version of Xuggler? Or a 64-bit version of the Java JVM but a 32-bit version of Xuggler? Unfortunately that won't work. You need to make sure that you match the "bitness" of each release. Sorry.
If fixing those problems doesn't resolve the issue, please contact us via the Support options.
The issue was that I didn't reboot. Mtyson included this in his answer, so he's correct.