The future of Java promises a cleaner, more readable syntax
Java has always been derided as being too verbose, especially when compared with languages like Groovy or Scala. But, according to Brian Goetz, that's all about to change after Java 9.
Java is too verbose. Even the biggest advocates of the Java language are willing to acquiesce to that point. And any enterprise software developer who has dabbled in any peripheral languages, such as Groovy, Scala or Ruby, knows the added verbosity does very little in terms of helping developers write high-quality, bug-free code. If anything, it hinders that process by creating far too many tripwires that will trigger a compiler error if a property is changed, or if a new instance variable is added to a class.
At JavaOne 2016, Brian Goetz, Java language architect at Oracle, joined Mark Reinhold during the opening keynote to talk about the various changes being contemplated for the Java language after the Java 9 release is out of the way, that will hopefully cut down on language's verbosity and allow developers to focus on what they want to focus on, which is writing code.
The new focus is certainly welcome. Unfortunately, these small, incremental changes to the language aren't as flashy as the big language changes that have happened in the past. By no means are these small alterations going to change how applications are developed, as did the addition of generics to Java 5, or the incorporation of Project Lambda in Java 8. "For the last couple of versions, we've been focusing mostly on big stuff, like Lambdas and Jigsaw," Goetz said. "That's important as far as building the foundation for the future. But we also care about everyday developer productivity. We're looking at features for the short term to make things easier."
Doing away with the boilerplates
The required verbosity in the Java language is often referred to as boilerplate code, as the code itself follows a very repeatable and boring form. Goetz's team has taken a targeted look at the biggest sources of boilerplates in Java. The constructor, equals methods, hashcode implementations and the ubiquitous toString method are prime culprits. "Maybe the IDE will generate it, but you still have to read it. The IDE can't do that for you," Goetz said.
Goetz pointed out this low-value code is a labor to write and tedious to read. So, what's the goal? In post Java 9 releases, developers will be able to create simple data holder classes, define the principle fields and then rely on the compiler to create a sensible implementation for these artifacts. From a readability standpoint, other coders on the team can then look at the code and easily see exactly what's going on.
Type inference is coming to Java -- again
The second way to reduce low-value work and boost productivity is by expanding the scope of type inference. It's not a concept that is completely new to Java, as type inferences have been around since Java 5. Calming fears that type inferences might be problematic, Goetz reminded JavaOne attendees that Java 5 had the generic method invocation, which did type inference; Java 7 had the generic constructor invocation, or Diamond Syntax; and Java 8 inferred types of Lambda formals. The next logical progression is adding type inferences for local variables. It's a natural evolution of the language, and not anything drastic or dramatic.
Calming the fears of developers who might suspect this sounds too much like dynamic typing, Goetz insisted the move is not about turning Java into JavaScript, but instead, it's simply about removing redundancy from the code, while retaining the benefit of strong static typing. Developers can let the compiler figure things out. If they do want a particular method spelled out in plain text, they can declare it. It's the best of both worlds.
"A lot of people freak out when they see this and think the code is going to be unreadable. It's certainly possible to write unreadable code," Goetz said. "But if you have sensible variable names, when you take the static types away from these locals, the code actually remains pretty readable. Perhaps more readable because what it is describing is what it does in the program."
