JVM Compile‑Time Secrets: Syntactic Sugar and Method Dispatch

1. javac front‑end compilation steps

javac processes a .java source file in four stages:

Lexical and syntactic analysis – tokenises the source and builds an abstract syntax tree (AST).

Symbol‑table population – records classes, methods, fields and other symbols for later lookup.

Annotation processing – runs annotation processors (e.g., Lombok @Data) which may modify the AST or generate additional code.

Semantic analysis, desugaring and bytecode generation – performs type checking, removes all syntactic sugar (the "desugar" phase), and walks the AST to emit .class bytecode.

2. Syntactic sugar deep dive

Generic type erasure – Generics exist only at compile time. After compilation the type parameters are replaced by their upper bound (normally Object), and the compiler inserts a cast when an element is retrieved.

List<Order> orders = new ArrayList<>();
List<String> names  = new ArrayList<>();
System.out.println(orders.getClass() == names.getClass()); // true

Consequences:

Cannot create new T[] or new T() because the type T does not exist at runtime.

Cannot use instanceof List<String> – only the raw type List is available.

Generic overloads are illegal; after erasure the signatures would clash.

Static members cannot refer to a class's type parameters.

Bridge methods are generated when a generic superclass method is overridden with a concrete type, preserving polymorphism.

Autoboxing / unboxing – The compiler rewrites primitive‑wrapper conversions to method calls.

Integer total = 100;          // autoboxing → Integer.valueOf(100)
int count = total;           // unboxing → total.intValue()

Integer.valueOf

caches values in the range [-128,127]. Therefore:

Integer a = 127, b = 127;   // a == b  → true (same cached object)
Integer c = 128, d = 128;   // c == d  → false (different objects)

Wrapper equality must be tested with equals(), not ==. In tight loops, using a wrapper (e.g., Long sum = 0L; and sum += i;) creates a temporary object on each iteration because the operation involves unboxing, arithmetic, and re‑boxing.

Other common sugar :

Enhanced for loops are desugared to index‑based array loops or Iterator traversals; removing elements directly inside the loop throws ConcurrentModificationException.

Varargs are compiled to an array (e.g., String[] args) at the call site.

String‑based switch is compiled to a hashCode() check followed by equals() to resolve the case.

Enums become final classes extending java.lang.Enum with static instances.

Try‑with‑resources is desugared to a try‑finally block that calls close() and records suppressed exceptions via addSuppressed.

Constant‑false branches are eliminated entirely from the generated bytecode.

3. Method‑invocation bytecode instructions

invokestatic

– invokes static methods. invokespecial – invokes constructors, private methods, and super calls. invokevirtual – invokes ordinary instance methods (virtual dispatch). invokeinterface – invokes interface methods (dynamic resolution). invokedynamic – performs runtime linkage, used for Lambda expressions and other dynamic language features.

4. Static vs. dynamic dispatch – overload vs. override

Static (non‑virtual) calls are resolved at compile time using the static type of the arguments. Example:

public void pay(Order o)   { System.out.println("普通订单"); }
public void pay(Object obj) { System.out.println("未知对象"); }
Order o = new Order();
Object obj = new Order();
pay(o);   // prints "普通订单"
pay(obj); // prints "未知对象" because the static type is Object

Dynamic (virtual) calls are resolved at runtime based on the actual object type. The JVM uses a virtual method table (vtable) to achieve O(1) lookup.

class Order { void printType() { System.out.println("普通订单"); } }
class VipOrder extends Order { @Override void printType() { System.out.println("VIP 订单"); } }
Order o = new VipOrder();
o.printType(); // prints "VIP 订单" (dynamic dispatch)

5. invokedynamic and Lambda – why Lambda is not an anonymous inner class

When the compiler sees a Lambda expression, it generates a private static method that contains the Lambda body and emits a single invokedynamic placeholder at the call site.

At the first execution of the invokedynamic instruction, the bootstrap method LambdaMetafactory.metafactory() runs.

The bootstrap method dynamically creates a class that implements the target functional interface (e.g., Consumer) and returns a CallSite linking the call site to that implementation.

Subsequent executions reuse the same CallSite, avoiding repeated class generation.

This design postpones the implementation decision to runtime, preventing the compiler from emitting a separate class file for each Lambda (which would inflate the classpath) and leaving room for future JVM optimisations.

Lambda uses invokedynamic from JDK 8 through JDK 17; method references such as System.out::println follow the same path.

6. Quick recap

javac front‑end: lexical analysis → AST → symbol table → annotation processing → desugaring → bytecode.

Generics are erased; limits include no new T[], no generic overloads, and the need for bridge methods.

Autoboxing caches [-128,127]; compare wrappers with equals(); avoid boxing in hot loops.

Five invoke instructions differentiate static vs. virtual calls.

Static dispatch (overload) uses compile‑time types; dynamic dispatch (override) uses runtime types via the vtable.

Lambda is implemented with invokedynamic, not as an anonymous inner class, reducing class‑file count and enabling runtime‑chosen implementations.