You've written a bit of code already, but if you've ever looked at your installation folder or a server config, you've probably seen those three acronyms: JDK, JRE, and JVM. They sound like alphabet soup, and honestly, a lot of tutorials just give you a Venn diagram and move on. I prefer to think of them as a set of nesting dolls. To really get why they exist, let's build a tiny utility called SystemProbe that tells us exactly which environment it's running in.

Drafting a Simple System Probe

I want a program that doesn't just print a string, but actually queries the environment. This helps us see the JVM in action. Here is what I'm putting in my SystemProbe.java file:

public class SystemProbe {
    public static void main(String[] args) {
        System.out.println("JVM Vendor: " + System.getProperty("java.vendor"));
        System.out.println("JVM Version: " + System.getProperty("java.version"));
        System.out.println("OS Architecture: " + System.getProperty("os.arch"));
    }
}

At this moment, this is just a text file. It's human-readable, but the computer has no idea what to do with it. To turn this into something executable, I need the JDK (Java Development Kit). The JDK is the full toolbox. It contains the compiler, the debugger, and the documentation tools. If you only had the JRE, you'd be stuck staring at this text file with no way to translate it.

Turning Source into Bytecode

Now, I'll use the Java compiler, javac, which is a tool provided by the JDK. I'll run this in my terminal:

javac SystemProbe.java

If you check your folder now, you'll see a new file: SystemProbe.class. This is the "magic" part of Java. This isn't machine code that your Intel or M1 chip understands; it's bytecode. This is why Java is "Write Once, Run Anywhere." The bytecode is a universal language that any JVM (Java Virtual Machine) can understand, regardless of whether it's running on Windows, Linux, or a toaster.

The "Command Not Found" Moment

Here is where I usually trip up when I'm switching between a development machine and a production server. I tried to run a diagnostic tool called javap (the bytecode disassembler) on a remote server to see how my code was compiled. I typed javap SystemProbe.class and got a blatant command not found error.

I panicked for a second, thinking the installation was corrupted. Then I remembered: the server only had the JRE (Java Runtime Environment) installed. The JRE is a stripped-down version of the JDK. It contains the JVM and the standard libraries needed to run a program, but it doesn't include the development tools like javac or javap. You don't want a full JDK on your production server because it's unnecessary bulk and a potential security risk. I had to remind myself: JDK is for the developer; JRE is for the user.

Executing via the Runtime

To actually see my SystemProbe work, I use the java command. This command launches the JVM.

java SystemProbe

When I run this, the JVM takes that .class bytecode, loads it into memory, and translates it on-the-fly into the specific machine code your CPU needs. The JVM is the actual engine. It handles the memory management (Garbage Collection) and ensures that the code behaves the same way on my Mac as it does on your Windows laptop.

So, to recap the nesting: The JDK includes the JRE, and the JRE includes the JVM. You write with the JDK, you distribute with the JRE, and the JVM does the heavy lifting of execution.

📋 Practical Task

Verify Environment Tooling with the JDK Disassembler

In this exercise, you will use a JDK-specific tool to prove the difference between source code and bytecode. This requires the JDK, as this tool is not available in a standalone JRE.

1. Create a file named Calculation.java with a simple method that adds two numbers and returns the result.
2. Compile the file using javac Calculation.java to generate the .class file.
3. Instead of running the program, use the JDK disassembler tool by running: javap -c Calculation.
4. Analyze the output. Look for the specific bytecode instructions (like iadd or ireturn).
5. The Challenge: Try to find the java executable and the javac executable on your system (using which java or where java). Note if they are located in the same directory and identify which one belongs to the JDK and which one provides the entry point for the JRE.