1. History of Java & Java Editions (SE / EE / ME)

1.1 What is it?

Java is a general-purpose, class-based, object-oriented programming language originally developed at Sun Microsystems, first released publicly in 1995. It was designed to let developers write code once and run it on any device without rewriting it for each platform.

Timeline (the version of history interviewers actually expect)

1.2 Java Editions — SE, EE, ME

1.3 Android Relevance

Android apps written in Java use the Java SE language and a subset of its core libraries, but they do not run on a traditional JVM — they compile to a different bytecode format run by ART (Android Runtime), previously Dalvik. This is a classic interview trap: interviewers will ask "does Android use JVM?" — the correct answer is no, Android uses ART/Dalvik with DEX bytecode, not JVM with .class bytecode, even though the source language is Java.

Interview Questions — History & Editions

2. JDK vs JRE vs JVM

2.1 What is each one?

2.2 Why does this separation exist?

End users who only need to run Java applications (e.g., running a desktop app) historically only needed the JRE — no need to ship a compiler with every machine. Developers writing/compiling code need the full JDK. This separation kept distribution lean. (Note: since Java 11, Oracle stopped shipping a separate public JRE download — you typically install a JDK even just to run apps now, though the conceptual distinction still matters for interviews.)

2.3 Internal Working / What's inside the JVM

• Class Loader Subsystem — loads .class files into memory (Bootstrap, Extension/Platform, Application loaders).
• Runtime Data Areas — Method Area/Metaspace, Heap, Java Stacks (per thread), PC Registers, Native Method Stacks.
• Execution Engine — Interpreter (executes bytecode line by line) + JIT Compiler (compiles "hot" bytecode into native machine code for speed) + Garbage Collector.
• Native Method Interface (JNI) — bridges Java code to native libraries (C/C++).

Interview Questions — JDK / JRE / JVM

3. Bytecode, Compilation Process & Execution Process

3.1 What is Bytecode?

Bytecode is an intermediate, platform-neutral instruction set stored in .class files after compilation. It is not native machine code (which is CPU-specific) and not raw source code (which is human-oriented) — it sits in between, designed specifically for the JVM to interpret or JIT-compile.

3.2 Compilation Process — Step by Step

1. Source Code (.java) is written by the developer.
2. javac (Java Compiler) compiles it into bytecode (.class file) — this step also does static type checking and catches compile-time errors.
3. The .class file contains bytecode instructions plus metadata (constant pool, method signatures, etc.) understood only by the JVM.

$ javac HelloWorld.java     <-- produces HelloWorld.class (bytecode)
$ java HelloWorld           <-- JVM loads & executes the bytecode

Example

// HelloWorld.java
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, Interview!");
    }
}

You can inspect the actual bytecode instructions using javap -c HelloWorld.class — this is an excellent thing to mention in an interview to show hands-on curiosity about internals.

3.3 Execution Process — Step by Step

1. Class Loading — the ClassLoader subsystem loads the .class file's bytecode into the Method Area of JVM memory.
2. Bytecode Verification — the Bytecode Verifier checks the code doesn't violate JVM security/structural constraints (no illegal type casts, no stack overflow at a structural level, no access violations) before it's trusted to run.
3. Execution — the Execution Engine runs the verified bytecode:
   • Initially via the Interpreter (reads and executes bytecode instructions one at a time — slower, but starts immediately).
   • The JIT (Just-In-Time) Compiler monitors "hot" methods (called frequently) and compiles them directly into native machine code, caching the result so subsequent calls skip interpretation entirely — this is what makes Java competitive in speed with natively compiled languages over time.
4. Garbage Collection runs concurrently/periodically to reclaim heap memory of unreachable objects.

3.4 JIT Compilation Tiers (deeper detail for senior-level questions)

• C1 (Client Compiler) — compiles quickly with lighter optimization, good for fast startup.
• C2 (Server Compiler) — heavier optimizations (inlining, loop unrolling, escape analysis) applied to long-running "hot" code, used in tiered compilation alongside C1.
• Modern HotSpot JVMs use tiered compilation by default — starting with interpretation, moving to C1, then C2 as a method proves itself "hot" over repeated invocations.

Interview Questions — Bytecode & Compilation/Execution

4. Platform Independence — "Write Once, Run Anywhere" (WORA)

4.1 What does WORA actually mean?

It means Java source code, once compiled into bytecode, can run unmodified on any device with a compatible JVM installed — Windows, Linux, macOS, etc. — without needing to be recompiled for each platform.

4.2 How is it actually achieved? (This is the part interviewers really want)

1. The Java compiler (javac) never targets a specific CPU — it always targets the abstract JVM bytecode format.
2. Each platform has its own platform-specific JVM implementation that knows how to translate that same bytecode into instructions that specific OS/CPU understands.
3. So the portability burden shifts from "every program must be recompiled per platform" to "only the JVM itself is written per platform" (by the JVM vendor, not by application developers).

4.3 Advantages

• Massive reduction in cross-platform development/maintenance cost.
• Enables "deploy anywhere" server environments (a huge reason Java dominates enterprise backend systems).
• Simplifies CI/CD — one build artifact (a JAR) can be tested and shipped broadly.

4.4 Disadvantages / Trade-offs

• An abstraction layer (JVM) adds overhead compared to code compiled directly to native machine code ahead of time.
• Startup time historically slower than natively compiled languages (mitigated today by tools like GraalVM Native Image and CDS/AppCDS class data sharing).
• You're dependent on a compatible JVM being available/installed on the target machine.

Interview Questions — Platform Independence

5. Java Architecture Overview

(Source → Compiler → Bytecode → JVM → Machine Code)

5.1 The Full Pipeline

 [1] MyProgram.java   (Source Code — human readable)
          |
          |  javac (compiler): syntax check, type check
          v
 [2] MyProgram.class  (Bytecode — platform-neutral instructions)
          |
          |  java (launcher) starts the JVM, which:
          v
 [3] Class Loader     -> loads .class into Method Area
          |
          v
 [4] Bytecode Verifier -> checks safety/structural correctness
          |
          v
 [5] Execution Engine
        - Interpreter (executes bytecode directly), and/or
        - JIT Compiler (compiles hot paths to native machine code)
          |
          v
 [6] Native Machine Code executed by the actual CPU

5.2 The Three Big JVM Subsystems (recap, tie-together)

Interview Questions — Java Architecture

Quick-Fire MCQs (Self-Test Before Moving to Day 3)

Mini Assignment

1. Write a "Hello World" program, compile it with javac, then run javap -c on the resulting .class file. Try to identify at least 3 bytecode instructions and guess what they do.
2. Write one paragraph (in your own words, no notes) explaining the full journey from source code to program output, as if explaining it to a fellow Android developer who has never seen server-side Java.
3. Research and note down: which JVM implementation does your current Android Studio / backend JDK use (HotSpot? Something else?), and what Java version it targets.