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.
Related
I am developing a windows application.
I need to create an installer(a common installer for both 32 bit and 64 bit windows OS) for that, for that I am using Install4J software.
I developed in Windows 32 bit, jdk 1.7.
Installer working fine in 32 bit windows os, but when I try to create installer in win 64 bit os, it is throwing me an error like java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM
Please help to sort out this..
The problem is that there are separate "swt.jar" files for 32bit and 64bit Windows JVMs, and they are not interchangeable. You can't use the 32bit Windows JAR on a 64bit Windows JVM ... or the other way around. (AFAIK, the fundamental impediment is in Windows and the JVM rather than SWT.)
One possibility is to do some classloader tricks, and dynamically choose between different JARs depending on the platform that your app detects at runtime. The installer would need incorporate both flavours of the SWT JAR ... with different names.
This answer goes into more detail: Supporting SWT on Windows/Mac & 32bit/64bit
Well that is just because when u install program into the Program files that will install only 32-but and will load 32-bit libraries so u can do one thing very simple solution of that just install your program in the the Program files x86 if u have 64 bit system.
that work for me and might work for u too.
I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?
The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer
The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.
"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!
My computer is win7 64 bit, and jdk is 1.7.0.21,jvm is 1.6.. and 64 bit
I want to run SWT application and export as runnable jar file. When I run the application, it has the exception that Cannot load 32-bit SWT libraries on 64-bit JVM, so I import the SDK as alternate jre just like you point at Cannot load 64-bit SWT libraries on 32-bit JVM ( replacing SWT file ), and in Eclipse, the application can run correctly, but when I edit the bat file to run the jar file, it always has the problem like Cannot load 32-bit SWT libraries on 64-bit JVM, I have the swt.jar for 64 bit, but I don't konw how to replace and I wanna edit the bat file with the information with the SDK. How to handle the problem?
You have a 64bit JVM so it won't run the 32-bit SWT libraries. You need to either:
Download and install the 32bit JVM and change your project's settings to run the 32bit JVM instead of the 64bit one.
Download and install the 64bit libraries instead.
This previous SO question has a great description of the first option with accompanying diagrams:
Cannot load 64-bit SWT libraries on 32-bit JVM ( replacing SWT file )
64-bit JVM ?
you should use the 64-bit swt
Apart from the appropriate swt lib corresponding to the Operating system and their bitness, sometimes consider the following also:
My environment:
32 bit Ubuntu
32 bit JVM/JRE
Eclipse running using the 32 bit JRE
32 bit Gtk SWT
Approach 1:
I faced the problem when I was replacing the 32 bit swt with 64 bit swt to test on other platforms. To resolve, I had to remove/clean the project and rebuild the project with the 64 bit swt. But this step logically does not make sense, still works.
Approach 2:
All my swt libs for each O/S had the same name- "swt.jar" residing in different folders. I only changed to the appropriate lib when testing, i.e., 32 and 64 bit o/s both has swt.jar. Now this was somehow causing some problem. Not yet able to identify. But on changing the name to something different for each of the swt lib files, it got resolved. This step also does not make much sense.
Approach 3:
I am working using geotools api version 10.5 which also contains an swt library in the bin folder. I had to remove it from the folder (move to alternate location) and now my app runs smooth!!
I had a similar issue. Installing 32-bit jvm on my 64-bit machine solved the issue.
My dificult to work with SWT is the distribution. It's require a installation for each SO (Linux, Windows | 32, 64), Swing no have this problem and is cool, but I prefer SWT/JFace.
To solve this problem I create a Ant script to zip each installation with its rightful swt jar.
I get the specific swt jars in:
http://archive.eclipse.org/eclipse/downloads/drops/R-3.6.1-201009090800/index.php#SWT
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 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/