Local Variable Type Inference with var

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Type inference

The compiler working out a type for you from the surrounding code, instead of you writing it.

var

A word you write in place of a local variable's type, asking the compiler to infer it from the initializer.

Initializer

The value after = in a declaration, such as 10 in var count = 10;.

Local variable

A variable declared inside a method, constructor or block. Only these can use var.

Static typing

Every variable's type is fixed when the code is compiled. var keeps this: the type is inferred once, then fixed.

Diamond

The empty <> after a generic class name, as in new ArrayList<>(), asking the compiler to infer the type arguments.

Reserved type name

A word that can't be used as a class name but can still be used for variables and methods. var is one.

Target type

The type the surrounding code expects for an expression. Lambdas need one, and var can't supply it.

1. 1

   Prove the type with behaviour

   In the first example, add var half = count / 3; and print it. Predict first: count is 15 at that point and both sides are int, so the answer is 5. Then change it to var half = count / 3.0; and predict again (5.0).

2. 2

   Make var refuse

   Add var nothing; on a line of its own and compile. Then try var empty = null;. Read both error messages: each one says why there was nothing to infer from.

   terminalcopy cmd

   $ javac Main.java

   ── expected output ──

   Main.java:3: error: cannot infer type for local variable nothing

   var nothing;

   ^

   (cannot use 'var' on variable without initializer)

   1 error

3. 3

   See that the bytecode is the same

   Write a class with int a = 1; and compile it, then change it to var a = 1; and compile again. Run javap -c Main both times and compare: the instructions are identical (iconst_1, istore_1).

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

public class Main {
    public static void main(String[] args) {
        var price = 10;
        price = 12.5;
    }
}

public class Main {
    var count = 0;
    public static void main(String[] args) {
    }
}

1. 1

   var works only for local variables that are initialized on the same line: var count = 10;. The compiler looks at the type of the initializer (10 is an int) and uses that exact type as if you had typed int count = 10;. This is called type inference.

2. 2

   var does not make Java dynamic. The type is chosen once, at compile time, and never changes. After var count = 10;, the line count = 12.5; is still an error, because count is an int. The class file is identical to the one you'd get by writing the type yourself: var leaves no trace in the bytecode.

3. 3

   The inferred type is exactly the initializer's type, which matters for literals: var n = 5; is int (not byte or long), var d = 5.0; is double, var f = 5.0f; is float, var big = 5L; is long, var c = 'A'; is char. With generics, var list = new ArrayList<>(); infers ArrayList<Object>, because the diamond has nothing to go on; write new ArrayList<String>() instead.

4. 4

   Where var is not allowed: fields, method parameters, method return types, a declaration with no initializer (var x;), an initializer of null, an array initializer (var a = {1, 2};), a lambda or method reference with no target type, and several variables in one statement (var a = 1, b = 2;). Each of these gives the compiler nothing exact to infer from, or var was deliberately kept local.

5. 5

   Where var is allowed and useful: ordinary locals, the index of a classic for loop, the variable of an enhanced for loop (for (var entry : map.entrySet())), resources in try-with-resources (Topic 7.6), and, since Java 11, lambda parameters ((var a, var b) -> a + b), which mainly exists so you can put annotations on them.

6. 6

   var is a reserved type name, not a keyword. Old code that used var as a variable or method name still compiles (var var = "ok"; is legal), but no class or interface may be named var any more. The style rule most teams follow, from OpenJDK's own guidelines: use var when the right-hand side shows the type (new, a factory method with a clear name, a literal), and spell the type out when it would make the reader guess.

• ↔

  var removes noise from long generic declarations and keeps the variable name at a fixed column, but it hides the type; that is a gain when the right side shows the type and a loss when it doesn't.

• ↔

  var gives the concrete type (ArrayList), while an explicit declaration can choose an interface (List); the interface keeps later code from depending on implementation details.

• ↔

  With literals, var silently picks int or double; writing the type makes the numeric range visible, which matters for sums and money.

• I can say exactly where var is allowed and where it isn't.

• I can predict the inferred type of literals and new expressions.

• I know var is resolved at compile time and leaves no trace in bytecode.

• I avoid the new ArrayList<>() trap with var.

• I can decide when var helps readability and when an explicit type is better.