Runtime vs Compile Time

Compile Time vs Runtime — and Why the Line Between Them Matters

Every Java program passes through two genuinely separate phases: compile time, when javac turns .java source into .class bytecode, and runtime, when the JVM actually executes that bytecode. Knowing which phase catches which category of mistake isn't academic — it determines whether a bug surfaces as a build failure your CI pipeline stops on, or as an exception in production at 3 AM. Generics are the clearest example: they feel like a runtime safety net, but they are purely a compile-time construct — the type information is erased before the bytecode is ever generated, which is exactly why certain checks that look like they should be possible at runtime simply aren't.

// BEFORE — assuming generics protect you everywhere, including through reflection
List<String> skus = new ArrayList<>();
Method addMethod = skus.getClass().getMethod("add", Object.class);
addMethod.invoke(skus, 12345);   // compiles and runs fine — reflection bypasses compile-time generics entirely
String firstSku = skus.get(0);    // ClassCastException — an Integer where a String was "guaranteed"

// AFTER — knowing generics are erased at runtime, defend where it actually matters
if (!(rawValue instanceof String)) {
    throw new IllegalArgumentException("Expected a String SKU, got " + rawValue.getClass());
}
// A runtime check, because the compiler's generic type check cannot follow you
// through reflection, raw types, or unchecked casts — it only ever existed at
// compile time in the first place.

Compile Time — What javac Actually Checks

// 1. Syntax checking
int x = 5   // Error: ';' expected

// 2. Type checking
String sku = 42;   // Error: incompatible types

// 3. Symbol resolution
System.out.printn("Hi");   // Error: cannot find symbol 'printn'

// 4. Access checking
private int internalStock;
product.internalStock = 20;   // Error: internalStock has private access

// 5. Constant folding (an optimization, not just a check)
int total = 2 + 3;   // compiled directly as: int total = 5;

Compile-time constants — inlined, not just evaluated

public class CatalogConstants {
    static final int MAX_ITEMS_PER_ORDER = 100;         // compile-time constant
    static final int RANDOM_ID = new Random().nextInt();   // NOT one — computed at runtime, every time
    static final int ABSOLUTE_MAX = MAX_ITEMS_PER_ORDER * 2;   // still a compile-time constant expression
}

// Calling code doesn't reference CatalogConstants at runtime for this value —
// the literal is inlined directly into the caller's own bytecode:
int limit = CatalogConstants.MAX_ITEMS_PER_ORDER;   // compiled as: int limit = 100;

Compile-time errors — these stop the build entirely

// Type mismatch on a generic
List<String> skus = new ArrayList<Integer>();   // Error!

// Unhandled checked exception
public void readCatalog() {
    new FileReader("catalog.csv");   // Error: unhandled IOException
}

// Missing return statement
public int getStockLevel() {
    int level = 5;
    // Error: missing return statement
}

Runtime — What the JVM Handles That the Compiler Can't

// 1. Object creation — memory is only actually allocated here
Order order = new Order();

// 2. Method dispatch — which override actually runs depends on the real object
PaymentMethod payment = resolvePaymentMethod(request);   // could be CreditCard, PayPal, ...
payment.charge(amount);   // the ACTUAL method is only known once this line runs

// 3. Array bounds checking
int[] slots = new int[5];
slots[10] = 1;   // ArrayIndexOutOfBoundsException — the compiler has no way to know this in advance

// 4. Null checks
String code = null;
code.length();   // NullPointerException — nullability isn't tracked by the type system

// 5. Class loading
Class<?> clazz = Class.forName("com.shop.PromotionEngine");   // resolved from a string, only possible at runtime

Runtime exceptions — the compiler had no way to catch these

// NullPointerException
String code = null;
code.toUpperCase();

// ClassCastException
Object obj = "discount-code";
Integer num = (Integer) obj;

// ArithmeticException
int result = 10 / 0;

// OutOfMemoryError — a resource limit, not a logic error the compiler could flag
List<byte[]> buffers = new ArrayList<>();
while (true) { buffers.add(new byte[1_000_000]); }

Type Erasure — Where "Compile-Time-Only" Has Real Consequences

Generics exist purely at compile time. By the time bytecode is generated, the type parameter is erased — this is precisely why the Section 0 example above compiles and runs without a single warning until the moment it actually reads a mistyped value back out.

// At compile time — fully type-checked
List<String> skus = new ArrayList<>();
List<Integer> quantities = new ArrayList<>();

// At runtime — both are just "List". The type parameter is gone.
System.out.println(skus.getClass() == quantities.getClass());   // true!

// This is exactly why you can't do this:
// if (list instanceof List<String>) { }   // compile error — no type info left to check
if (list instanceof List<?>) { }   // OK — the unbounded wildcard makes no claim about the erased type

Annotations — Retained for a Specific Phase, by Design

// SOURCE — discarded after compilation, never reaches the .class file
@Retention(RetentionPolicy.SOURCE)
public @interface Todo { }

// CLASS — present in the .class file, but not accessible via reflection (this is the default)
@Retention(RetentionPolicy.CLASS)
public @interface InBytecode { }

// RUNTIME — readable via reflection while the program runs
@Retention(RetentionPolicy.RUNTIME)
public @interface AuditLogged { }

// Familiar examples, by actual retention:
@Override       // SOURCE — the compiler checks it, then it's gone
@Deprecated    // RUNTIME — tools and reflection can query it
@Entity        // RUNTIME — Hibernate/JPA reads this while the application is running

Static vs Dynamic Binding

Static binding — resolved at compile time

public class Formatter {
    // Overloading — the compiler picks the matching signature
    public void print(String s) { System.out.println("String: " + s); }
    public void print(Integer i) { System.out.println("Integer: " + i); }

    public static void staticMethod() { }    // bound at compile time
    private void privateMethod() { }    // bound at compile time — can't be overridden at all
    public final void finalMethod() { }   // bound at compile time — the compiler knows no override can exist
}

Dynamic binding — resolved at runtime

class Animal {
    public void speak() { System.out.println("Animal speaks"); }
}

class Dog extends Animal {
    @Override
    public void speak() { System.out.println("Dog barks"); }
}

Animal animal = new Dog();
animal.speak();   // prints "Dog barks" — the ACTUAL runtime type decides which override runs,
                  // regardless of the compile-time declared type (Animal)

Reflection — Runtime Introspection of Compile-Time Structure

Class<?> clazz = PromotionEngine.class;

// Discover methods at runtime that were fixed at compile time
Method[] methods = clazz.getDeclaredMethods();

// Create an instance without a compile-time `new` expression
Object instance = clazz.getDeclaredConstructor().newInstance();

// Invoke a method resolved entirely by name, at runtime
Method apply = clazz.getMethod("applyDiscount", Order.class);
apply.invoke(instance, order);

// Read a RUNTIME-retention annotation — SOURCE/CLASS-retention ones are invisible here
if (clazz.isAnnotationPresent(AuditLogged.class)) {
    AuditLogged ann = clazz.getAnnotation(AuditLogged.class);
}

Reflection is exactly why the Section 0 example bypasses generic type safety: Method.invoke() accepts an Object, so the compile-time type check that would have stopped skus.add(12345) directly never gets a chance to run at all.

Practical Comparison

Best Practices and Common Pitfalls

Interview Questions