Java 10 var — Local Variable Type Inference
Fast recall
Quick revision
Core answer
var list = new ArrayList(); instead of ArrayList list = new ArrayList(); . `var` is NOT dynamic typing — the type is fixed at compile time; var x = 1; declares an int, and you can't later assign a String. It only works for local variables with initializers, for-loop variables, and try-with-resources. It does NOT work for fields, method parameters, return types, lambda parameters (without types), `null` initializer alone, or array initializers without `new`. The key trade-off is readability: var shines when the type is obvious from the initializer (var users = userRepo.findAll(); — clearly List) but hurts when the type is non-obvious (var result = service.process(); — what's result?). The Java community guidelines (Oracle's style guide by Stuart Marks) say: use var when it makes code clearer, skip it when the explicit type adds signal. It's especially useful with long generic types (Map>> ) and with diamond operator (var map = new HashMap>(); — no redundancy). Java 11 added `var` in lambda parameters specifically to allow annotations like @NonNull.Whether the candidate knows `var` is compile-time (not dynamic), where it works and doesn't, and the readability trade-offs from Oracle's style guide
Thinking `var` makes Java dynamically typed. Using `var` where the type is non-obvious. Trying to use `var` for fields or method parameters. Declaring `var x = null;`
Cite Stuart Marks' official style guide (G1 through G7), discuss the `var` + diamond interaction, mention Java 11's lambda-parameter `var` for annotations, and explain the interaction with intersection types
Interview-ready guide
Interview answer
var (Java 10, JEP 286) is local variable type inference — the compiler infers the type from the initializer's static type, so you write var list = new ArrayList instead of repeating the type.
Critical point: `var` is NOT dynamic typing
- The type is fixed at compile time
var x = 1;declares anint; you can't later assign a String- Same type safety as explicit types, just less typing
- Like Kotlin/Scala/C#'s
var, not like JavaScript/Python
Where `var` works
- Local variables with an initializer
- For-loop variables and for-each
- Try-with-resources
- Java 11+: lambda parameters (for annotations like
@NonNull)
Where `var` doesn't work
- Fields (class-level)
- Method parameters
- Method return types
- Without an initializer (
var x;fails) var x = null;— null alone has no type- Array initializer without
new - Bare lambda without target type
The readability trade-off
Good uses — type obvious from initializer:
var users = userRepo.findAll();— obviously Listvar now = Instant.now();— obviously Instantvar map = new HashMap— no redundancyvar total = BigDecimal.ZERO;— obviously BigDecimal
Bad uses — type non-obvious:
var result = service.process();— what is result? Forces reader to jump to definitionvar config = load();— no signalvar items = compute();— lost all type info
Oracle's official style guide — Stuart Marks' 7 guidelines
- 1Take advantage of the initializer — make the RHS expressive
- 2Minimize scope —
varworks best in short lifetimes - 3Use when initializer is clear
- 4Use to break up chained expressions with named intermediates
- 5Don't worry too much about 'programming to the interface' for locals
- 6Beware of diamond on RHS —
var list = new ArrayList<>();isArrayList - 7Take care with literals —
var x = 1;isint, notlong
Especially useful for
- Long generic types:
Mapbecomesvar - Intersection types:
var s = (Serializable & Comparable— couldn't name this type otherwise) "hello"; - Tight scopes inside methods
Java 11's lambda-parameter `var`
- Added specifically to allow annotations on inferred-type lambda params
(@NonNull var s) -> process(s)— annotations with inference- All params must use
varor none (no mixing) - Mostly useful for NonNull/Nullable; otherwise bare inference is cleaner
Team conventions
- Some ban
varoutright for stability - Some require explicit types for API-facing code
- Some use freely with IDE inferred-type hints
- Decide as a team, be consistent
- Modern IDEs show inferred types on hover
Pitfalls
- Diamond trap:
var list = new ArrayList<>();→ArrayList - Literal ambiguity:
var x = 0;is int; want long? write0L - Refactor sensitivity: changing the method signature changes the inferred type — locally fine, but watch for downstream assumptions
Recommendation: Use `var` liberally when the type is obvious from the initializer — var users = userRepo.findAll();, var map = new HashMap, var now = Instant.now();. It removes redundancy and reads better. Skip `var` when the type isn't obvious — var result = service.process(); forces readers to jump to definitions, which is worse than just spelling out the type. Follow Oracle's official style guide (Stuart Marks' G1–G7): the underlying principle is that var is for clarity, not terseness. Watch the diamond trap: var list = new ArrayList<>(); infers ArrayList; either specify the generic type on the RHS or don't use var. For fields, parameters, and return types, var isn't allowed anyway — spell out the type there for stability and API documentation. Remember it's compile-time inference, not dynamic typing — same safety guarantees, just less keyboard.
Java 10 `var` — Local Variable Type Inference
Direct Answer
var (Java 10, JEP 286) enables local variable type inference — the compiler infers the variable's type from the initializer's static type, so you write var list = new ArrayList<String>(); instead of ArrayList<String> list = new ArrayList<String>();. var is NOT dynamic typing — the type is fixed at compile time; var x = 1; declares an int, and you can't later assign a String. It only works for local variables with initializers, for-loop variables, and try-with-resources. It does NOT work for fields, method parameters, return types, lambda parameters (without types), null initializer alone, or array initializers without new. The key trade-off is readability: var shines when the type is obvious from the initializer (var users = userRepo.findAll(); — clearly List<User>) but hurts when the type is non-obvious (var result = service.process(); — what's result?). The Java community guidelines (Oracle's style guide by Stuart Marks) say: use var when it makes code clearer, skip it when the explicit type adds signal. It's especially useful with long generic types (Map<String, List<Map<String, Integer>>>) and with diamond operator (var map = new HashMap<String, List<Integer>>(); — no redundancy). Java 11 added var in lambda parameters specifically to allow annotations like @NonNull.
Common Mistakes & Pitfalls
Thinking var makes Java dynamically typed. Using var where the type is non-obvious. Trying to use var for fields or method parameters. Declaring var x = null;
Check your understanding
Answer these without looking back at the article.
- Is `var` dynamic typing? Why or why not?
- Why can't you use `var` for fields?
- What happens with `var list = new ArrayList<>();`?
- What was the reason for adding `var` to lambda parameters in Java 11?
- How does `var` interact with intersection types?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.