You installed a JDK. You opened a terminal, typed java -version, and got a clean reply. Then you opened a second terminal, or an IDE, or a build script, and got “java is not recognized” or, worse, a different version number entirely. Same machine. Same install. Two outcomes.
This is one of the most common and most misdiagnosed problems on a Windows dev box. The install is almost never broken. What is broken is the environment the process inherits when it starts. Once you understand what actually differs between those two terminals, the fix takes two minutes.
Every process gets its own copy of the environment
On Windows, environment variables are not a single shared global. Each process receives a block of them at launch, copied from its parent. A terminal that was already open when you installed the JDK never saw the change. A terminal you open after the install does.
So the first question is not “is the JDK installed?” It is “when was that window created, and by what?”
- An old cmd or PowerShell window opened before the install: stale copy, no updated PATH.
- A new window opened from Explorer after the install: fresh copy, should see the change.
- An IDE launched from a pinned taskbar shortcut before a system reboot: may hold an old copy if it was started as a background process.
Close the window and open a new one. If the problem vanishes, that was it. If it persists, keep reading.
User PATH vs System PATH: two lists that get merged
Windows keeps PATH in two places. There is a per-user PATH and a machine-wide System PATH. The effective PATH for a process is the System list followed by the User list, merged at process start.
This matters because installers are inconsistent about which one they touch. Some write to System PATH (needs admin). Some write to User PATH (no admin). If you installed the JDK for one user and are now running a terminal as a different user, or elevated as Administrator, you get a different merged PATH.
Test it. Open a normal terminal and run where java. Then open one “as Administrator” and run the same command. If the results differ, you are looking at two different PATH resolutions, and you now know which shell is missing the entry.
A concrete check I use: from a normal prompt, print the environment and look at the order.
echo %PATH%Or in PowerShell:
$env:PATH -split ';'Scan for your JDK’s bin directory. If it is there in one terminal and not the other, you have your answer. If it appears in both but the resolved version still differs, the problem is ordering, not presence: something earlier in PATH is answering first.
“Works in one terminal” often means “works in one shell”
cmd, PowerShell 5.1, PowerShell 7, Git Bash, and the integrated terminal inside VS Code or IntelliJ do not all read the same startup files. Git Bash reads your .bashrc and .bash_profile. PowerShell reads your profile script. cmd reads nothing extra.
If you set JAVA_HOME or appended to PATH in a shell profile, only that shell sees it. Open a different shell and it is gone. This is the single most common cause of “it works in the terminal I always use and nowhere else.”
The fix is to stop putting JDK configuration in shell profiles and put it where Windows itself reads it, so every child process inherits the same values. Set JAVA_HOME as a real system or user environment variable through the Windows Environment Variables dialog, not in a profile script.
The IDE launches with the environment it inherited
When you launch an IDE from the Start menu or a taskbar pin, it inherits environment variables from Explorer, which is a long-running process. If you changed PATH after Explorer started, Explorer still holds the old block. The IDE inherits the old block. The IDE’s built-in terminal inherits it too.
You can see this clearly. Change the PATH, then open a new cmd from Start. It sees the new value. Open the IDE and check the version inside its terminal, and it sees the old one. The IDE is not wrong; it is faithfully passing along what its parent gave it.
Two fixes. Either log out and back in (or reboot) so Explorer gets a fresh environment, or launch the IDE in a way that picks up current values. In practice, a reboot after JDK config changes is the least surprising path. It is annoying. It is also reliable.
If a package manager installed the JDK, the manager owns the PATH
If you installed the JDK via a package manager or a version manager (Scoop, Chocolatey, or a Java-specific tool), the manager may inject shims or its own paths, and different shells may resolve them differently depending on shell initialization. A shim on System PATH can shadow the directory you expect to win. Run where java and look at which path comes back first. If it is not the one you intended, fix the ordering, not the install.
This is the same class of problem as keeping multiple Java versions installed: the winner is decided by PATH order at process launch, so two terminals can legitimately disagree if they start from different parent environments. If you have more than one JDK on the machine, treat PATH ordering as the primary lever.
A short diagnostic sequence
- In each terminal, run
where java. Compare the first path returned. That is the JDK actually being used. - Run
echo %JAVA_HOME%(or$env:JAVA_HOMEin PowerShell). If it is empty in one and set in the other, the variable is coming from a shell profile, not from Windows. - Open a fresh cmd from Start. If it agrees with one terminal but not the other, the disagreeing terminal is stale. Close and reopen it.
- If a fresh cmd still disagrees with the IDE, reboot or re-login so Explorer refreshes, then relaunch the IDE from a fresh process.
- If
where javareturns the right path in every terminal but the version is still wrong, check for shims or duplicate JDK directories earlier in the list. The version follows whatever resolves first.
What not to bother with
Do not reinstall the JDK. If one terminal can run it, the files are fine. Reinstalling does not fix an inheritance problem and it gives you a clean excuse to introduce a new problem.
Do not disable your antivirus to “let the install finish.” That advice shows up in install guides for some software, but it is not relevant here: the JDK is on disk and executing in at least one shell, so it was not blocked. Leave real-time protection on.
Do not add the same JDK bin directory to both User PATH and System PATH. Duplicate entries make where noisy and hide ordering mistakes.
The mental model that ends the confusion
A terminal is not a window onto a single global truth. It is a process that was handed a snapshot of PATH and JAVA_HOME at the moment it launched. Compare two terminals by comparing their parents, not their installs. One parent was Explorer started this morning with an old snapshot; another was a fresh shell spawned after the change. That is the whole story.
When something works in one terminal and not the other, the JDK is almost never the variable. Time of launch, parent process, which user profile, and which shell startup files were read: those are the variables. Check those four and the diagnosis is usually done before you have opened the Environment Variables dialog.