Java: More Typing With Less Typing

I often hear criticism of Java because it is too verbose: “You need too much boiler-plate code, even for simple things,” “Why do I need to end every statement with a semi-colon? Other languages don’t require this” and so on. It is true Java does require more characters to be typed than some other languages.

Verbose v. Concise

However, it is a difficult balancing act for any language in terms of readability versus ease-of-development. Languages can be made very succinct and achieve a lot in only a few characters (think Perl). The downside of this rapid application development (always assuming you are sufficiently skilled to convert your requirements into the minimal syntax) is a loss of readability. I was once given a ten-page Perl script and asked to convert it to Java. I rapidly decided that Perl was a write-only language. Even the original developer struggled at times to understand what he had written less than a year after the code was written. I’m not criticizing Perl, which is a very powerful scripting tool, but using it as an example of readability.

Continuously Improved Developer Productivity

Over the last twenty years, Java has been improved in numerous ways to help reduce the burden of typing on the developer. Combining this with the massive advances in sophistication of IDEs and related tools has made Java developers at least an order of magnitude more productive than when Java was launched. Lambda expressions instead of anonymous inner classes, method references, try-with-resources, multi-exception catch blocks are all good examples of these improvements.

Which brings me to the real subject of this blog post, the recent JDK enhancement proposal (JEP 286), “Local-Variable Type Inference”. This would continue some of the work that has already been done in earlier versions of Java to reduce the amount of explicit type information that a developer needs to provide:

• In JDK 7 the so-called diamond operator was introduced. This eliminated the need to specify the type parameter of a generic type twice when instantiating it if the type was the same. When generics were first introduced I thought it rather odd that I needed to write List<String> l = new ArrayList<String>();. Thankfully we can now just write List<String> l = new ArrayList<>(); without losing any of the readability we had before.
• In JDK 8 a large part of the compiler was rewritten to improve its ability to infer types. This was in large part to support lambda expressions so that we can simply write (a, b) -> a.length() – b.length() rather than (String a, String b) -> a.length() – b.length().

JEP 286 proposes that in three situations the developer will no longer need to explicitly state the type:

1. Local variables with initializers (e.g. var l = new ArrayList<String>();)
2. Indexes in the enhanced for-loop (e.g. for (l : list))
3. Indexes in the traditional for-loop (e.g. for (i = 0; i < 4; i++))

Given that nearly all the other comparable languages to Java (the so-called ‘curly-brace’ languages like C, C++, C# and Go) have some form of local-variable type inference, the authors of the JEP posit that the idea of adding them to Java should not be controversial. I think this is fair, as the change would not radically alter the language or make it harder to learn or understand (quite the reverse, in fact).

What will prove to be controversial is the syntax that will be used, which is where my comment at the start of the blog becomes significant. Since there is no clear consensus from other languages the proposal lists no less than nine possibilities. The use of var seems to be something of a front-runner at the moment and it’s worth making it clear that this will not introduce a new reserved word to Java (breathe a sigh of relief anyone who’s used var as a variable name). However, does that get used in conjunction with val, let, or neither?

JEP 286 does not list a targeted release yet, but it would be great if it could be included in JDK 9. According to the published schedule, JDK 9 will be feature complete on 26^th May, so there are only about six weeks to finalize the details, which does seem rather ambitious.

Join the Discussion on the Zulu Forum

I’ve started a thread about this on the Zulu forum.

Why not add your thoughts to the discussion?