I'm developing a java application, using a 32Bit native library which I'm accessing via JNA. On MacOS X Snow Leopard it's possible to pass the parameter "-d32" to the JVM, which causes the JVM to start in 32Bit mode. I've got a launcher application, which sets some environment variables and then starts the main application. This is also the place where it is decided to launch the main application with the -d32 switch, if the program is executed on MacOS.
So here's my question: Is there a similar way to solve this on Windows or Linux?
It would be the best if it was possible to run the 64Bit JVM in 32Bit mode. But I'm not really afraid to tell my users to install an additional 32Bit JVM, that's not the problem. The problem is, that I would have to tell my launcher application where the 32Bit JVM can be found, as the first one in the PATH variable could be the 64Bit one.
Thanks in advance,
aRestless
If you bundle the 32-bit JVM with your application, it can run fully independent of any installed JRE and system path. This is allowed by Java SE 6: http://java.sun.com/javase/6/jdk-6u2-license.txt. You can also start JVM by loading jvm.dll, thus showing only your launcher image in task manager. You can even avoid writing a native launcher at all if you use WinRun4J: http://winrun4j.sourceforge.net/
Hope that helps!
Related
I'm working on a bluetooth java application under eclipse in OS X 10.10.1 Yosemite 64bit with the blue cove-2.1.0 jar. When I run the application I get the error message:
Native Library bluecove not available
Through a web search I found that the issue is caused by the 64 bit version of Java, but when I try to run the application with the -d32 argument passed to the VM I get the error:
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
Is there anyway to run this application despite the 64 bit configuration? or is there any other library despite bluecove that can manage a 64 bit environment?
A similar thing happened to me with a different java application (jruby), around which I was able to work by resetting my JAVA_HOME to a JVM that supports 32-bit mode. Essentially your 64-bit JVM is trying to tell you that it won't run in 32-bit mode, even when you specify the -d32 option.
To work around this, try running: /usr/libexec/java_home -d32
On my 64-bit Yosemite machine, that command returned /Library/Java/JavaVirtualMachines/1.6.0_65-b14-462.jdk/Contents/Home, which is the path to a JVM on my machine that will run in 32-bit mode. If you have one or more 32-bit-capable JVMs on your machine, you'll get a path to one of them, which you can then use to set your JAVA_HOME variable accordingly and you'll be off to the races.
If you don't have a 32-bit-capabile JVM on your machine, you will need to install one via the Oracle web site or homebrew and then set your JAVA_HOME accordingly.
If you want to skip a step or two, just do this -- export JAVA_HOME=`/usr/libexec/java_home -d32` -- which will automatically set your JAVA_HOME to the first detected instance of a JVM capable of running in 32-bit mode.
In my ini file for winrun4j java exe wrapper I set vm.version.min=1.7 to specify Java 7 as a requirement. But when I ran it I couldn't get winrun4j to recognise that I had a java 7 jre installed even though java -version from the command line returned it.
On further investigation I realized that my Java 7 installation was 64bit whereas my Java 6 installation was 32bit. I then found that winrun4j has some 64bit version of its commands (ie rcedit64), if I built an appname64.exe rather than appname.exe it no longer complained about Java 7.
So can someone confirm this was the issue that I need a 64bit exe to run a 64bit jvm
Secondly if this is the case how do I present this to the user, I'm wrapping the installer as an exe so does that mean I need to provide the user with both an installer.exe and a installer64.exe and explain to the user to pick the right one not based on their processor but based on what version of java they have installed32bit or 64bit)
Edit:
Sounds like things are as i described, and using launch4j maybe a solution
What's the best way to start Java applications on Windows 7?
that I need a 64bit exe to run a 64bit jvm
Yes. You can not use a 32 bit exe to run the 64bit JVM
Secondly if this is the case how do I present this to the user, I'm
wrapping the installer as an exe...
Don't. Just create an installer for a 32-bit system and a 64-bit system. Depending on the target system the corresponding installer should run
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.
I'm using Install4J mostly for it's great jar file optimization and support for pack200. The main hiccup I'm running up against is that we have several native libraries that are 32-bit only. We need to run with a 32 bit JVM for those to work, ideally dynamically downloding one and installing it when one's not there.
The case that's tricky is when there is a JVM installed above the minimum version we need, but that's 64-bit instead of 32-bit. Any way we can detect that and download and install a 32-bit JVM to run with instead?
You can bundle the 32bit JRE to installer. And instruct Install4J not to use already existing Java on user's machine but rather the one you have bundled.
I had similar problem, check Running install4j on 64bit JRE in Win.
I actually had missed the fact that Install4J already handles this. Since the launcher itself is 32 bit, Install4J requires a 32 bit JVM. So it downloads one automatically if it's not there.
On 64-bit openSUSE Linux, can a 32-bit eclipse running with 32-bit JVM compile code for a 64-bit system?
Is this setup possible? (Installing and running eclipse/java 32-bit on a 64-bit system)
If you're building pure Java, there's no such thing as compiling for a particular architecture - Java bytecode is portable across CPU architectures and 32/64-bitness.
If you want to compile another language (such as C++) then it gets a bit harder. Likewise you may find problems if you try to build JNI wrappers for one architecture on another.
When you compile in Java there is no notions of 32/64bits it's just java Bytecode. So yes, you can compile java in a 32bits environment and run it in a 64bits one.
The compiled Java program is always identical as Java runs through the Java virtual machine which handles the architecture and native calls. A Java program is not fully compiled all the way to machine code, only up to bytecode for the virtual machine. This means that a Java program can work on any architecture.
The crucial point is the JVM you choose to run Eclipse iwth and your final program.
If all your code is Java then the result can run on either. The most visible difference is the amount of memory that a program can actually use, where the 64-bit JVM allows for more than the 32-bit JVM.
As i remember there are some XUL library which depends of processor architecture.
So the way you need is emulate/virtualize eclipse environment x86 to run inside of x64 environment.
So the most expected exception should be XUL libraries error.
And one another life-hack could be switching to x64 libraries in x86 eclipse package, but its not guaranteed.
So, try to install x86 eclipse application to your environment and post here logs.
Regards
Eugene
Check answers for question Java programing for 64 bit JVM
It should not matter when you compile java code whether you compile for 32/64 bit.