Develop Reference

JDK and JRE version confusion

I've been working with Java for a bit now and the JDK/JRE version has given me quite a bit of trouble lately. I am developing using the Intellij IDEA IDE and it of course uses the latest version of the JDK, 14. However when I attempt to execute software compiled with JDK 14 outside the IDE, I get an error that the JRE isn't new enough to run this software. So I updated Java on my computer and another machine and attempt to run again without any success. After some digging, I tweaked my machine to use the JRE included in the JDK 14 which is compatible.
However it is kind of odd that I had to do that, one would think that the latest version of java should of been enough to run applications made with the latest version of the JDK (14). Right now Java is version 8 build 251 and says there is no newer update available. If JDK 14 is out for a while now, why would they not update the version of Java they ship?
The problem is partially solved, as only the machine I am using for development is capable of executing the created applications. Other people I've sent them to have been unable to run them, despite having the latest version of java. Also it is a pain to get the latest JDK, especially when having limited experience on how to get rid of old versions, change path point to the latest version, get the right package (open/oracle JDK) and do that for windows and several distrubutions of linux. What is going on? Did I get Java from the wrong place and everyone else as well? Why are oracle doing this and why are there no java updates since clearly there exists a newer version?

Starting with Java-11, separate JRE does not exist anymore. In other words, if you are using Java-11 or above, you should care about JDK only.
You should uninstall JRE-8 from your machine and make sure your JDK-14 bin folder in the PATH variable. Some application even requires JAVA_HOME to work and therefore you should make sure that your system has an environment variable called JAVA_HOME and its value set to the root folder of JDK-14 (i.e. one level above your JDK bin).
Q: What should my clients do to run my application compiled on JDK-14?
Ans: Your clients must install JDK-14. Also, check this thread for some alternatives.

You're confusing how IntelliJ or JDK are used on the OS. IntelliJ, now, often comes with its JDK binaries (but even this can be configured, IntelliJ can be configured to use any JDK/JRE build you'll provide to it); however, if you run your Java application out of IntelliJ, most likely you're using Java installed locally on your OS, which might be referenced via your JAVA_HOME environment variable.
I'd suggest to:
Check java -version in your shell (and hence you'll see what JVM instance your OS spins up when you run a Java application);
Check where java (on Windows, or which - on Linux) in your shell, to see all the Java binaries available on your OS.

Try to uninstall Java SE Development Kit and Java JRE(if you have both in your machine) and reinstall both again, JDK and JRE both, I am sharing my google drive link where you can find the latest version of both JDK and JRE and when you are done installing, add there bin folder path in the Environment Variables of your machine.

Build times increase substantially when switching to Java 7

We use Java within our build process, as it is used to resolve/publish our dependencies via Ivy.
No problem, nor have we had with it for 2 years, until we've tried to upgrade Java 6 Update 26 to Version 7 Update 7, whereas a build on a local developer PC (WinXP) now takes 2 hours to complete, instead of 10 minutes!!
Nothing else has changed on the PC, making it the absolute target for our concerns.
Does anyone know of any reason as to why version 7 of Java would make such a speed difference like this?
UPDATE: The build process is NAnt-based, so Java.exe is called from a NAnt script, running in a Command (DOS) window.

I'm using JDK 7u7 and I noticed a better performance by tuning some VM Options.
You could try the G1GC and AgressiveOpts to help with compile time.
Follow the settings I use in my editor:
-Xss8m
-Xmn256m
-Xms512m
-Xmx1024m
-XX:PermSize=256m
-XX:MaxPermSize=512m
-XX:+UseG1GC
-XX:+OptimizeStringConcat
-XX:+UseStringCache
-XX:+AggressiveOpts
You will find each option's description in the VM Options link.
I hope it helps.

In my experience, Java 7 was a huge step backward in terms of speed and compatibility. I've found it slower not only to compile, but running the JRE as well.
I've also had major issues running eclipse with it (and yes, i've used update 7).
And from my standpoint there's nothing in Java 7 that i need. I like the ForkJoinPool, and can get that as an add on library for Java 6.
Maybe Java 8 will be better.

First, did you remove JDK6 or leave it in place? Check your JDK_HOME and any other place it is specified to ensure that you are actually using JDK7. In the XP console type java -version and ensure it is what is expected. (Close/reopen the command prompt to pick up changes in the Win GUI.)
It was never stated what version of XP you are running -- 64-bit or 32-bit. Ensure the appropriate JDK environment is on the machine. (Depending on exactly what is executing, this can make a tangible difference. Also, the best bet for debugging is to keep it the same as before -- reduce variables.)
Troubleshoot the issue and narrow it down. Does an Eclipse installation perform slower after the upgrade? (Eclipse itself runs in a JVM. It's a good baseline.) Is Eclipse pointing at the correct JDK when you test it? Try other Java tools to see if there is a performance difference. Breakpoints and logging at different control points in the build and any Java executables are your friends.
Since Nant is .NET based, have you looked at the Java process that is actually launched? Is your Ivy distribution really old?
All this said, it is hard for me to believe this is a Java issue and not a configuration challenge on the Windows box. Have you tried it on any other machines, anyway?

Ensure 32-bit JVM in Install4J?

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.

Java exit code 13 on Eclipse RCP application (Indigo)

I seem to have a 32bit vs. 64bit problem here. It should be simple to solve, but I'm hoping you can help me by pointing out the problem. I really want to avoid re-installing OSs, Eclipse, several plugins, JDKs and JREs over and over again to find a working solution. Many thanks in advance!
I build on a 64bit Thinkpad, in 64bit Windows 7.
I have built an Eclipse RCP application in Indigo (3.7.1.), 32-bit version.
The only "Javas" I have on this machine is a 1.6.29 32bit JRE, and a 1.6.29 32bit JDK. I've installed these (perhaps in false assumption) to be able to build for 32bit systems, and not screw things up by building on a 64bit machine.
Seems I was wrong: when I export the application (as Eclipse product) I get the dreaded Java exit code=13:
I am sure this is somehow to do with the combination of 32bit software on a 64bit system (if you can prove me wrong, even better!).
Does one of you know how I can set this up properly and still be able to build for win32?
Again, many thanks!
UPDATE
I have installed 64-bit Eclipse 3.7.1, and JRE 1.6_30 + JDK 1.6_30, both 64-bit versions. However, the error remains! I think this might either be a bug, or I'm doing something else wrong.
First of all, here is the error message:
For this build, I didn't use the Delta Pack but instead added the RCP SDK Software Site to the target definition, choosing the option "include all environments" (or similar).
Also in the target definition, I set the target environment to win32 (OS and WS) and x86_64 (arch). Furthermore, I set the Environment to use the default JRE.
In the product configuration, I set the Execution Environment to JavaSE 1.6, and set the JRE to be packaged.
Also, here's my eclipse.ini:
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
Any ideas?

I would recommend you to install everything as 64bit or 32bit system. That's a common problem with eclipse and I haven't found a better solution.

The Eclipse website tells me that
"Exit code 13 is returned from Main when it wants the launcher to display an error message. Generally, the error message will just be "an error has occurred, check your log file". Look for a log file in your configuration directory."
Some of these errors have been caused by not having the correct java version installed (Cannot run Eclipse; JVM terminated. Exit code=13), while others seem to have been caused by a "#" character in their eclipse directory (http://www.eclipsezone.com/eclipse/forums/t105198.html).
Maybe one of these reasons causes the crash.

Seems this had nothing to do with 32-bit vs. 64-bit and everything with my lack of experience. The product configuration simply wasn't set up correctly. I've bypassed this by creating a new one which uses the automatically created plugin run config from when you start the application via the "Launch an Eclipse application" link in Eclipse itself.
For those who come across a similar problem, here is how it can be done.
Launch the application via "Launch an Eclipse application"
Go to Run > Run Configurations... and memorize the name of the run configuration
Create a new Product Configuration, and choose "Use a launch configuration:" in the wizard. From the dropdown list, choose the run configuration you have memorized in step 2.
Give the new product configuration an ID, Version and Name, and add further info (e.g., in the Product Definition section) as needed.
Synchronize and Launch from within Eclipse to see if everything works fine.
Export and be happy.

Install all in 64bit.
Then to run (emulate) your Eclipse in 32bit
Just: insert an argument in:
Run Configurations... -> Arguments (tab) -> Program arguments : Type -d32

Old question but it seems worth answering. I just had this problem with an RCP based on features. It turned out that I was exporting the RCP with the feature projects closed. When I opened them and exported the product again, everything worked fine.

try moving the project to the root of the drive
c:\test\eclipse\

solved:D
1. check the operating system is it 32 bit or 64 bit.. but i think its not problem on my computer because i am using 32 bit jdk and 32 bit eclipse on my windows 7 64 bit.
2. if u still have problem ... try to move eclipse to C:/ its work for my friends.. with problem returned error 13

Configure Launch4J to use 32-bit JVM only

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/