so I have this project in java that uses a jni .dll i wrote (which i've aptly named jniusb) that gives access to usb-hid devices. i've been using it for several months now without any notable issues until yesterday when i tried to launch my program from the jar instead of directly from netbeans. after a little debugging i characterized my issue as follows:
clicking on the jar icon starts my program without loading the dll. displaying the error messages in my gui revealed "no jniusb in java.library.path" even though i copied my dll to the java binaries folder (which always seemed to work in the past).
i tweaked the code to find the current directory and use "System.load" (with the dll copied to the same folder as my jar) instead of "System.loadLibrary". this approach threw the error "C:\Users\bpaik\Documents\NetBeansProjects\JniUsb\dist\jniusb.dll: Can't load AMD 64-bit .dll on a IA 32-bit platform". this made me scratch my head since i am most definitely working on an AMD 64-bit platform and running out of netbeans works with the same dll...
running the jar from the command prompt (with either java.exe or javaw.exe) loads the dll just fine. i thought that maybe this meant that i was having admin privileges issues so i tested the theory by going to the java executable and granting admin privileges, but this did not change anything. (and i'm also pretty sure i've used load/loadlibrary before without admin...)
i am no java expert so i've pretty much exhausted my debugging abilities and am now hoping that someone with a little more experience than i will recognize the issue i've described, thanks.
UPDATE: so i've fixed the problem but I still have no idea what is going on. i did a x86 build of my .dll and threw it into the folder with my jar and everything loaded/worked just fine. so i guess somehow (even though i set the default program for my jar to be the x64 JVM) the jar i built with the x64 library in Netbeans is running in a 32-bit JVM. to sum things up:
my jar is built with the x64 library in netbeans and runs fine with the x64 dll when launched from the command prompt.
when launching the jar from the icon (with default program set to x64 java) my program and JVM somehow switch to a 32-bit JVM and work fine when i use the 32-bit version of my dll.
trying to explicitly run my jar with the 32-bit java doesn't work at all. my gui doesn't display and the command prompt briefly opens/closes...
Problem 2 is certainly caused by you running a 32-bit JVM. Netbeans presumably runs a 64-bit JVM. You'll need to use something like Launch4j to get the right JVM loaded (or include both a 32-bit and 64-bit version of your DLL).
From the command line, try -d32 and -d64 to test that theory out.
Do you have multiple versions of Java installed on your Machine? It appears that when you run the jar by itself, your machine is creating a 32-bit VM for it. Open an command prompt and type java -version to check which version of Java is being used.
Related
I have a C++ application that uses JNI to create a Java virtual machine. I have the latest version of Java installed - JDK 8-144. If I run "java -version" it comes up and tells me that Java Hotspot 8 is the JVM. I have JAVA_HOME defined in the .profile file, and it works -- JAVA_HOME points to the JDK8-144 folder.
My application is including jni.h from the latest JDK. Our code creates a JVM with the JNI_VERSION_1_8 version flag. On Windows, this compiles and works perfectly.
The problem is that when we compile this code on the Mac, and use the JVM Framework for linking, we end up with an executable that, when run, says that there's "No Java Runtime present" and a dialog comes up that says we need to install the Version 6 JVM. This happens if we run the application from either the Bash terminal or from XCode.
I've researched this and there are other people who have had this identical issue. Everyone seems to suggest that JAVA_HOME needs to be pointing to the correct place, and mine is. Again, java -version works correctly. The whole thing is quite puzzling.
Does anyone know the right way to solve this? I've tried two different Macs with identical results. They are both running the latest version of macOS Sierra.
Thanks!
Dan
I have a very old application (published in 2001) I am trying to get working in Windows 7/8/10. There is a setup.exe part of it that is using Java in some capacity, and not working correctly. I suspect it is using java because I decompiled the JAR file packaged with the application and there are references to several setup steps within the .java files (along with a file named setup.java). There is also a jre folder published with the application as well, running the following (dated) version:
F:\jre\bin>java -version
java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)
At first I suspected the application was using the systems environmental variables to use the currently installed version of JAVA, but I ruled that out by completely purging JAVA from the system and retesting - same results.
I next tried to simply update the folder to the latest version. As expected however, there were calls being made that were no longer supported (error message was referencing _JVM_IsVMGeneratedMethodl).
At this point I am running out of options. I could always run this application in a VM (and it works fine), but I would prefer to somehow package it in a nice streamlined way for easy distribution and install. Is there anything I can do? I was thinking something along the lines of application virtualization but still reading up on it.
It's hard to tell without "being there", but I'm guessing that the old (1.3) JVM just isn't compatible with the more modern versions of Windows.
Your best bet is probably running it against whatever version of Windows the app was originally developed on, in a VM.
If you have / can get the complete source code, you could try recompiling it with the version of Java supported on your current system. But it's probably a long-shot.
If it is containing a JRE folder, then you could skip the installer and add some batch file to launch that .jar with the specific JRE via a command of this form:
java -jar pathToYourJAR
btw, you could also consider options to convert to executable, some older are mentioned here:
How can I convert my Java program to an .exe file?
some of them may allow you to select which JRE to bundle/use
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.
We've got a GWT web app that uses JNI to call a dll. We build the dll as well. It works fine on my developer machine, which is a 64-bit Windows 7 machine, running Java 6 and running the webapps in Tomcat 6. But when we run it on the tester's VM which is running 32-bit WinXP, it errors with
java.lang.UnsatisfiedLinkError: Cannot load native JNIWrapper library (jniwrap64.dll)
at com.jniwrapper.Library.loadNativeCode(SourceFile:78)
at com.jniwrapper.Library.loadNativeCode(SourceFile:103)
at com.jniwrapper.Library.ensureNativeCode(SourceFile:113)
at com.jniwrapper.Library.load(SourceFile:189)
My JRE_HOME is set to a 32-bit version of Java 6, because I wanted the build to be able to work on a 32-bit machine, but clearly I'm mis-understanding something about how the 32 or 64-bit versions of java work in compiling the web app.
And yes, the dll that we call is built in to the .war, since it works on my machine.
I also googled the jniwrap64.dll but didn't find much that was relevant.
Added for clarification : jniwrap64.dll is not the dll that I've built, and my code is not explicitly loading this library. That's part of my confusion, is what is this library, why is it being loaded, etc. I have assumed that jniwrap64.dll is some kind of system library that needs to be installed. My code that loads our library is as follows:
Library myLib = Library(path);
myLib.load(this.getClass().getClassLoader());
When you load the dll with System.loadLibrary() do you load "jniwrap64.dll" or "jniwrap32.dll" ? Cna you show us the line of code which loads this library?