How Do You Install the JDK on Windows and Verify It?

Every Java program you will ever write needs two things on your machine: a compiler that turns source code into bytecode, and a runtime that executes that bytecode. Both ship together in the Java Development Kit, and installing it correctly is a fifteen-minute job that removes the most common first-day frustration for newcomers.

What exactly are you installing?

The name causes confusion. The JDK is the developer toolkit: it contains the javac compiler, the java launcher that runs your programs, and a set of smaller tools you will meet later — jshell for quick experiments, jar for packaging, javadoc for generating API documentation, and jlink for building trimmed-down runtime images. Installing the JDK gives you all of it. You do not need to hunt for a separate runtime package, and you should not install one on its own.

There is one choice to make: which distribution. Oracle supplies its own builds, Eclipse Adoptium publishes builds that are free for use in production and development, and several vendors offer their own. For learning and for commercial work, any of them will do — the language and the standard library are the same, so a program written against one runs on another. Pick the one your employer or your course uses, otherwise pick the one that is easiest to install on your system and stick with it.

How do you install it on each operating system?

The most reliable route on every platform is the official installer or the system package manager, because both put the compiler on your PATH for you. Here is the shape of each option.

# Windows — the package manager can install a maintained build directly
winget search openjdk
winget install Microsoft.OpenJDK

# macOS — Homebrew installs the current release and links javac and java
brew install openjdk
brew link --force openjdk

# Debian or Ubuntu
sudo apt update
sudo apt install openjdk

# Fedora or RHEL
sudo dnf install java-latest-openjdk-devel

On Windows the graphical installer from the vendor's site works equally well: accept the defaults, and — this is the part people miss — tick the option that sets the environment variables, or add the bin folder to your PATH yourself. On macOS, the Homebrew route needs brew link --force openjdk because the keg-only package is not linked automatically. On Linux, install the devel flavour: the plain runtime package often omits the compiler, and you will only discover that when javac is missing.

How do you verify that it worked?

Open a fresh terminal — not the one that was open before you installed, because it caches the old PATH — and ask the tools to identify themselves.

# Where are the tools?
where java
where javac

# What did we get?
java -version
javac -version

# Is JAVA_HOME set (needed by some build tools later)?
echo $JAVA_HOME

Both version commands print a single line each: the runtime reports the vendor and the build it belongs to, the compiler reports its own. What matters is that both respond without an error. A machine where java works but javac does not is the classic half-install, and it is the single most common reason a first Java program will not compile.

# what a healthy machine prints (the build details vary by vendor)

> java -version
openjdk version "<build>"
OpenJDK Runtime Environment (build <build>)
OpenJDK 64-Bit Server VM (build <build>, mixed mode)

> javac -version
javac <build>

If the shell says the command is not recognised, the bin folder is not on your PATH. That folder holds java, javac, jshell and the rest; on a typical install it lives under the JDK's own directory. Adding that one folder to your PATH fixes the problem, and the same fix resolves the confusing case where java runs but javac does not — an older runtime often shadows a newer compiler.

What usually goes wrong?

Three failures account for nearly every first-day problem. The first is a stale terminal: PATH changes only apply to new windows. The second is a half-install, where a runtime is present but the compiler is not. The third is a version mismatch, where the java on your PATH is older than the javac that compiled your class files; a program compiled against a newer standard library will fail at runtime with an error about a missing class or method, which looks like a bug in your code but is really a PATH ordering problem.

You can see which tools you are really using by printing the resolved paths, and you can see what the compiler thinks it is doing with javac -verbose on a real source file. Those two commands answer most "it worked yesterday" mysteries.

Do you need an editor or an IDE to write Java?

No. Any text editor will do, and for the first few lessons that is actually the better choice: you learn what the toolchain does because you type the commands yourself. A full IDE is excellent once your projects have many files — it manages the classpath, runs the tests, and steps through exceptions — but it hides the very commands this lesson is about. Install the JDK now, keep a plain editor open, and add an IDE when the projects outgrow single files.

Quick reference

• The JDK bundles the compiler, the runtime and the developer tools. Install the JDK.
• Verify with java -version and javac -version; both must answer.
• If a command is not found, the bin folder is missing from your PATH — add it and open a new terminal.
• On Linux, install the development package, not just the runtime package.
• Keep one distribution installed. Mixing vendors is legal but makes version problems harder to read.

Try it yourself: install the JDK, then open a terminal and record the output of where java, where javac, java -version and javac -version. Next, deliberately break your PATH for one command by running a program from a path where only the runtime exists, notice the difference, and write down which of the two tools you would trust to be the one that runs your class files.