The JVM (Java Virtual Machine) is the runtime engine that executes bytecode — it interprets or JIT-compiles .class files to native machine instructions. The JRE (Java Runtime Environment) packages the JVM with the core class library (rt.jar) needed to run Java applications. The JDK (Java Development Kit) adds development tools like javac, javadoc, jdb, and jar on top of the JRE. If you are writing code, you need a JDK. If you are only running an app, the JRE suffices.

Yes — a JRE alone can run any compiled Java application (bytecode in .class or .jar files). The java launcher is part of the JRE. However, you cannot compile Java source code with only a JRE because javac is a JDK tool. A JDK includes the JRE, so with a JDK installed you can both compile and run Java programs.

HotSpot (Oracle, Eclipse Temurin) is the most widely used — it features tiered compilation with aggressive JIT optimizations and the widest range of GC algorithms (Serial, Parallel, G1, ZGC, Shenandoah). OpenJ9 (Eclipse) emphasizes fast startup and lower memory footprint, originally from IBM's J9 JVM. GraalVM (Oracle) adds ahead-of-time (AOT) compilation via native image, plus polyglot support for running JavaScript, Python, and Ruby alongside Java.

The JVM provides platform independence — the same .class bytecode runs on Windows, Linux, macOS, and embedded devices without recompilation. It also offers memory safety (no dangling pointers), security sandboxing for untrusted code, and dynamic class loading. The JVM's abstraction lets developers focus on portable code while JVM implementers optimize for each platform's hardware. JIT compilation at runtime can also apply CPU-specific optimizations that static compilation cannot anticipate.

Use the jlink tool to assemble a custom runtime image containing only the modules your application requires. First, determine your application's module dependencies with jdeps --print-deps myapp.jar. Then run: jlink --add-modules java.base,java.logging,java.sql --output myruntime. This produces a minimal image with only the specified modules, dramatically reducing size — useful for Docker containers where a full JDK/JRE would be wasteful.

The JDK ships as a superset of the JRE because developers also need to run applications during development — debugging, testing, and executing sample code are daily activities. Including the JRE means a single JDK installation handles both roles. You can think of it as: JDK = JRE + compilation tools. If you install only the JRE, the javac binary is simply not present in $JAVA_HOME/bin.

A JRE is a stripped-down runtime — it contains the JVM, core class library (rt.jar), and native libraries. A JDK adds the compiler (javac), debugger (jdb), profiler, documentation generator (javadoc), and build tools. In practice, JDK installations are 2–3x larger because they include all development binaries. For production servers running only compiled applications, the JRE (or a custom jlink image) is preferred to reduce footprint and attack surface.

JDK SE (Standard Edition) is for general-purpose desktop and server applications — it is what most developers install. JDK EE (Enterprise Edition) was deprecated in 2018; Jakarta EE is its successor for enterprise middleware and web services. JDK ME (Micro Edition) targets mobile devices, embedded systems, and IoT with a stripped-down class library and a smaller footprint VM. Most backend developers work exclusively with JDK SE, using Maven or Gradle for dependency management.

No — the Java compiler (javac) is a JDK tool, not a JRE tool. Attempting to run javac on a JRE-only machine produces bash: javac: command not found. The JRE only includes the java launcher and runtime library. For any compilation, debugging, or build activity, you need the JDK installed.

The JVM Specification defines the abstract runtime engine — bytecode instruction set, runtime memory model (heap, stack, PC registers, metaspace), thread synchronization primitives, and class file format. It does not mandate specific implementations of memory allocator, garbage collection algorithm, JIT compilation strategy, or thread scheduling. This is why HotSpot, OpenJ9, GraalVM, and Azul Zing all behave identically for the same bytecode but differ in performance characteristics, memory usage, and startup time.

OpenJDK is the open-source reference implementation of the Java SE specification, released under GPL v2 with the Classpath exception. Oracle JDK is Oracle's commercially supported distribution built on top of OpenJDK — it adds proprietary tools like Java Flight Recorder, Java Mission Control, and GraalVM Enterprise. For most use cases, OpenJDK (via Eclipse Temurin, Amazon Corretto, or Azul Zulu) is sufficient and free. Oracle JDK is chosen when commercial support and Oracle's additional tools are needed.

jlink assembles a custom Java runtime containing only the modules your application actually needs. You first use jdeps --print-deps myapp.jar to discover required modules, then run: jlink --add-modules java.base,java.logging,java.sql --output myruntime. The output is a minimal directory with a stripped-down JVM and only the JARs you depend on — often 30–60% smaller than a full JRE. This is ideal for containerized microservices where a full JDK/JRE would waste megabytes and expand the attack surface.

The javac -source and -target flags control which Java language version the compiler accepts and which bytecode version it emits. For example, -target 11 produces bytecode that any JVM 11+ can execute, regardless of whether the host JDK is 17. However, the runtime JVM must support features used — a Java 17 class file using string switches (introduced in JDK 14) will fail on a JDK 11 JVM. The bytecode version number (major.minor) is the real compatibility gate, not the -target flag alone.

GraalVM native image pre-compiles bytecode to machine code during the build phase via AOT (ahead-of-time) compilation, eliminating JVM startup and JIT warmup time. However, AOT compilation cannot apply runtime profiling data — it cannot do speculative inlining based on actual call frequencies or deoptimize and re-optimize based on runtime behavior. HotSpot's JIT compiler observes the running program and applies aggressive optimizations (inlining, scalar replacement, lock elision) that often outperform static AOT code for long-running, stable workloads.

JAVA_HOME is an environment variable that points to the JDK or JRE installation directory. Many build tools (Maven, Gradle, Ant), IDEs (IntelliJ, Eclipse), and scripts use $JAVA_HOME/bin/java or $JAVA_HOME/bin/javac to locate the Java runtime. If JAVA_HOME points to a JRE instead of a JDK, javac will be missing — you will see bash: javac: command not found when building. Tools that rely on the compiler will fail, even though java (runnable from the JRE) would still work.

The bytecode verifier is a critical security component that runs before any compiled code is executed. It checks that the .class file's instruction sequences are valid — ensuring no stack overflow, no invalid type casts, no accessing fields of objects that don't exist, and no violation of access modifiers. This prevents malicious .class files from crashing the JVM or bypassing the security sandbox. The verifier is why untrusted Java code cannot corrupt memory or escalate privileges — it is fundamentally impossible to compile a .class file that passes verification but contains unsafe operations.

Two approaches: (1) Check if javac exists in $JAVA_HOME/bin — if it does, it is a JDK. (2) From within the Java program itself, use new java.io.File(System.getProperty("java.home") + "/bin/javac").exists(). This is what the implementation snippet in this post demonstrates. Build servers and CI pipelines often use this check to fail-fast if a developer accidentally configured a JRE-only environment for a project that needs compilation.

Each LTS release removes deprecated APIs, adds new language features, and ships updated JVM implementations. JDK 8 introduced lambda expressions and the streams API. JDK 11 removed the Java EE module (JAX-WS, JAXB) and added HTTP Client (standardized in JDK 11). JDK 17 added sealed classes and pattern matching for switch. JDK 21 added virtual threads (project Loom) and record patterns. Newer LTS versions also include substantially improved GC algorithms (ZGC and Shenandoah became production-ready), better metaspace handling, and faster JIT compilers — upgrading the JVM version often yields free performance gains.

The classpath is a list of directories and JAR files that the JVM searches for class files at runtime. It is an unbounded, flat list — every JAR is examined in order until the class is found. The module path (Java 9+) enforces explicit module boundaries: each JAR must declare its module-info.java, and the module system validates reads and exports at compile and runtime. The module path prevents accidental cross-boundary dependencies and enables jlink to create minimal images. Legacy JARs without module-info still work on the classpath in "automatic module" mode, but lose the encapsulation benefits.

Yes — multiple JDK versions can be installed simultaneously in separate directories (e.g., /usr/lib/jvm/java-11 and /usr/lib/jvm/java-17). On Linux, update-alternatives --config java selects the system-wide default. On macOS, Oracle's JDK installer manages /Library/Java/JavaVirtualMachines/. SDKMAN! (sdk install java 17.0.9-temurin) and jenv are popular version managers that let you switch per-project via a .java-version file. Always ensure java -version and javac -version reference the same installation to avoid version mismatch errors.