Java var: Local Variable Type Inference
Fast recall
Quick revision
Core answer
Whether you understand that var is static inference (not dynamic typing), know where it is and isn't allowed, and can reason about readability trade-offs
Thinking var makes Java dynamically typed like JavaScript's var, or not knowing that var cannot be used with null initializers, method parameters, or fields
Discuss the readability trade-off: var is great for generic type noise (Map.Entry iteration, stream pipelines) but hurts readability when the inferred type is not obvious from context. Mention JEP 323 (lambda parameters) and how var enables annotations on lambda parameters.
Interview-ready guide
Interview answer
var is compile-time type inference — not dynamic typing. The compiler resolves the type from the right-hand side and locks it in; the variable is fully statically typed after that.
What var does:
var x = 42becomesint x = 42in bytecode — cannot later hold aStringvar entries = map.entrySet()eliminatesMap.Entrynoise — clearly an improvement- Same performance as explicit types — no runtime overhead
Restrictions:
- Local variables only — not allowed for fields, method parameters, or return types
- Cannot initialize with null — the compiler has nothing to infer from
var list = new ArrayList<>()infersArrayList— usevar list = new ArrayListto preserve the generic type()
When to use vs avoid:
- Good:
var list = new ArrayList,() for (var entry : map.entrySet()), constructor calls where the type is obvious from the right side - Avoid:
var result = process(data)— forces the reader to look upprocess()to understand the variable's type
I recommend var when the type is obvious from the right-hand side, explicit types when it isn't.
Java var: Local Variable Type Inference
Direct Answer
var (Java 10+) lets the compiler infer the type of a local variable from its initializer, eliminating verbose type repetition. The variable is still statically typed — the inferred type is fixed at compile time. var can only be used for local variables with an initializer; not for fields, method parameters, or return types.
Deep Dive & Architecture
Varargs (`Type...
args`) = syntactic sugar — compiler converts to array.
Must be last parameter, at most one per method. Can pass 0+ args or an explicit array. Heap pollution with generics (T... args) — @SafeVarargs when provably safe. Null trap: method(null) passes as null array — args.length throws NPE. Avoid combining varargs with overloading — compiler resolution can produce surprises.
Saying Java is pass-by-reference for objects because you can modify the object's fields inside a method
Common Mistakes & Pitfalls
Thinking var makes Java dynamically typed like JavaScript's var, or not knowing that var cannot be used with null initializers, method parameters, or fields
Check your understanding
Answer these without looking back at the article.
- Is Java pass-by-value or pass-by-reference?
- Varargs in Java — Variable Arguments and Heap Pollution
- What is autoboxing and unboxing in Java? What is the Integer cache trap?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.