5 things we learned about var in Java at Code One

Since local variable type inference was introduced in Java 10, there has been a lot of debate, and a lot of people don’t like it:

At Code One this year there have been loads of talks about var, most notably by Venkat Subramaniam and Stuart Marks. My key takeaways are that sometimes it makes code less readable, and it is probably not worth spending time refactoring old code to use var. But when writing new code, it can be a nice way to remove boilerplate code and in some cases can actually improve readability:

var hashMap = new HashMap<String, Integer>();

Here are 5 points about var that came up at Code One:

1. Java already had type inference before Java 10

There has been a lot of talk about the introduction of type inference in Java 10. But type inference is not actually new to Java. Since Java 8 came out in 2014, we have been able to use type inference in lambdas. For example:

BinaryOperator<Integer> add = (x, y) -> x + y;

In this example x and y are integers, but we never explicitly say that they are – the compiler infers this for us.

It is only the ability to use type inference for local variables that is new in Java 10.

2. Var is not a reserved keyword in Java

Var is not reserved. So if you really wanted to annoy your colleagues you could put this in your code:

var var = 7;

And the code will compile and run.

3. You can write bad code with var, but you can write bad code without var

One of the most common complaints about var is that it will allow programmers to write unreadable code.

This is definitely possible, for example it would be a bad idea to do something like this:

var x = getSomething();

When you read this line of code there is no way to tell what type x is.

But it might be a better idea to teach someone not to do this than to not use the feature. It can still be a good idea to use var when the right hand side is a method call.

An example of a good place to use var would be here:

var inputStream = socket.getInputStream();

You can probably guess from looking at the context that inputStream is of type InputStream.

4. Var is not a move towards dynamic typing

Java is still very much statically typed and the introduction of var is not a move towards dynamic typing.

Even though the type is inferred, there is still a static type. When I say:

var x = 7;

the variable x is not of a type called ‘var’. Is it still a variable of type int, and it is still statically typed. We are just telling the compiler to work out the type from the context. This is very different to ‘var’ in Javascript.

So Java is not moving towards becoming a dynamically typed language, and is not turning into Javascript.

5. In Java 11 you can use var in lambda expressions

In Java 10 you can do this:

BinaryOperator<Integer> add = (x, y) -> x + y;

But in Java 11 you can do this:

BinaryOperator<Integer> add = (var x, var y) -> x + y;

But why would you do that? One reason is if you want to add annotations, you need to specify the type. E.g. you can do:

BinaryOperator<Integer> add = (final var x, final var y) -> x + y;

You would not be able to add ‘final’ without the var.

Are you using var yet? What do you think of it?

Our software libraries allow you to