1.1 What Makes Java "Write Once, Run Anywhere"?

Java source code is never compiled directly to machine code. Instead, javac compiles .java files into bytecode (.class files) — a compact, platform-neutral instruction set for a virtual processor. Any machine with a Java Virtual Machine (JVM) can execute that bytecode, which is why the same .class file runs unmodified on Windows, Linux, and macOS.

Compilation & execution flow:

Hello.java --(javac: compiler)--> Hello.class (bytecode)
Hello.class --(java: launches JVM)--> Class Loader --> Bytecode Verifier
          --> Interpreter + JIT Compiler --> native machine code --> CPU

The platform independence of the bytecode is achieved by the platform dependence of the JVM — each OS has its own JVM implementation, but they all understand identical bytecode.

1.2 JDK vs JRE vs JVM — The Classic 5-Mark Question

Memory aid: JDK ⊃ JRE ⊃ JVM. Since Java 11, Oracle no longer ships a standalone JRE — the JDK is the standard download.

1.3 Inside the JVM — Runtime Data Areas

Advanced papers ask you to describe JVM memory areas. There are five:

1. Method Area (Metaspace since Java 8): class metadata, static variables, the runtime constant pool. Shared across threads.
2. Heap: every object and array lives here. Shared; managed by the garbage collector. Internally split into Young Generation (Eden + Survivor spaces) and Old Generation.
3. JVM Stack (per thread): one stack frame per method call, holding local variables, operand stack, and the return address. Primitive locals live here; object locals hold only a reference pointing into the heap.
4. PC Register (per thread): address of the current bytecode instruction.
5. Native Method Stack (per thread): supports native (C/C++) calls via JNI.

Memory picture in words: for Student s = new Student(); inside main, the reference variable s sits in main's stack frame; the actual Student object with all its instance fields sits in the heap; the Student class metadata sits in the method area.

1.4 The JIT Compiler — Why Java Is Fast Now

Pure interpretation (executing bytecode instruction-by-instruction) is slow. The Just-In-Time (JIT) compiler watches for hotspots — methods executed thousands of times — and compiles them to optimized native machine code at runtime, applying inlining, loop unrolling, and escape analysis. This adaptive optimization is why long-running Java servers approach C++ speed. The default JVM is literally named HotSpot.

1.5 Java Buzzwords (Features)

Simple (no pointers/operator overloading), Object-Oriented, Platform-Independent, Secure (bytecode verifier + no direct memory access), Robust (strong typing, exceptions, GC), Multithreaded (built into the language), Architecture-Neutral, Portable, High-Performance (JIT), Distributed (RMI, networking libraries), Dynamic (classes loaded on demand).

1.6 The Four Pillars of OOP — Preview

Each pillar gets its own lesson in Unit II.

1.7 Common Exam Traps

• Java is compiled AND interpreted — saying "purely interpreted" loses marks.
• The JVM is platform-dependent; bytecode is platform-independent.
• main must be public static void main(String[] args) — static so the JVM can call it without creating an object.
• Java is not 100% object-oriented because primitives (int, char, …) are not objects.

🎯 Exam Focus

1. Differentiate between JDK, JRE and JVM with a neat diagram. (5 marks — asked almost every year)
2. Explain the compilation and execution process of a Java program. What role does bytecode play in platform independence?
3. Describe the runtime data areas of the JVM. Which areas are shared among threads and which are per-thread?
4. What is JIT compilation? How does HotSpot decide what to compile?
5. "Java is both compiled and interpreted." Justify this statement.
6. Write a program that prints "Hello, University!" and explain the purpose of each word in the main method signature.