Install Microsoft OpenJDK 21 on Windows 11/10 Using WinGet: Set JAVA_HOME, Path and Verify Java

Check compatibility and choose your Java version​

This walkthrough uses Microsoft Build of OpenJDK 21, a long-term-support JDK available for Windows x64 and ARM64. It is a supported choice, not a claim that Java 21 is the newest release. As checked on October 18, 2026, Microsoft lists September 2028 as its earliest end-of-support date. Microsoft’s operating-system policy also requires an actively maintained OS receiving security fixes.

Before starting:

• Check which Java major version your project, course, or build tool requires. Follow that requirement instead of selecting a version solely because it is newer.
• Allow an internet connection for the package download.
• Have administrator approval available if the installer or system-variable editor requires it.
• On a managed work or school PC, obtain approval before changing the machine’s default Java installation.
• Keep any existing JDK until you have checked whether another project needs it.

Windows 10 compatibility is not the same as Windows 10 support. Normal support for Windows 10 version 22H2 ended on October 14, 2025. Installing a maintained JDK does not restore operating-system support; check your Windows servicing entitlement separately.

The main procedure uses Command Prompt to avoid mixing shell syntax. Windows Terminal is also suitable, but it hosts different shells: select a Command Prompt profile for the Command Prompt examples. PowerShell equivalents for the important verification commands appear later.

1. Check WinGet and inspect the package​

1. Open Start, type Command Prompt, and open it.
2. Check that Windows Package Manager is available:

winget --version

A version number means the command is available. If Windows reports that winget is not recognized, install or update Microsoft’s App Installer through Microsoft Store, then reopen Command Prompt. WinGet is delivered as part of App Installer. If your organization blocks it, ask IT for the approved deployment route rather than bypassing the restriction.

1. Inspect the exact package before installing it:

winget show --id Microsoft.OpenJDK.21 --exact --source winget

Check that the result identifies Microsoft Build of OpenJDK 21. --exact restricts matching to the supplied identifier; --source winget avoids ambiguity with other configured catalogs. Review any source agreement before accepting it.

1. If you already use Java, record what currently runs:

 java -version
 javac -version
 where.exe java
 where.exe javac
 echo %JAVA_HOME%

Save the results for comparison. A missing command is not a problem at this stage. where.exe searches the current directory and directories in Path, making it useful for identifying competing installations.

2. Install the JDK with WinGet​

Before installing: Microsoft advises using only one installation method for each JDK version. If you already installed Microsoft’s JDK 21 through a different installer format or a ZIP deployment, do not layer a second method over it without planning the migration. Record its location and dependent projects first.

1. Run:

winget install --id Microsoft.OpenJDK.21 --exact --source winget

1. Review the package information and any agreement prompts. Approve a Windows elevation request only if you are authorized to install the software.
2. Wait for WinGet to finish. Do not continue with environment-variable changes if the installer reports a failure. WinGet selects and launches the package installer; installation can require elevation even when the original terminal is not elevated.
3. Locate the installed JDK in File Explorer. Microsoft’s Java setup documentation gives a location in this form:

C:\Program Files\Microsoft\jdk-21.0.x.x-hotspot

That is an example, not a path to paste literally. Use the actual folder on your computer, including its installed version suffix. Open its bin subfolder and confirm that it contains java.exe and javac.exe. Then return to the parent JDK folder and copy its address.

The installer may already have added Java tools to Path. Microsoft documents that behavior separately from the optional JAVA_HOME installer feature, so check the variables rather than assuming both were configured.

3. Set JAVA_HOME and Path without overwriting existing entries​

JAVA_HOME should identify the JDK root, while the Path entry identifies its bin subfolder:

Do not set JAVA_HOME to java.exe, javac.exe, or the bin folder. Microsoft’s documented Windows configuration uses the root folder for JAVA_HOME and %JAVA_HOME%\bin for Path.

Warning: Changing system variables can change Java selection for other users and development tools. Before editing, record any existing JAVA_HOME values and the existing Java-related Path entries, including their order. Never replace the entire Path with a Java directory.

1. On Windows 11 or Windows 10, open Start, search for Edit the system environment variables, and select it. This shared route avoids the differences between the two versions’ Settings layouts.
2. In System Properties, click Environment Variables.
3. Under System variables, select JAVA_HOME and click Edit if it exists. Otherwise, click New.
4. Enter:

• Variable name: JAVA_HOME
• Variable value: the actual JDK root folder copied from File Explorer.

1. Click OK.
2. Still under System variables, select Path, then click Edit.
3. Click New and enter:

%JAVA_HOME%\bin

If that exact entry already exists, do not add a duplicate.

1. Click OK in each open dialog to save the changes. These are the system-variable settings Microsoft documents for its Windows Java setup.

Also inspect User variables for an existing JAVA_HOME. Windows maintains both user and machine scopes, and a user-level setting can affect the environment seen by your programs. Do not leave an old user-level Java selection unnoticed while configuring a new machine-level one. Record it before changing it, and use the fresh-terminal check below to see the effective value.

Avoid shortcuts that rewrite Path using setx. Microsoft documents that setx expands variable references and has a 1,024-character assignment limit; using it carelessly on a long Path can lose existing entries. The graphical editor is the safer approach here.

4. Open a fresh terminal and verify Java selection​

Environment changes do not rewrite the environment of an already-running shell. Close your existing Command Prompt windows and reopen Command Prompt from Start. If using Windows Terminal or an IDE terminal, close and reopen the host application too. Existing processes and their child processes can retain the previous environment.

1. In the fresh Command Prompt, run:

 echo %JAVA_HOME%
 "%JAVA_HOME%\bin\java.exe" -version
 "%JAVA_HOME%\bin\javac.exe" -version

These explicit-path commands check the JDK selected by JAVA_HOME, independently of ordinary Path lookup.

1. Now check the commands you will normally use:

 java -version
 javac -version
 where.exe java
 where.exe javac

Both version commands should report Java 21 for this walkthrough. Inspect the reported executable locations too: merely seeing the same major version does not prove they belong to the same installation. where.exe can reveal additional Java executables in the search locations.

1. If using PowerShell, use its environment-variable syntax and call operator instead:

 $env:JAVA_HOME
 & "$env:JAVA_HOME\bin\java.exe" -version
 & "$env:JAVA_HOME\bin\javac.exe" -version
 java -version
 javac -version
 where.exe java
 where.exe javac

In PowerShell, %JAVA_HOME% is not the environment-variable syntax. Using where.exe explicitly also avoids confusion with PowerShell’s where alias.

A fresh process is the important requirement for reading the saved variables; changing them does not itself require reinstalling Java. Follow any separate restart request issued by the installer.

5. Compile and run a small test program​

A compilation test verifies that the compiler and runtime can work together, beyond simply printing their version numbers. The following is a self-contained test program.

1. Create a folder for the test and open Command Prompt in that folder.
2. Using a plain-text editor, save this code as HelloJava.java, ensuring the filename does not end in .txt:

 public class HelloJava {
 public static void main(String args) {
 System.out.println("Java JDK is working.");
 }
 }

1. Compile and run it:

 javac HelloJava.java
 java -cp. HelloJava

javac compiles the source file. The runtime command explicitly uses the current folder as its class path. The expected output from this example is:

Java JDK is working.

Successful compilation and execution complete the basic JDK check.

Fix missing commands, wrong versions, and installation failures​

Java works by full path but not by its short command​

If "%JAVA_HOME%\bin\java.exe" -version works but java -version fails, the JDK is accessible through JAVA_HOME; investigate command lookup instead of reinstalling immediately.

1. Reopen the environment-variable editor.
2. Confirm that Path contains %JAVA_HOME%\bin.
3. Save the dialogs and open a fresh terminal.
4. Run where.exe java and where.exe javac again.

If the short commands select another installation, inspect the earlier Java-related directories in Path. Windows searches path directories in order. Record the original order before moving entries, because changing precedence may affect older applications. Move the intended JDK entry ahead of competing Java entries in the relevant list, then retest. Do not delete unrelated paths.

JAVA_HOME prints an old folder or the explicit compiler command fails​

Check the actual directory in File Explorer. Common configuration mistakes include using the example’s x placeholders, pointing at a removed JDK folder, or appending bin to JAVA_HOME.

Inspect both user and system scopes, correct the intended value, and restart the terminal host. If the selected folder lacks bin\javac.exe, it is not the complete JDK location needed for this procedure.

WinGet cannot find the package​

Refresh the catalog and retry the package inspection:

winget source update --name winget
winget show --id Microsoft.OpenJDK.21 --exact --source winget

Microsoft documents source updates as the way to refresh repository data. If the source is blocked or unavailable on a managed network, stop and give IT the exact error rather than changing repositories or disabling security controls.

For installation failures, capture the error and open WinGet’s diagnostic logs:

winget --open-logs

Include the failed command and relevant log with an escalation. Do not share logs publicly without checking them for personal or organizational information.

Roll back the default Java selection or remove the JDK​

Before uninstalling: Confirm that no project depends on this JDK. If you only need to restore the previous default Java version, reverting the environment variables is less disruptive than removing an installation.

1. Reopen Edit the system environment variables > Environment Variables.
2. Restore the previous JAVA_HOME value you recorded. If you created it solely for this setup and no longer need it, remove that variable.
3. Restore the previous Java-related Path entries and their order. Remove only the entry you added if it is no longer required.
4. Close and reopen your terminals, then repeat the version and executable-location checks. Microsoft supports editing both user and system environment scopes through this dialog.

If you also want to remove the installed package, run:

winget uninstall --id Microsoft.OpenJDK.21 --exact --source winget

WinGet’s uninstall command targets the specified installed package. Afterward, verify that JAVA_HOME and Path no longer point to a removed directory. In a fresh terminal, run java -version, javac -version, and both where.exe checks to confirm that the intended remaining JDK is selected—or that no Java command remains available if you intentionally removed your only installation.