Java 10 is there! And the most controversial feature of it is the var keyword. Should you embrace it or not?
If you're a regular reader of BeyondJava.net, you probably know that I already propagated the var keywords years ago. But I'm spending enough business hours each day with Java to know how Java programmers feel. So I recommend reading and heeding the Guidelines for using the var keywords in Java 10 by Stuart W. Marks.
Does var improve the readability of the code, or does it make it worse?
Actually, I was fairly surprised there's such an emotional discussion about the var keyword. In Java, you can use it only for local variables. These variables typically have a very small scope. So in most cases, the inferred type is not a big deal to the poor guy (or gal) who's reading your source code at late hours, desperately trying to find the bug you've left to them.
As it turns out, that's the bottom line: Always think of your co-worker trying to decipher your code one or two years later. Type inference is meant to improve the readability of the code. var is a great tool to achieve this goal. Don't use it when it starts to make the code short but hard-to-read. The guidelines I've mentioned above do a great job to show examples when and when not to use var.
Experiences from other languages: Scala and TypeScript
Another reason why I'm so surprised about the emotional discussion is because var is a de-facto-standard in most modern programming languages. For instance, Scala and TypeScript both have powerful type inference. In the early days, the Scala aficionados frequently went over the top, but by not, most development teams have found a compromise between conciseness and readability that works. In TypeScript, I never heard any complaints about the evils of type inference. It just works for most teams.
Experiences from other languages: JavaScript
Let's have a look at the other extreme. JavaScript is a language that doesn't allow you to make the type explicit. Until recently, var was the only keyword they had to define a variable.
Many people were unhappy with var, but they didn't insist on adding types. Instead, they insisted on getting rid of variable hoisting. And they insisted on being able to define constants. So the current versions of ECMAScript introduced the keywords let and const.
Most of the time, the lack of explicit types doesn't affect JavaScript programmers. So it's reasonable to assume that the careful introduction of type inference to Java doesn't hurt anybody.
var doesn't make Java a dynamic language
I should add that the JavaScript programmers pay a high price for their dynamic typing. Almost every JavaScript programmer is big into unit testing. That's their life safer. It goes without saying that unit testing is important in Java, too, but JavaScript programmers have to write many more tests because the compiler is much more lenient.
Thing is, the introduction of var doesn't make Java a dynamically-typed language. It's still statically typed. There are corner cases where var introduces errors because of its flexibility. As long as you keep this in mind, you should be safe.
Using an interface instead of the implementation
It's a common pattern in Java to declare the variable as a generic List. That's only an interface. It doesn't give any clue which implemention is used.
In theory, that's a big plus. However, in practice, I hardly ever saw errors introduced by using the actual implementation instead of sticking to the interface. Truth to tell, I did see a few such errors. But they are scarce, and most of the time, you can fix them in virtually no time. Once upon a time, I was convinced it's very important to always use the interface instead of the implementation. But over time, the topic has become less and less important to me.
Wrapping it up
I'm pretty much convinced that var is a major improvement to the Java language. It's up to you to make it a success. var is a sharp knife: you can use it to improve your life, and you can use it to make software maintenance a nightmare. I'm optimistic that following the Guidelines for using the var keywords in Java 10 by Stuart W. Marks is a good measure against nightmares.
But then, I didn't envision the way the stream API is currently used. Just think of the famous example:
var one = Arrays.asList(1, 2, 3).stream().findFirst().orElseGet(null);While I'd like to say this code is an exaggeration (it is!), I've seen similar code using streams just because they are fashionable a bit too often. Before adopting a new feature like var just because it's cool, ask yourself if it's still cool at three o'clock in the morning when an angry customer asks you to fix their bug right now! :)