1. Extract the zip file into a folder, e.g. C:\Program Files\Java\ and it will create a jdk-11 folder (where the bin folder is a direct sub-folder). You may need Administrator privileges to extract the zip file to this location.

2. Set a PATH:

   • Select Control Panel and then System.
   • Click Advanced and then Environment Variables.
   • Add the location of the bin folder of the JDK installation to the PATH variable in System Variables.
   • The following is a typical value for the PATH variable: C:\WINDOWS\system32;C:\WINDOWS;"C:\Program Files\Java\jdk-11\bin"

3. Set JAVA_HOME:

   • Under System Variables, click New.
   • Enter the variable name as JAVA_HOME.
   • Enter the variable value as the installation path of the JDK (without the bin sub-folder).
   • Click OK.
   • Click Apply Changes.
4. Configure the JDK in your IDE (e.g. IntelliJ or Eclipse).

You are set.

To see if it worked, open up the Command Prompt and type java -version and see if it prints your newly installed JDK.

If you want to uninstall - just undo the above steps.

Note: You can also point JAVA_HOME to the folder of your JDK installations and then set the PATH variable to %JAVA_HOME%\bin. So when you want to change the JDK you change only the JAVA_HOME variable and leave PATH as it is.

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.