The whole structure with Java 11 has changed. Java is now a modular platform, where you can create your own "JRE" distribution with specifically the modules that you need to run your application.

The release notes at https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html have the following sentence:

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.

Documentation about jlink: https://docs.oracle.com/en/java/javase/11/tools/jlink.html

And another article about it: https://medium.com/codefx-weekly/is-jlink-the-future-1d8cb45f6306

The Answer by Stephen C is correct, and important.

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.

Important:

• Understand clearly the nature of the OpenJDK project, as explained in Wikipedia
• Read this white paper by Oracle of 2018-03, Java Client Roadmap Update
• Read the white paper Java Is Still Free, authored by key members of the Java community.

Learn about:

• Java Platform Module System
• jlink (JEP 282)
• jpackage (JEP 343)

Desktop apps are now expected to bundle their own Java runtime. Those tools listed above can create a very small runtime custom-fit to your particular app.

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

And a table mapping possible motivations or considerations leading to suggested vendors of Java.

Compatibility concerns

In the Comments, an question was raised, concern over compatibility issues between releases by various vendors.

Firstly, know that the OpenJDK project includes a vast suite of tests known as the OpenJDK Community Technology Compatibility Kit (TCK). Vendors are free to self-declare whether their release has passed those tests. These claims are not verified, and rely on the honor system. On my diagram above, I have check-marked "TCK" on the couple vendors I know have self-declared: Oracle JDK by Oracle & Zulu by Azul Systems.

All the products listed in the blue barrel area of my chart above are built almost directly on the OpenJDK source code. So generally, you should see virtually identical compatibility.

There are two areas of concern you might consider: Technology differences, and schedule of updates/patches.

As for technology differences, vendors using the OpenJDK project can ship with either the HotSpot engine or the OpenJ9 engine. These will differ on performance (faster/slower startup versus overall speed, more/less memory), but their behavior in terms of complying with the Java specifications should be identical. They could differ, and certainly either might present a flaw (that likely would be soon fixed) that the other lacked. Personally, I would not be concerned by this, but I mention it for completeness.

Another technology difference is the different kind of JVM used by Zing by Azul Systems and GraalVM by Oracle. Either of these might differ in some way from each other or from the other products, because they intentionally have a different kind of JVM implementation, to offer special features. But given the thoroughness of the Java specs, they should not be incompatible. If they were, you can expect any compatibility problem to be rapidly resolved. If I needed the special features of either of these products, I would use them with full confidence.

Another possible concern is the speed with which a vendor might update their own releases with certain bug fixes or security patches. For example, Oracle has stated that they reserve the right to immediately ship any ready patches to their own customers, while submitting those to the OpenJDK project for consideration. Certainly, any of the vendors providing commercial support are likely to rush a fix or patch to their paying customers. Those releases built as a courtesy to the community provided free-of-cost may take longer to update, likely after the OpenJDK project has incorporated a fix/patch.

And each vendor is free to modify their code base at will, as long as they comply with the Java specs. For example, the Corretto team at Amazon has already made improvements to their own release, and then shared those changes upstream to the OpenJDK project. There may a gap in time before OpenJDK incorporated those changes, if they decide to do so. So it is possible that various releases might differ. But at this point, all of the vendors in the Java community seem to have sincere commitments to work together to prevent fragmentation. So, again, I have no real concern here, but mention this for completeness.