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
Related
I created Software Project in java Netbeans 8 and running on JDK 8.My Operating System is 64 bit.And My client Machine running on Windows xp 32 bit operating system.Would it work in xp if i made exe ?
What is appropriate Java Platform in Windows XP?
None really. Read this: https://www.java.com/en/download/faq/winxp.xml which explains why Oracle no longer supports Java on Windows XP.
Now you can probably find older versions of Java that will run on Windows XP, but you won't be able to get (reliable) security patches any more, either for the OS or for Java.
Would it work in xp if i made exe ?
It probably wouldn't. For a start, many of the ways to turn Java code into an exe do it by embedding a JRE inside the exe!
Do yourself a favour and upgrade to a PC with a more up-to-date Windows operating system. Or install Linux on it ... for free.
You can still install the Java 8 version in windows XP. When you generate the exe file, try to generate with 32bits.
You can do it with Launch4j for example.
I need to run java in 32 bit mode under windows 8.1 64 bit.
I have installed java 7 jre under c:\Program Files\Java\jre7 (64bit JVM) and under c:\Program Files (x86)\Java\jre7 (32bit JVM).
However, if from cmd I issue java -d32 -version, I get this error:
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
Without the -d32 switch it confirms its running the 64 bit JVM:
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
So I opened the java control panel and added the 32bit JVM to the user installed JRE (system tab does not allow me to change anything even if running as administrator), but nothing changes.
I've read some posts of users saying that with java 7+ the -d32 mode should be supported but I can't get it.
Note: Please note that I cannot remove the 64bit JVM because I need it for other applications
According to this FAQ :
How do I select between 32 and 64-bit operation? What's the default?
The options -d32 and -d64 have been added to the Java launcher to
specify whether the program is to be run in a 32 or 64-bit
environment. On Solaris these correspond to the ILP32 and LP64 data
models, respectively. Since Solaris has both a 32 and 64-bit J2SE
implementation contained within the same installation of Java, you can
specify either version. If neither -d32 nor -d64 is specified, the
default is to run in a 32-bit environment. Other Java commands
(javac, javadoc, etc.) will rarely need to be executed in a 64-bit
environment. However, the -d32/-d64 options may be passed to these
commands and then on to the Java launcher using the established -J
prefix option (eg: -J-d64).
All other platforms (Windows and Linux) contain separate 32 and 64-bit installation packages. If both packages are installed on a
system, you select one or the other by adding the appropriate "bin"
directory to your path. For consistency, the Java implementations on
Linux accept the -d64 option.
I've found another solution to that.
By using launchj4 I can wrap my jar into an exe and I can specify the JRE I want to use and force it to search for a 32bit JVM, set min and max version etc (see the JRE).
The wrapper will automatically search installed JRE's and chose the one that meets the requirements.
Also wrapping my jar into an exe is more convenient for deploying my application.
You can have both 32bit and 64 bit installed on the same machine. Infact you can have multiple version of each of 32bit and 64bit installed (eg - java6 and java7). Because each JRE will be installed in different folders, it usually does not matter.
When running different versions of jre, your application will search for the Java executable using the PATH variable. So if Java 32bit is first on the PATH, you will have problems running a Java 64bit application. You can modify the path to use a certain Java version e.g. by defining a environment variable JAVA32HOME with the value C:\java\java6 (32bit) and change the command to
%JAVA32HOME%\bin\java ...
Or you can manually add the version you want to use, first in the PATH variable. Remember the first instance of java.exe found while searching your PATH will be the one that is executed.
Why don't you just install the 32-bit version of Java as well from the link below:
Java Downloads for All Operating Systems
Consider going to your settings , choosing your active profile then click on advanced settings , now on the menu that pops up and choose the version you would like to work with . Once everything is configured use the terminal to verify the usage of the right version. Now incaqse thus pdate-alternatives --config java. through the terminal and update any values by selecting the version you like and pressing down on the enter key on the output you get
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.
I'm using Launch4J to start my Java application and if an x64 JRE is present on the system, Launch4J seems to prefer it.
Unfortunately my application cannot run on a 64 bit JVM because I'm loading a 32 bit DLL, which is not possible and leads to an UnsatisfiedLinkError.
Is there any way to force/trick Launch4J to use a 32 bit JVM only?
I have exactly the same problem : Into 64 bits environment if both 32 ans 64 bits JDK/JRE are installed this tools always detect the 64 bits version.
I have patched the source (java + C++) code to make my own version and re-compile all. I add a check box to FORCE the 32 bits JDK/JRE detection into 64 bits windows environment.
Just donwload the version and use it as the original one.
Version : launch4j-3.0.2-win32_Java32bitsDetection
I had this exact problem about a year ago, using Lauch4J to wrap a small Java program that required a 32-bit DLL (swt-win32.dll, as it happened).
I found that if there were 32-bit and 64-bit JVMs installed, Launch4J would always favour the 64-bit one. It would only work if the 64-bit JVM was uninstalled, which was obviously not a practical solution.
I found no way of getting Launch4J to prefer (and require) the 32-bit JVM, after searching quite a bit and posting questions on its forum.
Therefore, I evaluated a good number of alternative JRE converters (I used this list: http://www.excelsior-usa.com/articles/java-to-exe.html).
I ended up settling on Jar2Exe, which was the only one that had the features I needed. It's not free, though there is an evaluation version, and I think it wasn't expensive.
Hope this helps!
I don't know Launch4J, but you can get the Information about 32/64 by reading System.getProperty("os.arch");. If you encounter a 64-bit system you may quit the installer with a nice message, to tell the User to install a 32-bit JVM.
You may Wrap your startUp-Code with an Wrapper to show a Message-Box to the user.
public static void main(String[] args]){
String architecture = System.getProperty("os.arch");
// Did not test the return value of this property,,but should work
if("64".equals(architecture)){
// Show a dialog, or print a logmessage
System.exit(-1);
}
// Start my APP
com.something.startup.main(args);
}
If you don't mind including a copy of JDK with your app, try passing these arguments (in the MyApp.ini) to launch4j:
-D32 -Djava.home=d:\MyApp\JDK32 -Djava.ext.dirs=d:\MyApp\JDK32\jre\lib\ext
There are also other things going on here that you could use:
If you don't package the JRE, you can set the Launch4j option to use "jreOnly" and then, using the DOS environment variable called "%ProgramFiles%" you can locate the 32-bit or the 64-bit JRE in the expected location, depending on whether you used the SysWOW64 32-bit cmd.exe shell or the regular 64-bit shell. Then you can pass these options to the JVM:
-D32 -Djava.home=%ProgramFiles%\Java\JREDIR -Djava.ext.dirs=%ProgramFiles%\Java\JREDIR\lib\ext
or
-D32 -Djava.home=%ProgramFiles(x86)%\Java\JREDIR -Djava.ext.dirs=%ProgramFiles(x86)%\Java\JREDIR\lib\ext
I encountered the same problem some time ago and forked the project, so that the User interface exposes an option to force that a 32bit JVM ought to be found, you can grab the installer of launch4j 3.0.3 with the patch from:
http://fbergmann.github.io/launch4j/files/SetupLaunch4j_3.0.3.exe
and read more here:
http://frank-fbergmann.blogspot.de/2012/11/launch4j-for-32bit.html
http://fbergmann.github.io/launch4j/
This is an old question and Launch4J has been updated since it was asked. Now there is a dedicated user-interface control for selecting which version of the JVM to prefer.
The options currently are:
64-bit only
First 64-bit, then 32-bit
First 32-bit, then 64-bit
32-bit only
The last, one of course, is exactly what the OP requested.
For any users of Launch4j applications like Areca that get stung by this one, and need a quick work around, look in the directory where the application is launched and you will find a complete java command line to run your program inside a file named launch4j.log. Just make a bat file or script using the java vm you prefer and run it with the full command line in the log.
You will have to add a JVM parameter while configuring.
It is shown in the below post on how to add it:
http://www.technimi.com/index.php?do=/group/java/forum/building-an-exe-using-launch4j-for-32-bit-jvm/