Java 10 var Keyword and Local Type Inference

Java 10 brings var to local variables and it is already changing how my editor looks during code review.

The new var keyword is short for local type inference. The compiler still knows the exact types and keeps all the strong guarantees we expect from Java. We just stop repeating ourselves when the right side of the assignment already tells the whole story. If you have the latest early builds you can try it today. With the new six month release cadence on everyone radar, this is the small but loud feature people will stare at first.

So what does local type inference cover in this first pass. It works for local variables with an initializer, for the variable in an enhanced for loop and inside try with resources. It does not touch fields, method parameters or return types. No magic at runtime. No dynamic types. Just compile time inference to remove noise when the type is obvious from the expression. That makes everyday code a little cleaner without asking us to change how we think about types.

// Java 10 var keyword in action
var names = new ArrayList<String>();
names.add("Ada");
names.add("Linus");

var ids = new HashMap<Integer, String>();
ids.put(1, "root");

// Enhanced for loop
for (var name : names) {
    System.out.println(name.toUpperCase());
}

// Try with resources
try (var in = Files.newBufferedReader(Paths.get("config.txt"))) {
    var firstLine = in.readLine();
    System.out.println(firstLine);
}

Notice how the right side gives the compiler everything. var is not a keyword you can use for method parameters or fields, and you cannot declare var without an initializer. You also cannot assign null alone because there is nothing to infer from. The goal is to trim repetition, not to hide types. The moment the right side is unclear, you will feel it during code review because the next person will scroll to find what that variable really is.

// These will not compile
// var x;                      // no initializer
// var y = null;               // cannot infer from null
// var z = { 1, 2, 3 };        // array needs 'new int[] { ... }'
// class C { var f = 42; }     // not allowed for fields
// void m(var p) {}            // not allowed for parameters

// Do this instead
var nums = new int[] { 1, 2, 3 };
var path = Paths.get("/tmp");

I like var most when the type appears twice and adds no value. Think about Map<Long, List<String>> map = new HashMap<>();. With inference, the left side becomes shorter and the right side is still clear. On the other hand, var r = service.get() feels fishy when get returns many possible things. In those spots I keep the explicit type or I rename the method or variable until the code reads like a sentence. Readability beats trends. Your future self will thank you after a long day.

Team guidelines will matter here. A few ideas I am trying with my crew. Use var when the initializer makes the type obvious by construction, like a constructor call, a literal or a static factory with a clear name. Prefer explicit types when the call site hides intent or when the type carries meaning that a name alone cannot convey. Do not create mystery by naming var x or var data everywhere. Write names that explain what the variable represents in the domain. Tests are a good place to adopt var early because setup code often repeats types that nobody cares about.

Tooling is already helping. IntelliJ IDEA, Eclipse and NetBeans show the inferred type on hover and offer quick hints in the gutter. Code style checks can warn on bad uses like var with a method returning Object. Static analysis is still static. The compiler knows the exact type no matter what we write. That means performance and bytecode stay the same, and your JVM keeps doing its job without surprises. The only change is how the source looks and how we read it during review.

If you like small refactors, var can make diffs calmer. When you replace a long generic type on both sides with a succinct var, the diff focuses on the actual logic. It also nudges us toward better API names. Methods like toList, of and newBuilder communicate types clearly, which pairs well with inference. That is a gentle push toward code that explains itself without forcing the reader to parse angle brackets at every stop.

Bottom line for today. Java 10 var keyword is a quality of life feature. Use it to cut noise, not thought. When the type helps tell the story, keep it. When the type just repeats the constructor, let local type inference do the boring part. Your code stays strongly typed, your IDE keeps you honest and your reviewers spend more time on behavior than boilerplate. That feels like a win for everyday Java, and a good sign for the next step in the language journey.

Java 10 local type inference is here to make code clear when the right side already speaks for itself.

Write for the reader, and let var carry its weight where it shines.