JDK vs JRE vs JVM Internals — Interview Questions
⚡ Short Answer
The JDK is the toolchain that compiles and packages (javac, jlink, javap, jshell); the JRE is the runtime = JVM + core libraries; the JVM is the execution engine that loads bytecode, verifies it, interprets it, and — once code is hot — JIT-compiles it to native machine code via tiered compilation (C1 → C2). Modern Java has no standalone JRE download: you ship a trimmed runtime image built with jlink.
☕Coffee Chat Question
Concept Made Simple
“Beyond the definitions, what actually happens between javac and native execution across the JDK, JRE and JVM?”
🧠Mind Map Answer
Remember It Faster
Think of three layers stacked by responsibility: JDK builds it, JRE runs it, JVM executes it. javac never produces machine code — it produces portable bytecode (.class), and the JVM turns that into native instructions at runtime.
Tiered compilation: methods start interpreted (fast startup), get profiled, then the C1 (client) and C2 (server) compilers produce increasingly optimised native code for the hot ones. That's why a JVM app speeds up after warm-up.
Key takeaway: the JVM is not just a container — it's a profiling, self-optimising runtime. 'Write once, run anywhere' is the JVM's doing, not the compiler's.
⌨️Hands-on Keyboard
Learn by Doing
# JDK compiles source -> portable bytecode (not native code)
javac Hello.java # produces Hello.class
# Inspect the bytecode the JVM will actually run
javap -c Hello # disassemble methods
# See tiered JIT decisions at runtime
java -XX:+PrintCompilation Hello
# Build a small, JRE-free custom runtime image (replaces the old JRE)
jlink --add-modules java.base --output myruntime🔥What If?
Think Beyond the Expected
If bytecode is portable, why is the JVM platform-specific?
Because the JVM is the layer that maps portable bytecode onto a specific OS/CPU — memory model, threading, and JIT code generation are all native. You download a different JVM build per platform, but the same .class/.jar runs on all of them. Portability lives in the bytecode contract; the JVM absorbs the platform differences.
😂Real World
This shows up in Docker sizing and cold-start tuning: teams ship a jlink'd runtime image (tens of MB, no full JRE) and tune warm-up because tiered compilation means the first thousand requests run interpreted/C1 before C2 kicks in — which is exactly why benchmarks must warm up before measuring.
🎯Interviewer's Expectation
Keywords they're listening for:
⚠️Common Mistakes
- ✗Saying javac produces machine code
- ✗Treating the JVM as a passive sandbox rather than a JIT compiler
- ✗Assuming a full JRE still ships with modern JDKs
✅Best Practices
- ✓Build slim runtime images with jlink for containers
- ✓Warm up before benchmarking (let C2 compile hot paths)
- ✓Use javap/PrintCompilation to reason about performance
🔁Follow-up Questions
- 1What does the bytecode verifier check and why?
- 2How does C2 decide a method is 'hot'?
- 3What's the difference between AOT (GraalVM native-image) and JIT?
🧩Related Technologies
Continue Learning with AI
Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.
Plain-language foundations
I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner. Topic: JVM Internals (Advanced Java) Interview question: "Beyond the definitions, what actually happens between javac and native execution across the JDK, JRE and JVM?" Please: 1. Explain the core idea in simple, plain language, using an everyday analogy. 2. Define any technical terms you use. 3. Walk through one small, concrete example. 4. Finish with a single sentence I can easily remember. Keep the tone friendly and assume I'm new to this topic.
Was this answer helpful?
⭐ Featured Products
Support our platform by exploring our recommended products.
As an Amazon affiliate, purchases through these links may earn us a small commission — at no extra cost to you. It helps keep Full Stack Interview Guru free.