First off, I've been trying to launch Eclipse but I kept getting the below error
Failed to load JNI shared library "C:\Program Files (x86)\Java\jdk1.8.0_25\bin...\jre\bin\client\jvm.dll"
So I looked through this thread
Failed to load the JNI shared Library (JDK)
The sensing I got was that I might want to uninstall Java and make sure I have the right 64 bit version, since I already have a 64 bit Eclipse.
I went ahead and went to uninstall the Java Update files via the control panel, which went fine.
Then when I tried to delete the Java files in my Program Files (x86) folder, I can't do it as the "file is being used by another process"
Now I can't install a new version of Java as I get an error code 1603 owing to the incomplete Java files, and I still got my JNI shared library error to fix.
I'm really stuck now. What do I do?
If you use 64 bit eclipse, you need a 64 bit operating system and 64 bit JDK. Close your eclipse and JDK, remove X86 JDK and install 64bit JDK.
ctrl+shift+esc open task manager and end all processes that are opened by java. Sometimes when you run java and your applications don't close properly, java run-time environment is still running. So you have to force java out of that state. Next time, i'd just install the newer version of java right on top of the old one. Because the installation process removes the old version of java for you and replaces it with the newest one.
with jframes using the code
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)
this is essential to your program so it closes completely.
Related
Couple days ago, I was happily coding away on my IDE, Eclipse. However, after attempting to boot it up today, i get the error in the title you see.
Symptoms:
- Attempting to boot up eclipse results in an error: 'Failed to load the JNI shared library "C:\Windows\system32\..\jre\bin\client\jvm.dll"'
- Attempting to use 'java -version' results in an error: 'Error: could not open 'C:\Windows\jre\lib\amd64\jvm.cfg'
- However, if I open cmd in the jre OR jdk folder, it allows me to check the version and use java as normal.
What i've done:
- double checked windows, eclipse, and jre/jdk bit versions, all 64 bit.
- reinstalled eclipse and jre/jdk, doublechecking that I'm installing 64 bit versions
- set my -vm argument to the correct jdk
- set the PATH to my current JDK bin folder
- doublechecked registry entries for something pointing towards the system32 folder, everything is pointing at the correct locations.
I'm really not sure what to do here :\ I don't remember making any changes, updating java, or modifying anything that should have caused any of these problems since the last time I had boot up eclipse.
Answer found here
For whatever reason, the java install dumped the java/javaw/javaws.exe's into system32 and it was trying to run the VM out of sys32.
I am trying to launch an application (not Eclipse) that was written in Java. When I do, I get an error that says "Failed to Load the JNI shared Library (JDK)" along with a path that points to the location of the file.
From searching Google and StackOverflow, all I can find are people saying that the Java version installed needs to match my machine. My machine is 64 bit and so is my java installation, so I don't think that is my issue.
I have also verified that C:\Program Files\Java\jre7\bin is in my path variable. Also, just for the record, I do not use Eclipse. I have also tried uninstalling and reinstalling Java an the application that was written in Java. Lastly, the file it is complaining about exists on the machine.
Does anyone know what else could be the cause of this problem?
Update:
Thanks for your responses. I got it resolved, but the resolution seems like more of a hack and goes against what I was reading earlier. I installed the 32 bit version of Java 7 along side of my 64 bit version of Java 7. I then added the path the 32 bit version to the system path variable.
After I did this, the application was able to launch. Is there an issue with having both 64 bit and 32 bit versions of Java 7 installed simultaneously?
This is an error from your application. The application uses JNI. It is complaining that it cannot load it. Why it says (JDK) only its author knows. You will have to ask the author.
There is no problem having both versions of Java installed. However, the application you were using probably shipped with a 32-bit version of the JNI library. So, it needed to be used with a 32-bit Java JRE.
After a couple of months with no Android development, I ran the SDK Manager yesterday, and upgraded from r16 to r18. After that upgrade, everything stopped working. I downloaded a fresh copy of the SDK tools from Google. The Windows installer complains there's no Java installed (the solution here , which used to work before, doesn't work).
I downloaded the ZIP file instead and put it in the right place. Running SDK Manager.EXE does nothing (it just returns immediately to the command prompt). Running tools\android.bat displays an error complaining "Failed to convert path to a short DOS path: c:\windows\system32\java.exe", and then suggests I install Java.
I'm running Windows 7 64-bit, with Java 1.7 (64 bit) properly installed (Eclipse runs well, the Android tools r16 ran very well until yesterday). c:\windows\system32\java.exe exists and works as it should.
What am I doing wrong?
UPDATE: I found an old r16 setup around. I installed it and everything went back to normal.
I put this one aside for a while, but now I had to get it back running. I didn't want to install a 32-bit Java VM alongside the 64 bit one I have.
I found the culprit. in android_sdk\tools\lib there's a batch-file called find_java.bat. It calls find_java.exe -s to find a list of potential Java locations. Running the exe file like this returns the error I've been seeing:
Failed to convert path to short DOS path: c:\windows\system32\java.exe
-s stands for short. Running it without the -s causes find_java.exe to work, causing find_java.bat to work, causing everything else to work. So the fix was to edit find_java.bat, and remove the -s .
I honestly don't know what Google is thinking.
My fix was to remove /bin from my JAVA_HOME, as in C:\Java\jdk1.6.0_26\bin --> C:\Java\jdk1.6.0_26\
I'm running 64bit java on W7.
This google issue was helpful:
http://code.google.com/p/android/issues/detail?id=23648
This is just a guess, but I advise you to install JDK 6. It is said in the SDK requirements that you have to use it. I remember that I installed JDK 7 and I had some kind of trouble with it too.
Also it is safer to use the 32-bit version.
You need to also update the Eclipse plugins via Help > Install New Software.
I was able to fix same like problem by adding the jdk path to PATH variable in environment variables.
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.