1.2 Local Variable Type Inference (`var`) Rules and Scoping

Local Variable Type Inference (var) Rules and Scoping

Local variable type inference, introduced via JEP 286 in Java 10 and expanded in Java 11, allows developers to omit explicit type declarations by writing var. While var reduces boilerplate, it introduces nuanced compile-time mechanics, strict syntax restrictions, and scoping interactions that are primary targets for examination.

---

The Nature of var: Static Typing and Reserved Type Names

A critical misconception is that var behaves like JavaScript's dynamic variables or Python's duck typing. In Java, var maintains 100% static typing. The compiler inspects the compile-time type of the initializer expression and substitutes that exact, concrete type into the bytecode. Once compiled, the variable has a single, immutable static type.

Furthermore, var is not a keyword; it is a reserved type name. This design choice ensures backwards compatibility with legacy codebases:

int var = 100; // Legal! 'var' can be used as a variable or method identifier
void var() {}  // Legal! 'var' can be used as a method name
// class var {} // COMPILE ERROR: 'var' cannot be used as a class or interface name

---

Where var Is Permitted

Java allows var in exactly five contexts, all tied to local execution scopes:

1. Local variables with an immediate initializer:

   var message = "Hello, Java 17!"; // Inferred as java.lang.String
   var count = 42;                  // Inferred as int
   

2. Enhanced for loops (for-each):

   List<String> names = List.of("Alice", "Bob");
   for (var name : names) {         // Inferred as String
       System.out.println(name.toUpperCase());
   }
   

3. Traditional index-based for loops:

   for (var i = 0; i < 10; i++) {   // Inferred as int
       System.out.print(i);
   }
   

4. Try-with-resources variable declarations:

   try (var fis = new FileInputStream("app.log")) { // Inferred as FileInputStream
       int data = fis.read();
   }
   

5. Lambda formal parameters (Java 11+): When using var in lambda parameter lists, all parameters must use var. This syntax exists primarily to apply annotations to inferred lambda parameters:

   BiFunction<Integer, Integer, Integer> add = (var x, var y) -> x + y; // Legal
   // BiFunction<Integer, Integer, Integer> mix = (var x, int y) -> x + y; // COMPILE ERROR: cannot mix var with explicit types
   

---

Where var Is Strictly Forbidden

The compiler rejects var in any position where type information cannot be immediately resolved from a right-hand initializer, or where public API contracts require explicit typing:

---

Type Inference Mechanics and Advanced Nuances

The Diamond Operator (<>) Pitfall

When var is combined with the diamond operator new ArrayList<>(), there is no left-hand type to supply the generic type parameter. In this scenario, the compiler defaults the generic type argument to Object:

var list = new ArrayList<>(); // Inferred as ArrayList<Object>!
list.add("Java 17");
list.add(42);

// String s = list.get(0); // COMPILE ERROR: list.get(0) returns Object, cannot assign to String
Object obj = list.get(0);  // Compiles successfully

// Correct approach to infer ArrayList<String>:
var stringList = new ArrayList<String>(); // Inferred as ArrayList<String>
String s = stringList.get(0);             // Compiles successfully

Non-Denotable Types and Anonymous Classes

Because var infers the exact compile-time type, it can capture non-denotable types that cannot be named in standard Java source code. A prominent example is an anonymous class instance. With explicit typing, assigning an anonymous class instance to Object hides all fields and methods declared inside the anonymous body. With var, the compiler infers the anonymous subtype itself:

var point = new Object() {
    int x = 10;
    int y = 20;
    int distance() { return x + y; }
};

System.out.println(point.x);          // Compiles! Prints 10
System.out.println(point.distance()); // Compiles! Prints 30

If Object point had been used, point.x would fail compilation because x is not a member of Object.

Reassignment and Type Compatibility

Once a variable is declared with var, its inferred type is immutable. Assigning a value of an incompatible type causes a compile-time error:

var number = 10;   // Inferred as int
number = 20;       // Valid: 20 is an int
// number = "ten"; // COMPILE ERROR: incompatible types: String cannot be converted to int
// number = 3.14;  // COMPILE ERROR: incompatible types: possible lossy conversion from double to int

---

Scope and Variable Shadowing

Local variables declared with var obey standard Java block-scoping rules:

• A local variable exists from the moment it is declared until the closing brace } of its enclosing block.
• Java forbids variable shadowing between local blocks in the same method. You cannot redeclare a variable name if it was already declared in an enclosing scope within that method:

public void testScope() {
    var x = 10;
    {
        // var x = 20; // COMPILE ERROR: variable x is already defined in method testScope()
    }
}

However, a local variable (declared with or without var) can shadow an instance or static field of the surrounding class:

public class ShadowDemo {
    int count = 100; // Instance field

    public void show() {
        var count = 5; // Valid: local var shadows the instance field
        System.out.println(count);      // Prints 5 (local variable)
        System.out.println(this.count); // Prints 100 (instance field accessed via this)
    }
}