Set Up Java Properly: JDK, Environment Variables, and Your First Program

The first step in Java is not writing code — it is putting three things in the right places: a translator, an execution engine, and a lookup directory. Your .java file reads fine to humans and not at all to a machine, so a compiler (javac) translates it into bytecode (.class); that bytecode runs on any machine with a JVM, so a virtual machine (java) executes it on the spot; and neither command sits somewhere your terminal can see by default, so two environment variables have to say where they live. That is the whole article: what to install, how the system finds it, and what happens inside one command once it is found.

After this article you should be able to answer three questions:

• Am I installing a JDK or a JRE, and why does nobody install a standalone JRE anymore?
• Who reads JAVA_HOME and who reads PATH? What error does each mistake produce?
• When you type java Hello, which five things happen inside the machine, in order?

Almost every beginner gets confused here: one guide tells you to install the JDK, another mentions the JRE, and your task manager shows something called a JVM. These are not three parallel things — they are nested, like Russian dolls.

Java ships a new release every six months, but not every release deserves production use. Only LTS releases are meant for production — that is an industry rule:

Downloading from Oracle's site works, but version management gets painful. Use winget or Scoop instead — one command each:

After installation you do not need to configure environment variables by hand — package managers register everything. Manual zip installs do require Section 3.

macOS ships /usr/libexec/java_home, a built-in JDK locator that is smarter than a hard-coded path — it can pick a version when several are installed.

This is the step beginners most often copy wrong, and it is worth understanding properly. The two variables have completely different jobs:

The two chains never talk to each other, which is why "who complains when this is wrong" is impossible to memorise. Play a round instead: pick a setting on the left, then its actual job on the right — a wrong pick explains itself on the spot.

To verify, run one command — and read the capitalized version number:

Create a folder and type this in any text editor (save it as Hello.java, not the .txt Notepad suggests):

Open a terminal in that folder and run two commands:

Why the .class step? Because this is exactly how Java achieves portability: compile once, and the bytecode runs anywhere a JVM exists — that is what "write once, run anywhere" actually means.

Those five stages (find the command → load the JVM → build the classpath → load the main class → call main) read like a rhyme, but failures always land in one specific box. Spread them out as a single-step run: the six lines on the left, and on the right the variables and call stack as they change. Press step repeatedly and watch step 4 — that is where the Section 9 error is born:

In real work you may maintain a JDK 8 system in the morning and build a JDK 21 project in the afternoon. Never uninstall and reinstall to switch — use a manager:

The hard part of running several JDKs is not installing them but knowing which one is actually in charge, because three parties each follow their own rule: the shell follows PATH order, tools follow JAVA_HOME, the IDE follows its Project SDK. This animation runs the three lines side by side — pay attention to frame 6, the moment they disagree, which is exactly when "works in the IDE, dies in the terminal" is born:

"Don't let a laptop decide the build" boils down, in practice, to a few lines of pom. Rather than copying someone's, tick the boxes and watch what it emits — especially the java.version line and the three scopes:

Environment setup is hard to remember because it is path lookup you cannot see. These four kernel experiments really execute the JDK's layers in your browser, and every one lets you flip the parameter yourself.

The first unpacks "the life of one line of code". Bytecode is the intermediate language javac emits; a class loader is the role that reads .class files into memory; JIT (just-in-time) compilation is the accelerator that turns hot bytecode into machine code once the JVM notices a loop running often. Switch to "JIT tiers" and you watch the same loop get interpreted first and compiled later — that is why Java feels slow at startup and fast afterwards:

The second answers the analogy from Section 3 head-on: why a String.java of yours can never beat the JDK's String. Pick "parent delegation" to watch a request climb upward; pick "duplicate jars" to see which copy wins when two jars hold the same class — the one listed earlier in the classpath, which is exactly the root cause behind the NoClassDefFoundError row in the Section 9 table:

Flip the same mechanism around and you get the error that breaks most beginners. On "ClassNotFoundException" you literally watch the JVM walk every directory on the classpath and come back empty-handed:

The third explains something you will meet constantly from the next article on: IDEA quietly does one job before Run. Under "compile output" you see .java become .class inside target/classes; run without compiling first and you are executing stale bytecode:

The fourth experiment answers Section 3's question directly: which JDK is actually working. On "who wins" you watch the shell walk PATH and take the first hit; on "JAVA_HOME vs PATH" the two readers separate; "several JDKs installed" is the lifelike one — 8, 17 and 21 coexisting, with tools, shell and IDE each picking their own:

The order of that lookup chain is not something you absorb by reading — you have to click. This diagram splits "main library first" into five boxes:

Finally, a preview of how an application dies when the environment is wrong. It is not a one-line 'class not found' but a full screen — the triage desk below trains exactly that reading:

Once you are bored of buttons, type the commands yourself. This console talks to the same in-browser Java kernel, and every reply is computed there — start with whoami to see which JDK is live, then work through the lab envpath lines:

Steps 1 and 3 of that chain are both things you can write wrong. Change the address format on the left and the right panel immediately says who reads it and what it throws; then pick a JDK version below to see where Spring Boot and the language features each draw their line:

Every phrase in the first column can be pasted straight into a search box — do not paraphrase or shorten it:

Version mismatch is the most common half of that fused message. Here is a real stack — do not read the answer, just click the frame you think is guilty:

Goal: walk the whole "compile → run → break it on purpose → read the error" chain in a plain terminal, with no IDE involved.

Run these in order and compare the output:

Expected output (the version line follows your own JDK):

Done when: all four property lines print, and you can say out loud why java never takes a .class suffix.

Three tiny edits, one variable at a time — note what changes each time:

1. Temporarily rewrite JAVA_HOME with a trailing \bin and run mvn -v. You will observe Maven failing with The JAVA_HOME is set to an invalid directory while java -version still works — they do not read the same thing.
2. Point the classpath somewhere wrong, e.g. java -cp nonexistent EnvCheck. You will observe Could not find or load main class; replay the classpath experiment in Section 7 to see exactly which directories were walked.
3. Compile the same class twice into two folders (javac -d out1 EnvCheck.java, edit one print line, javac -d out2 EnvCheck.java), then run with -cp "out1;out2" and with "out2;out1". You will observe the printed output following the classpath order — that is "the earlier duplicate jar wins".

Tip: after variant 3, go back to the "duplicate jars" mode in Section 7 and the abstract rule suddenly becomes concrete.

Write your own environment health check script — the thing you will thank yourself for on every new machine.

• check-env.ps1 on Windows, check-env.sh on macOS / Linux
• Print at least: the real java -version, javac -version, the Maven and Java lines from mvn -v, the resolved path from where java / which java, and whether JAVA_HOME points at a root rather than bin
• Each check prints either [OK] or [FAIL] reason + one-line fix, and the script exits 0 only when everything passes
• Bonus: detect multiple installed JDKs and list them all (/usr/libexec/java_home -V on macOS, update-alternatives --list java on Linux)

Acceptance checklist: ① removing java from PATH produces a FAIL instead of a crash; ② running it on two machines pinpoints "different JDK version" from the diff alone; ③ you, three months from now, still understand those FAIL messages.