55

We are planning to migrate our Java 8 project to use Java 11. But I noticed that Java 11 doesn't have a JRE folder.

In Java 9 and Java 10, folder structures are changed i.e. java\jdk1.x or java\jre1.x, where x is Java 9 or 10.

But in Java 11, I am getting only one folder, i.e. java\jdk-11. How will my client use my application without jre?

What I understood is that Java 11 is enforcing to modularize our application, and using jlink is needed to create our own jre to run the application in client.

Is my understanding correct?

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Maha Lak
  • 677
  • 1
  • 6
  • 7
  • 5
    The directory structure of Java 9+ is different, but it has full JRE functionality. For instance, you can see that the JDK includes a bin/java executable (or bin/java.exe). – VGR Oct 01 '18 at 05:19
  • In java9 or java10 installation i get two folders java\jdk1.10 and java\jre1.10. But in java11 i will have only one folder i.e java\jdk-11. I agree with you but for java11 there is no jre folder. – Maha Lak Oct 01 '18 at 05:32
  • 7
    See the documentation: [Oracle JDK Migration Guide - Deployment](https://docs.oracle.com/en/java/javase/11/migrate/index.html#JSMIG-GUID-954372A5-5954-4075-A1AF-6A9168371246). You are not forced to use the module system. – Jesper Oct 01 '18 at 06:15
  • 4
    JEP 220 and the JDK 9 release notes (specifically https://www.oracle.com/technetwork/java/javase/9-relnote-issues-3704069.html#JDK-8049367) have all the details on the changes to the structure of the run-time image. – Alan Bateman Oct 01 '18 at 07:50
  • Thanks Jesper. I got it. So client need to install jdk to use java application? – Maha Lak Oct 01 '18 at 07:50
  • 6
    @feelingunwelcome why was it closed as off-topic? It does not seem to ask for an off-site resource, but only how to use the JDK without JRE. – Didier L Oct 01 '18 at 11:07
  • 3
    Similar: [*How to get java 11 run-time environment working since there is no more jre 11 for download?*](https://stackoverflow.com/q/53111921/642706) – Basil Bourque Feb 17 '19 at 20:48
  • See also: [*Obtain Java 11 for macOS?*](https://apple.stackexchange.com/q/346195/17907). – Basil Bourque Mar 03 '19 at 05:47

3 Answers3

79

For 20 years, the JDK shipped with a JRE which was just a subset of its functionality installed in a different directory on your system.

In fact, it shipped with TWO identical JREs, one installed inside the JDK installation directory and one outside it.

This has always puzzled me as it's a complete waste of effort on the part of the maintainers to make this so, and a complete waste of disk space on the computer you install it on, as that JRE just duplicates some of the things the JDK can do already.

Finally, with Java 11, Oracle and the OpenJDK team decided to end this silliness and just distribute a single thing, the JDK. This JDK when installed is actually smaller on your hard disk than the old JRE alone used to be, removing even the somewhat valid argument that you'd want a separate JRE for devices with limited disk space, an argument that never explained why 2 JREs would be installed with a single JDK in the first place but was made to justify the need for a JRE as a stripped down runtime environment for the JDK.

Ergo, there is no need for a separate JRE, and there hasn't been one for a long time, let alone for including and forcibly installing it as part of the JDK installation.

And no, you don't need to create your own JRE. Just install the OpenJDK on the client machines and make sure you add the $JAVA_HOME/bin to the system path, just as you had to do with old JREs.

And oh, strip the Windows directory tree of any java*.exe files which some versions of the old JRE installer were wont to place there, as well as the system path which also had some weird entries added by some JRE installers.

jwenting
  • 4,890
  • 2
  • 22
  • 28
  • 8
    In earlier versions, a jdk could get installed anywhere whereas the “public jre” had to be installed on the boot partition. That was purely a restriction invented by Sun, as actually, the registration of browser plugins or the control panel did not require this. Later version lifted the restriction, but still installed the “public jre” as a separate jre (I always turned this option off anyway). Nowadays, these features are gone, so the unnecessary thing has become even more unnecessary. Afaik, you can still create a JRE from the JDK via jlink, which boils down to removing development modules. – Holger Oct 01 '18 at 14:06
  • 2
    @Holger good point. And even weirder is that Sun installed that JRE by default under "c:\program files" on Windows while it wouldn't work properly if installed in a directory with spaces in the name :) – jwenting Oct 02 '18 at 05:25
  • 2
    So... no more `JRE_HOME` environment variable ? – David Ferreira Oct 18 '18 at 00:24
  • Exactly! No need of separate JRE Installation and so no need of JRE_HOME environment variable. – Pratik Patil Oct 21 '18 at 18:45
  • 7
    I think the actual reason why JRE is no more available is because from Java 9 (the module system), applications are expected to ship as a self-contained piece instead of relying on an externally available JRE. – Codebender Oct 25 '18 at 16:40
  • @Codebender yet the distribution license for the JDK is such that you're not allowed to distribute it... – jwenting Nov 12 '18 at 04:58
  • 2
    The AdoptOpenJDK project provides both JRE and JDK downloads for Java 11: https://adoptopenjdk.net/releases.html?variant=openjdk11#x64_win (see @matsonkepson's answer). Is this more "silliness"? – mzjn Dec 18 '18 at 12:05
  • 1
    This answer can be summed up by the last two paragraphs of... interesting advice. Install a compiler into production and remove binaries from your customer machines at your own risk. – Cypher Feb 26 '19 at 00:04
  • For an answer with so many up-votes, it is completely wrong. The problem with installing the whole jdk is primarily security -- you increase your attack-surface by including the compiler. Also, you add other modules, such as java.desktop, that you don't use in server-based microservices and so which also increase the attack-surface. This is a bad idea. You should use jlink, no matter how difficult, to create a custom jre, as is the intent of modularisation. – Software Engineer Oct 10 '20 at 15:14
  • @SoftwareEngineer nope, that's part of the reason. They took out the included JRE because it was useless. And that was the question. – jwenting Oct 11 '20 at 12:55
  • @jwenting - the jre isn't useless. They took out the default because a jre with all modules enabled by default is useless. The intent is that you create your own jre with minimal modules using link. Using the jdk instead is a security flaw. – Software Engineer Oct 11 '20 at 14:36
30

tl;dr

How will my client use my application without jre?

➥ Bundle a Java implementation within your Java-based app.

Learn about:

Details

What I understood is that Java 11 is enforcing to modularize our application

No, modularization is not required, strictly speaking. Most existing apps can run as-is in Java 11. You can continue to develop in Java 11 without modularizing your code. But in your case, for a GUI desktop or mobile app, then you need to package a JVM within your app. Modularizing and using jlink tooling is probably the best way to go about that. In contrast a server-side Servlet-based app or Microservices server need not yet modularize, though likely a good idea to do so eventually.

I noticed that Java 11 doesn't have a JRE folder.

Oracle no longer intends for end-users to be installing a JRE or a JDK. Java Applets in a browser and Java Web Start app delivery are both being phased out, leaving the end-user with no need for a JRE. Java-based apps are expected to bundle their own Java implementation. The only folks consciously installing a JDK will be developers & server-side sysadmins.

Some folks are disappointed to see the passing of the Java Everywhere dream. And they may be annoyed to have to make a build of their app for every host OS (macOS, Linux, Windows, etc.). On the other hand, some developers are happy to be bundling a Java implementation (now smaller than ever) with their app, as that eliminates the hassle for the end-user to download-install-update a system-wide Java implementation. Also eliminates wrestling with corporate IT departments to install Java on users’ PCs. And bundling Java with app simplifies testing and support, as you know and control exactly what version and distribution of Java is involved. By the way, this bundling-Java-with-app is not exactly new: It has been supported by Apple for many years in the macOS & iOS app stores.

Important:

Here is a flowchart diagram that may help you finding and deciding amongst the various vendors providing a Java 11 implementation.

Flowchart guiding you in choosing a vendor for a Java 11 implementation

Motivations in choosing a vendor for Java

Basil Bourque
  • 218,480
  • 72
  • 657
  • 915
  • 1
    Tying together what you wrote and what jwenting wrote, my understanding of Oracle's vision is: End users need one copy of a Java runtime installed as a part of each and every Java application they want to execute. And developers need to ship a separate installer of their application for each non-server platform they want their application to be able to run on; the installation includes both their application and a Java runtime. The RA (run anywhere) part of WORA is now more difficult than previously. – Pixelstix Apr 26 '19 at 20:43
  • 3
    @Pixelstix Correct, except for the last sentence. Some developers are happy to be bundling a Java implementation (now smaller than ever) with their app, as that eliminates the hassle for the end-user to download-install-update a system-wide Java implementation. Also eliminates getting corporate IT depts to install Java. And bundling Java with app simplifies testing and support, as you know and control exactly what version and distribution of Java is involved. By the way, this bundling-Java-with-app is not exactly new: It has been supported by Apple for many years in the macOS & iOS app stores. – Basil Bourque Apr 26 '19 at 21:07
  • 1
    Granted things are easier from an enterprise point of view, especially if you assume an app store model of updates. The developer would IMO be ethically obliged to release new versions of their application just to ensure they ship with a recent JRE without known security vulnerabilities. In a larger sense, this feels to me like a shift from Java as a platform to Java as a runtime, with a few trade-offs being made which work out better for some than others. – Pixelstix May 03 '19 at 15:00
  • 2
    You need update your app with a fresh release only if a new security vulnerability could affect your particular customers because of your particular features. No need to update for a TLS bug if your app does not use TLS. This is true for any libraries you may include as a dependency in your app. The JVM is now one (large) dependency within your app. The JVM within your app is being used only by your app. – Basil Bourque May 03 '19 at 16:25
  • 2
    @Pixelstix We do agree. This is certainly a shift from Java as a platform to Java as a runtime. And yes, there are trade-offs, with some benefits and some down-sides. – Basil Bourque May 03 '19 at 16:27
10

Look at the AdoptOpenJDK project website to download the latest JRE and JDK.

I have used their nightly builds to work around the problem of missing JRE in JDK package. Just unpack JRE into JDK folder and this is going to be it.

Enter image description here

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
matson kepson
  • 1,284
  • 12
  • 14