Is there auto type inferring in Java?

The journey of type inference in Java

Pre-Java 10: The verbosity era

Before the Renaissance of type inference in Java 10, we were mostly dealing with explicit type declarations. They were functionally elegant, but aesthetically... let's say verbose.

List<String> verbosityEnsureList = new ArrayList<String>(); // And they say, Java code is 'expressive'


Java 7 gave us the diamond operator (<>), offering some relief from the verbosity.

List<String> lessVerboseList = new ArrayList<>(); // Less typing, more coffee!


The leap with Java 8: Lambda expressions

Java 8 gave us lambda expressions and method references, and for a moment, Java started to resemble our fantasy of a less verbose language.

// Classical dance :
new Thread(new Runnable() {
    public void run() {
        System.out.println("Running like a Cheetah!");
    }
}).start();

// Hip Hop:
new Thread(() -> System.out.println("Running like a Cheetah!")).start();


Features likeforEach and method references like System.out::println took type inference to another level. We were closer to having readable, less verbose code.

Java 10+: 'var' changes the game

In Java 10, var was introduced, applying type inference to local variable declaration, and changing our lives for good.

// That old lengthy path:
ArrayList<String> list = new ArrayList<String>();

// Taking users to the future: Java 10+
var list = new ArrayList<String>(); // Keep it short and simple!


This reduces verbosity, enhances productivity, and improves code clarity.

Best practices and pitfalls

Strike the balance between readability and auto-deduction

While var may be your new best friend, remember that a wise friend is one who knows when to give you space. Use var when the type is evident from the context, but avoid it when explicit typing enhances readability and understanding.

var message = "Emerald hills"; // Evident that it's a String

// Compare this
var e = new Employee(); // What's 'e'? Exponent? Elephant?

// With this
Employee employee = new Employee(); // Now we're talking!


'var' isn't a silver bullet for generics

Use var to simplify complex generic types but be sure not to make the code overly obfuscated. Junior developers won't appreciate figuring out a Map<String, List<Map.Entry<String, Integer>>> that turned into a simple var.

Picky with the places it visits

var is a picky keyword; it sticks to local variable declarations inside methods. It doesn't go visiting class fields, method return types, or parameters. Moreover, when it comes to variable initialization, var insists on being present so that it can infer the type. Uninitialized variables are a no-go!

var name; // Nope
var emptyList = null; // Still nope
