JAVA / GETTING STARTED
Installing the JDK and choosing an editor
Install a vendor build of the JDK, confirm from the shell and from Java itself which one is active, and point your editor at that same install.
What you will learn
- Choose any OpenJDK build (Temurin, Corretto, Zulu) at an LTS release such as 21 or 25
- Verify the active JDK with java -version, javac -version and the java.home property
- Explain why PATH, not the installer, decides which java actually runs
- Set your editor's project JDK to the same directory your terminal uses
Understanding Installing the JDK and choosing an editor
Java is developed as source in the OpenJDK project, and what you download is one vendor's compiled build of that source: Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft's build, Oracle's build. For learning they are interchangeable, because the compiler and the language are the same; the differences are how long each vendor keeps patching a release and under what licence. What does matter is the feature release number, since a JDK can always compile and run code written for older releases but never read class files produced by a newer one. Pick a long-term-support release such as 17, 21 or 25 and you will not have to re-download every six months.
Installing a JDK unpacks a directory tree whose bin folder holds java, javac, jar and the other tools; nothing about it registers itself with the language. Your shell locates those programs through PATH, so when several JDKs are present the one that answers java is whichever bin directory comes first, not the one you installed most recently. JAVA_HOME is a separate convention that Maven, Gradle and many scripts read to find a JDK, and it points at the install root, the parent of bin. Because PATH and JAVA_HOME can disagree, treat java -version and the java.home system property as the only reliable answer to which JDK is active.
Choosing an editor is an independent decision, because no editor compiles Java; the JDK does. A plain text editor plus a terminal is entirely sufficient and keeps the toolchain visible, while IntelliJ IDEA Community Edition, VS Code with the Java extensions, Eclipse and NetBeans add navigation, refactoring and live error checking by running their own analysis against a JDK you select per project. That project setting is the part beginners overlook: the IDE's configured JDK and release level, not your PATH, decide what the IDE accepts, which is why one file can compile cleanly in a terminal and still show errors in the editor.
public class ShowJdk {
public static void main(String[] args) {
System.out.println("java.version = " + System.getProperty("java.version"));
System.out.println("java.vendor = " + System.getProperty("java.vendor"));
System.out.println("java.home = " + System.getProperty("java.home"));
System.out.println("feature = " + Runtime.version().feature());
}
}Installing Java means placing one chosen JDK build where your tools can find it, and almost every later setup problem is a question of which JDK is being found.
Worked examples
Full JDK or only a runtime
Asks the running installation, from inside Java, whether it carries a compiler at all.
import javax.tools.JavaCompiler;
import javax.tools.ToolProvider;
public class CompilerCheck {
public static void main(String[] args) {
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
if (compiler == null) {
System.out.println("No compiler here: this is a runtime, not a JDK.");
} else {
System.out.println("Compiler found: " + compiler.getClass().getSimpleName());
System.out.println("Full JDK, javac is available.");
}
}
}Example explained
Line 1ToolProvider.getSystemJavaCompiler() returns null when the installation has no compiler, which is exactly the situation behind a missing javac.
Line 2JavacTool is the class implementing that compiler, so javac is a library shipped inside the JDK rather than a separate program you install.
Line 3A trimmed runtime image built without the jdk.compiler module takes the null branch, which makes this a quick check when javac appears to be missing.
Version probe by compilation
Uses two language features with known minimum releases so a compile error reveals an editor pointed at an old JDK.
public class Probe {
record Point(int x, int y) {}
public static void main(String[] args) {
var p = new Point(2, 3);
System.out.println(p);
System.out.println("Compiled, so this JDK is 16 or newer.");
}
}Example explained
Line 1record Point(int x, int y) {} is accepted only from release 16 onward, so an error on that line means the JDK behind the editor is older than you assumed.
Line 2var was added in release 10, so the two lines together bracket the release your compiler is using.
Line 3Point[x=2, y=3] comes from the toString the record generates automatically, not from any formatting you wrote.
Line 4This failure appears while compiling, which distinguishes a stale editor setting from a wrong PATH, whose mismatches only show up when running.
Where the tools live
Prints the install root and derives the bin directory that must be on PATH for javac to be found.
import java.nio.file.Path;
public class WhereIsJavac {
public static void main(String[] args) {
Path home = Path.of(System.getProperty("java.home"));
System.out.println("JAVA_HOME should be: " + home);
System.out.println("PATH needs: " + home.resolve("bin"));
}
}Example explained
Line 1java.home is reported by the JVM that is actually running, so it identifies the install in use even if you have forgotten what you downloaded.
Line 2JAVA_HOME points at the install root, one level above bin, which is why build tools that read it can find both java and javac.
Line 3resolve("bin") joins the two path parts using the separator of the current operating system, so the same code prints a backslash form on Windows.
Important notes
The sample java.version, java.vendor and java.home values come from one machine, a Temurin 25 install on Linux; your strings will differ, and only the feature number should match the JDK you chose.
Oracle's builds and the OpenJDK builds from Temurin, Corretto or Zulu ship the same compiler and language, so check licence terms for commercial use but never assume a paid build is needed to learn.
Common mistakes
Installing a runtime-only package, such as an old bundled JRE or a trimmed runtime image, so java works but javac is not found and nothing you write can be compiled.
Changing PATH or JAVA_HOME and then testing in a terminal window that was already open, which still holds the old environment, leading you to conclude the install failed.
Leaving an old Java 8 first on PATH while the editor builds with 21: the class file compiles, then running it fails with UnsupportedClassVersionError reporting class file version 65.0 against a runtime that recognises only up to 52.0.
Try it yourself
Change, predict, then run
Print Runtime.version() and Runtime.version().feature() in a browser editor, then add feature + 44 to state the class file major version that release emits, and compare the feature number with what java -version reports on your own machine.
Open the Java workspaceCheck your understanding
Your terminal compiles and runs a file containing a record declaration without complaint, but your IDE marks that same line as an error. What is the most likely cause?
- The IDE's project JDK or release level is older than the JDK that your PATH points at
- The IDE needs javac installed separately, because IDE builds do not use the JDK
- Records can only be compiled from the command line, not from an IDE build
- JAVA_HOME is unset, so the IDE has no compiler available
Show answer
An IDE checks and builds against the JDK and release level configured in the project, independent of your shell's PATH, so an older project setting rejects a construct the terminal accepts. The unset JAVA_HOME option is tempting because build tools do read that variable, but a missing JAVA_HOME would break every file in the project rather than flag one declaration.