This question already has answers here:
Multiple Java versions running concurrently under Windows
(10 answers)
Closed 9 years ago.
I was wondering if there would be any implications (slowed performance, crashes and so on),
running a java 1.4 application and a java 1.6 application on the same machine
Different java version are installed in different directories so running 2 java programs with different JRE version will not make any effect other than that you are running 2 processes of java.
So bottom line, there is no problem with that, it will not slow you down.
Also, java 6 has better performance than 1.4 so if you can run both on 6 its usually better.
None, The only problem is you can only have one default JVM. If you have too many versions e.g. hundreds it is likely to be a bit of mess, but it won't slow you down.
It seems that the header does not correspond the question. Running different jre versions on the same machine is not the same as running a java 1.4 application and a java 1.6 application. So I will give 2 answers
Yes you can have 2 different jre installed on your machine.
You can run 1.4 application (classes compiled in Javac 1.4) on JRJ 1.6 but you cannot run 1.6 application (classes compiled in Javac 1.6) on JRE 1.4.
Of course, It will not slow machine. A machine can have multiple JVM on single machine. There will not be any kind of conflict because everything would be in separate folder.
There is only special case in case of multiple JDK/JRE.
Case : - What version will be used by your browser.
For this you can control all the things from java console from control panel in windows.
Yes, you can have multiple JRE installed on the same machine on the same O/S. And you can have one project configured with one version of Java Compiler on your IDE. But remember when you run Higher version of Java compiled code on a JRE having lower version, you might face some issues with the new features and enhancements introduced with the later versions.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I write a few small, free, desktop command-line applications in Java. I package those as JAR files in releases on GitHub. About a year ago in light of Oracle licensing changes, I switched from the Oracle JDK to Open JDK. Developing on Windows, this is what I currently have installed:
C:\Users\admin>java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12-39)
OpenJDK 64-Bit Server VM (build 17.0.1+12-39, mixed mode, sharing)
Now, about a week ago I was visiting a friend (also a software developer) and a reason came up where we wanted to run my application on his Windows box. He didn't have Java installed. So, watching over his shoulder, he went to the java.com "Download Java for Windows" page (currently listing Java Version 8 Update 341), downloaded, and installed it.
Then when he went to run my application, it failed to run, giving back an error along the lines of (paraphrasing from memory), "This version of the JRE does not support a later version of Java". This surprised both of us; he didn't know there was a later version of Java, and I didn't know compiling with the current OpenJDK would make a non-supported binary.
What's the best practice to fix this release problem?
Your user most likely ran into the issue that Java classes compiled with a newer class file version number do not run on older JVMs. If that is the only issue it can be addressed by recompiling ...
But there is a deeper issue. Older Java class libraries don't support all of the APIs provided by newer versions of Java. Also there have been some important architectural changes starting in Java 9 (e.g. addition of modules, removal of applets and closing off access to JDK internal classes) that "break" applications that run on older Java versions
What this means is that if you develop and test your code on Java 17 (say) there is a significant chance that it won't work on (say) Java 8 ... even if you compiled it for Java 8. And vice versa, because some APIs have been removed, or made inaccessible or ... work differently.
So my advice would be:
Decide on a specific range of Java versions you will support for your application; e.g. Java 8 LTS1 through Java 17 LTS.
Develop targeting the oldest Java version and its APIs.
Build and test on the Java oldest version.
Also test on (at least) all of the other LTS Java versions ... within the range you are supporting.
This will mean that you are limited to using the APIs and Java language features of your oldest supported version. This could hold you back, so you have to choose between that and supporting users with old (out of date) versions of Java.
The issue of users trying to install / use old versions of Java can be addressed in three ways:
Provide clear installation instructions to the user that say what kind / version(s) of Java they need to install, and where to get them from. (And how to set or configure JAVA_HOME if your application relies on that.)
Of course, some users won't read the instructions properly, but that is their lookout ...
Use jlink to turn your application into a custom JVM, and distribute your code that way.
Use jpackage to create platform specific binaries.
If you take the jlink or jpackage routes, the onus will be on you to push out new distributables whenever there are Java security patches that are relevant to your application. Your users won't be able to "just install the latest Java patches" anymore.
Note that jlink is available for Java 9 onwards, and jpackage from Java 16 onwards.
What JDK should I compile with to support most desktop users?
I don't think there is a good answer to that. We can't tell you what proportion of "desktop" users have each version of Java installed. (Or what they are permitted to install; e.g. by corporate policy.) But you can't support old Java versions indefinitely.
I did find this though:
Java 8 still dominates, but Java 17 wave is coming – survey - dated March 2022.
1 - Java 7 and earlier are all well beyond "end of life". You are not helping anyone by trying to support them.
Well, you have a few options...
First of all you can TARGET the version 8 runtime, but you can compile code from later revisions of the language. This may or may not work in all cases, as Java 9 and up do some things rather differently! Still, fairly vanilla Java that isn't doing weird ClassLoader stuff is LIKELY to work, and you can certainly avoid problematic constructs.
Secondly, you can simply stick to Java 8! It is ANCIENT but it is a virtually immortal LTS, due to the reason above that things in Java 9 are different. However, you will miss out on new things.
You COULD go whole hog and move on from Java 17 to GraalVM, which can be had in versions compatible with Java11, Java17, etc. It has the ability to compile code down to a completely stand-alone binary, using native-image, and again unless you do some fairly esoteric stuff, your code will work. The end result will be similar to using something like C++. You can even build shareable libraries.
I guess your other option is to just make sure people are not using Java8. Ideally they're using Java11, but I guess now java17 is the newest LTS, though few people seem to install it.
It looks like you are using Java 17. Developers of apps targeting Java version after 8 are expected to supply the runtime for running the application. This means there is no more 'downloading and installing Java' separately on the user side. This is also why the download page you refer to only offers Java 8.
In practice, this means that you should use jlink to create a runtime image (i.e. the thing that you would previously download and install) that can run your application.
jpackage can also be used to create application images and installers (it calls jlink under the hood). Both of those are tools that come with the JDK.
For your purposes I recommend using jpackage with something like this:
jpackage `
--win-console `
--main-jar app.jar `
--main-class Main `
--name myapp `
--type app-image `
--input input
In this command, input is a folder that has the main app.jar in it (Note: the input folder should not be the current directory, since that will lead to infinite recursion).
--win-console is also needed for console applications on Windows, since otherwise no console is created when running the app.
This command will create a myapp folder that you can zip/tar up and distribute.
This myapp folder has a myapp.exe launcher that can be used to run the application.
Also, note that this will create a runtime image with a default set of modules. If your jar is modular (i.e. it has a module-info file), I suggest using --module instead of --main-jar/--main-class, since that will use the module descriptor to determine the set of modules in the runtime image. (See jpackage --help)
Note that on Windows you will also need to install the wix toolkit. It can be installed easily through e.g. scoop:
scoop install wixtoolset
It is to my understanding that Java JREs are backwards compatible, if you write a program in Java (JDK) 7, it will run with Java (JRE) 8.
I have a couple of programs I developed in Java 8, and have .jar and EXE files that I built when I finished them, and they always ran fine. However, after installing Java JDK 11 (11.0.2), these old .jar files break...
A couple of them still run, but their GUIs have expanded, with buttons and images being bigger than before, and in some cases blurry
One program just doesn't run at all, trying to run it in a console gives an exception: "Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: javax/activation/ActivationDataFlavor"
I understand that this class and some other javax classes have been removed from JDK 11, so from a development standpoint you couldn't use them anymore without a tool such as Maven. But I do not understand why installing JDK 11 has any effect on my old jars, as I didn't install a new JRE, and even if one came with it, it should be backwards compatible?
Too add to this, I use Apache NetBeans 10, it worked fine with Java 8, but after I installed JDK 11, NetBeans 10 still ran but its loading window was big and blurry, and the IDE's images are blurry, and all the text is bigger.
So why is installing JDK 11 having these negative effects on older programs?
Note - I have tried associating the jars/EXEs with javaw.exe from JRE version 8 (201), however, they all still have the same issues.
Java tries to be backward compatible but sometimes breaking changes are necessary to evolve the ecosystem. Until now breaking changes were shipped with major release e.g. Java 9, 10, 11. In your case you are most likely affected by Java 11's JEP 320: Remove the Java EE and CORBA Modules.
Remember that Java 8 was released in 2014. For 5 years Oracle and the Java community provided patches and security fixes for Java 8 but doing this forever is impossible.
The issue you are facing is likely not an incompatiblity w.r.t. the bytecode. It is just a missing class.
Java 11 dropped the support of some old technologies - for example Java Applets. If you run a Java 8 Applet in a Java 11 JDK / JRE you will get a ClassNotFound exception just because Java 11 does not provide the class / jar.
Similarly for JavaFX, which still exists, but is not longer part of the Java Distribution. You have to add it as a separate Jar.
I believe it would be possible to add these classes to a project. Personally I would like to see a port.
I'd like to write a desktop app using Java and I'm wondering if I can get the app to execute on computers running both Window 7 and Windows 10. I've got Eclipse set up with JavaSE 1.8 and I'm running Windows 8.
Thanks!
Yes. Once it's compiled, you can pass your app on to any computer with a JVM (Java virtual machine, aka "any machine with java installed") and your application will be able to be run. There are versioning caveats, for instance an old version JVM won't be able to run newer code (compiled to a higher version) but you probably won't have to worry about it. If you need to, you can set your compiler to compile to earlier versions (and you can set this in eclipse) but you probably won't have to bother with it.
Does Java support running in compatibility mode? In other words if we have JDK 8 install on system, can it be configured to run my application on 7 or previous release using the same installation ?
I can give one example like IE-11 can be switch to run as IE 8, 9, or 10 based on the compatibility option.
I agree with the comment of Kayaman.
There are 2 types of incompatibilities that could occur: bytecode changes (some feature supported in 8 and not in 7 - new Java versions tend to be upward compatible - so 8 will be able to run all 7-targeted code) and library changes which is more problematic.
If you have compiled with Java 8 targeting 7+, your bytecode will be compatible with Java 7 JVM, but you have no guarantee that it will run with Java 7 libraries.
Your best bet is then to compile and run with Java 7 - and it will (most probably) run with Java 8.
Then there are other changes that may impact your application (GC performance for instance).
Hi for suppose i have multiple JRE versions(1.6.1 till 1.7) on a single machine and one of the application is supposed to use JRE 1.6, at the same time another application is using JRE 1.7.0_17 ,Will that cause any performance issues???Please advice
No it shouldn't cause any (big) problems. Each JVM will run as a seperate process and will be handled independently by the OS. If your apps use the same resources, then there might be a deadlock somewhere.
As a general note (which applies to any process), having more processes will consume more CPU.
Yes, you can have multiple JRE installed on the same machine. And you can have one project configured with one version another with another version.
But if you run Higher version of Java compiled code on a JRE having lower version, you might face some issues.
It will not slow machine. A machine can have multiple JVM on single machine.
First in hand, since you are talking about JRE (not JDK), you need not to have multiple JRE's.
JRE 1.7 supports JRE 1.6 because of backward compatibility. Just remove 1.6 and connect to 1.7.
Might helpful : Do I need both JRE 1.6 and JRE 1.7?