I have made an a java app with JDK 13. I created a exe file with launch4j. But nobody can run it because everyone has the jre 1.8 version and it wont start... I has to include the java jdk 13 with installation and set the java_home with that ?
TL;DR - If you want to distribute a Java 13 application, the best option is to use jlink to create the executable. This avoids the user having to install any JDK or JRE to run your code.
Clearly, users cannot run your application with a Java 8 JRE or JDK. A typical Java 13 application will make use of features that are not present in the Java 8 platform. But even if it worked, free Java 8 will be end-of-life in April 2021, and at that point:
It will stop getting security updates, making it (in theory if not practice) unsafe for your customers to use.
It will be more difficult for your customers to find free Java 8 binaries. (Paying Oracle for a license will be an option though.)
But Java 13 is problematic too. That will be end-of life in September 2020! And besides, JRE distributions are no longer available.
Finally, application installers with embedded JREs were always somewhat problematic:
It was easy for software suppliers to forget to update the installer when there was a security patch to the JRE.
It was difficult for system administrators to add the embedded JRE to the list of things that were automatically updated. Especially if they allowed end-users to install the application for themselves.
The best approach will be to do the following:
Use jlink to create the distributable for your application for all platforms that you support
Update to Java 14 as soon as practical
Whenever a Java patch release with security fixes is released, assess what has been fixed and (if warranted) create new releases of the distributable for your customers to install.
If you don't want use jlink, another alternative would be to develop your code to run on Java LTS releases. (The current LTS release is Java 11, and the next one will be Java 17 which is planned for September 2021.)
Using an LTS release would allow you to release your code as JAR files.
Embedded JREs are a bad idea; see above.
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
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.
I (as a non-Java kind of guy) am puzzled that my local JRE 10 installation required an update, but when updating, I get the JRE 8! This is even reported on https://java.com/en/download/more_info10.jsp:
Users who installed JRE 9 and/or JRE 10 (non Long-Term Support Releases) should remove those out-of-date versions of Java.
I would understand if JRE 11 would be the current version, but no, it's JRE 8:
If you still require Java on your computer download the latest release of JRE 8 available at java.com, which is the only currently supported major release of Java targeting desktop deployment.
How can this be?
The explanation is right there on that page you linked and quoted.
Relevant section highlighted.
"desktop deployment".
If you still require Java on your computer download the latest release
of JRE 8 available at java.com, which is the only currently supported
major release of Java targeting desktop deployment.
Short answer:
Java 9 and 10 are not a Long Term Support (LTS) release, and have expired.
Java 8 commercial supports end January 2019, public updates for personal use through December 2020 though.
Java 11 is the current and is also a LTS support release.
So todays choice is between java 8 and 11. But 11 removed applets and browser integration and other desktop technologies (JavaFX, java webstart etc). See list below and link to source. See also the Oracle white paper of 2018-03, Java Client Roadmap Update.
Further details:
Oracle has decided to stop releasing several variants of JRE on their own. As well as requiring a license for production use for newer releases. For example 32bit variants are no more, traditional desktop variants not available as there is no no java webstart and javafx is separated out since jdk 11+ etc, Oracle is more focusing on 64bit and server.
Put together with the fact that 9 and 10 are not Long term support releases (and they have expired) this leaves you with the choice of Java 8 for this particular use case for now.
JDK public updates for java 8 from oracle will end in January 2019 (and December 2020 for personal use) so at least until then is the current desktop java version of choice, from Oracle that is.
The current version of java 11, is only available as a 64bit JDK (development kit download) from oracle. No suitable desktop JRE (just the runtime).
Removed in JDK 11 release from Oracle:
Important Changes and Information
The following are some important changes in and information about this release. In some cases, additional details about the changes described below are provided in these Release Notes.
The deployment stack, required for Applets and Web Start Applications, was deprecated in JDK 9 and has been removed in JDK 11.
Without a deployment stack, the entire section of supported browsers has been removed from the list of supported configurations of
JDK 11.
Auto-update, which was available for JRE installations on Windows and macOS, is no longer available.
In Windows and macOS, installing the JDK in previous releases optionally installed a JRE. In JDK 11, this is no longer an option.
In this release, the JRE or Server JRE is no longer offered. Only the JDK is offered. Users can use jlink to create smaller custom
runtimes.
JavaFX is no longer included in the JDK. It is now available as a separate download from openjfx.io.
Source: https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html
Simple: Oracle's own support roadmap lists Java 8 as having "premier" support until 2022.
Conversely, Java 9 and 10 have had their premier support lapse in March and September of 2018. Oracle's new update model ensures that non-LTS releases from Java 9 onwards are only officially supported until the new version of Java arrives.
"Current" is a bit of a strong word when it comes to Java; technically, the latest version of Java that should be used by end consumers is Java 11 (as of time of writing), since that is the current LTS. However, not all applications which use Java may be up-to-date, so it's safest to fall back to Java 8 until your application vendor informs you that it's safe to upgrade.
Perhaps that's because Java 11 deprecated modules which are present in Java 10 e.g. JAXB or Java FX. Latest Java 8 still has these modules so the software that worked on Java 10 can potentially work with Java 8.
On my machine, yesterday, I had installed and configured 6 java versions:
JRE 6
JRE 7
JRE 8
JDK 6
JDK 7
JDK 8
I believe an update was installed last night and today, both JRE 6 and 7 are missing (in 7, the lib folder is still there, as jars from it might have been locked by running applications).
JDKs are perfectly fine, same is JRE 8.
After checking on a different machine (windows as well), the same thing happened: JRE 7 missing almost completely.
Did any else experience this? If yes, what is the cause? Is it an Oracle "feature" to remove older JREs?
I should mention that we have application which for various reasons need 6 or 7, and cannot be updated to 8 at this time.
Thanks.
Yes, it's a feature. In the Java 6 times it was not, and it ended up in a library hell with dozens of versions of the JRE installed at the same time - something that, in theory, should not be needed as those versions are supposed to be compatible with each other.
As the documentation says:
The Java auto-update mechanism is designed to keep Java users
up-to-date with the latest security fixes. To achieve this goal
Windows and OS X users that rely on Java’s auto-update mechanism will
have their JRE 7 replaced with JRE 8.
...
As we did when JRE 6 was replaced by JRE 7, we have auto-updated users of the older release to the newer version of Java.
If you need to support older environments, you can set your compiler's compliance level. You will not be able to use newer features of the language, but it should run just fine.
You can also keep multiple JDKs installed and use that to test - the JRE comes bundled with it, so you just have to browse to that folder on the command prompt and compile with javac and/or start your app with java.
Does the JDK (Java Development Kit) update itself? I have noticed that I haven't gotten an update for JDK but only Java updates.
The JDK is used for writing java applications and is only updated manually.
The JRE is used for running java applications, such as jars and applets. Depending on the OS the JRE can be scheduled for automatic or manual update.
Some links with more details:
http://java.com/en/download/help/mac_java_update.xml
http://java.com/en/download/faq/expire_date.xml