Mastery
Mastery/Java/G. Modern language features (8 → 21)
T1 · high-leverage

var local type inference (Java 10+)

var infers the type at compile time from the initializer -- it is NOT dynamic typing, the variable's type is fixed forever at that point, exactly as if you'd written it explicitly. It only works for local variables with an initializer (never fields, parameters, or return types), and readability guidance generally says: use it when the type is obvious from the right-hand side, skip it when the type carries real information the reader would otherwise lose.

java
var list = new ArrayList<String>();
list.add("hi");
System.out.println("inferred type is fully static, still checked: " + list.getClass().getSimpleName());

var count = 42;          // inferred as int
var label = "widgets";   // inferred as String
System.out.println(label + ": " + count);

Interview angle

A quick "is this dynamic typing?" check separates candidates who understand var from those who've only seen the keyword — the correct answer is a firm no: the type is resolved once, at compile time, from the initializer, and is exactly as fixed as if it had been written explicitly. It's also a light API-design/style question: good engineers can articulate when var helps readability versus when it hides useful type information from the reader.

In the industry

Team style guides on var usage vary widely and are genuinely debated — Google's Java style guide encourages it when the type is obvious from context (var list = new ArrayList<String>()), while discouraging it when it would obscure the type (var result = process(input) tells the reader nothing). Most linters/IDE inspections default to flagging var usages where the initializer's type isn't immediately clear from the right-hand side, rather than banning or mandating it outright.

← try-with-resources, `AutoCloseable`, and suppressed exceptions