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.
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
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.
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
var doesn’t make Java a dynamic language
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! 🙂