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/
Related
I want to send a jar to some people for testing my software but I need that the jar is launched on a 32bit jvm. How can I verify automatically that the 32 bit jvm is installed and to be sure that the jar is launched with the right jvm?
I want to avoid to ask people to do all manually because they are not technical guys.
Can you help me?
******** SOLUTIONS ******
I have found two type of solutions that i want to share with you:
1) I have discovered that C:\Windows\SysWoW64 and C:\Windows\system32 contain the last installed version of the java.exe. So, ones could write a .bat that verifies which is the 32bit jvm for launching the code
2) Use the java code described in an other post for generating the proper .bat
As far as I know there is no simple way to achieve that. First guess is, of course, the %JAVA_HOME%. But it is most likely not set on the PC of "not technical guy", so let's skip it.
I believe there is a tricky way with Windows registry that could work.
If Java was installed with an installer (not just manual unpack) it will have some registry entries. On my PC I've found key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_25\JavaHome that points to my Java installation. There is also JDK keys nearby. There are multiple versions that can be installed on the same machine so it is better to collect all this keys (both jre and jdk in both HKLM and HKCU) and try to find one that points to the 32bit version. And if one has non-Oracle Java on his PC then registry keys will most likely have another path (if even exist).
When you found java installation there are many ways to check if it is 32 or 64 bit. Take a look at this SO question.
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
I have installed a 64 bit Java on a 64 bit Centos machine. My query is that if I dont specify the -d64 option will the JVM run in 32 bit mode even if there is no 32 bit JVM installed ?
Also I was a bit curious if we can use the -d64 option with "javac". If yes, then what does it imply or where could it be used? I came across this when reading this article.
Thanks
The selection of the data model (bits) for the JRE is to constrain the operation of the application to only run in one mode. The java byte code is designed to work in both data models, so for the 100% pure java applications, will work according the behavior and benefits of each architecture.
But, if your application use native libs that work only in one mode, then the application will fail under the not supported one. For that, you must explicitly indicate in which mode it should run.
When you set -d32 or -d64 the JRE will not start your application if it can't run in the selected mode.
From the Oracle document you linked to:
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.
(emphasis mine)
So, according to the document you linked to, the default is to run in a 32-bit JRE, and it is possible to run javac in a 64-bit JRE by passing -J-d64 rather than simply -d64.
However, note that this document also says that it applies to Java 1.4, and says nothing about more recent versions of Java.
I have see two jre in the java folder one in jdk and one outside jdk. Can you tell me the what is the reason behind having these two jre?
I didn't read your answer right and searched a little, here's an answer from somebody who seems to be Oracle staff:
There are some differences which may explain what you are seeing. The
JRE that is included with the JDK does not support Auto Update and it
does not contain any product offerings as the standalone JRE does. The
JRE and JDK are both built at the same time (approximately) from the
source base.
from https://forums.oracle.com/forums/thread.jspa?threadID=2277801
Old Answer 32/64 Bit Windows
If you are on Windows 7 64 Bit (or maybe other MS 64 Bit Systems) you need 2 JRE's. One for your 64 Bit Applications (Browser) and one for 32 Bit. They should have distinct Folder Names, ie:
64 Bit C:\Program Files\java\jre7
32 Bit C:\Program Files (x86)\java\jre7
If you're just running an application you only need the Java Runtime Environment (JRE), so it make sense to deliver that as a distinct entity.
If you are developing the you need the complete Java Development Kit, and it's helpful to have everything you need including the JRE.
So, two usage scenarios, two ways to get the JRE.
See the question referenced by Jaya for more information.
If you are developing a java program then compile time private jre(C:\Program Files\Java\jdk1.7.0_65\jre) will be used and running time public jre(C:\Program Files\Java\jre7) will be used.This is the default use case scenario.If compile time jvm finds that private jre is not there then it will go for public jre and run time also if jvm finds that if public jre is not there then it will go for private jre.
The JDK is required for developing Java applications, but it includes a JRE (Java Runtime Environment) which is required in order to run Java applications.
If you're an advanced user and you know what you're doing then you only need one copy of the JRE, meaning that you do not need the "Public JRE" in addition to the one that comes with the JDK.
Simply set your Environment variable JAVA_HOME to point to the JDK installation directory, and add the JRE's bin directory, i.e. %JAVA_HOME%\jre\bin, to your PATH.
If you want Java to notify/remind/annoy you about updates, and have an extra 200MB of disk space that you don't need, then install the public JRE too.
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.