How Java 10 will CHANGE the Way You Code (original) (raw)

Highlighting the New Java Local Variable Type Inference Feature Coming in Java 10

Back in 2016, a new JDK Enhancement Proposal (JEP) was making waves in the Java community: JEP 286. Now, 2 years later, Local Variable Type Inference is arguably the most noteworthy feature coming in Java 10. This is one more step that the Java Language developers are taking in order to simplify the writing of Java applications.

In the following post we will explain what all of this means and how it will affect your code.

Breaking Down Local Variable Type Inference

This new feature will add some syntactic sugar to Java – simplifying it and improving developer experience. The new syntax will reduce the verbosity associated with writing Java, while maintaining the commitment to static type safety.

In other words, you’ll be able to declare variables without having to specify the associated type. A declaration such as:

List list = new ArrayList();
Stream stream = getStream();

Will be replaced with this new, simplified syntax:

var list = new ArrayList();
var stream = getStream();

As you can see, the Local Variable Type Inference will introduce the use of the ‘_var_’ keyword rather than requiring the explicit specification of the type of the variable.

Java is known to be a bit verbose, which can be good when it comes to understanding what you or another developer had in mind when a function was written. But, for those of you who think developing software in Java is too tedious, this feature marks a significant change.

While Type Inference is not a new concept in Java, it is a new concept for local variables.

It was partly introduced in Java 7 (as part of Project Coin) with the diamond operator (<>), which allows initializing lists without a type bound ArrayList<>, and in Java 8 with Lambda Formals. For example, using the diamond operator allows writing the following code:

List list = new LinkedList();

Now, the Oracle Team is taking it one step further.

Community Response

Back before JEP 286 was, in fact, a JEP… A survey was conducted by Oracle to get a better understanding of how the Java community felt about the proposal. For the most part, the survey focused on the overall feelings toward the proposal, and how the community thought it should be implemented. Of the 2,453 developers that replied, the results were mostly positive:

Survey question: What do you think of the proposed Local Variable Type Inference feature overall?

The second part of the survey focused on the potential syntactic choices, suggesting 5 options to choose from based on similar use in other languages such as C#, Scala, Swift, C++ or to use _‘let_’.

Most users voted for the var/val option:

Possible syntax options

In the end, the team decided to go with the 2nd most popular choice, var only.

Most members of the Java community seem to approve of this new option, with many of them asking Oracle to “get with the times”. The few developers who are against the feature claim that it might be difficult for those who are taking their first steps in Java, or point out that the existing syntax is the “right mix of verbosity and legibility”.

And of course, on the JEP 286 summary page you’ll be able to find the following justification for adding the new feature:

“Java is nearly the only popular statically typed language that has not embraced local-variable type inference; at this point, this should no longer be a controversial feature”

How Will This Affect Your Code?

Once we get all of the excitement over a new feature out of our systems, the first question we usually want to ask ourselves is: How will this affect my code? In the feature summary, “the degree of boilerplate coding required in Java” is addressed as a main motivation, so we can look forward to omitting manifest type declarations in the future.

More specifically, the treatment will be restricted to:

The Java team at Oracle states that it will not be available for:

Due to Java’s commitment to support previous versions of Java, we can assume it won’t break backwards compatibility.

Plus: GC Improvements and Other Housekeeping

There are 2 JEPs in JDK 10 that focus on improving the current Garbage Collection (GC) elements. The first one, Garbage-Collector Interface (JEP 304) will introduce a clean garbage collector interface to help improve the source code isolation of different garbage collectors.

In current Java versions there are bits and pieces of GC source files scattered all over the HotSpot sources. This becomes an issue when implementing a new garbage collector, since developers have to know where to look for those source files. One of the main goals of this JEP is to introduce better modularity for HotSpot internal GC code, have a cleaner GC interface and make it easier to implement new collectors.

The second JEP that is scheduled for Java 10 is Parallel Full GC for G1 (JEP 307), which puts its focus on improving G1 worst-case latencies, by making the full GC parallel. G1 was made the default GC in Java 9, and the goal of this JEP is to make G1 parallel as well.

Among the other features that are scheduled for Java 10, we can expect:

Please Try This at Home

Just like with every other JDK release, Oracle has already created an Early Access Release that Java users can download to test out the new features. Actually, this JEP has been available for test driving since early 2016, so what are you waiting for?

Even if you haven’t started thinking about moving to JDK 9 yet, getting a feel for the new features and having the opportunity to give feedback to the platform designers is a great way to learn about the new version and to have an impact on the community.

Final Thoughts

We’ve been keeping an especially close eye on the development of the Java Platform lately. It feels like ever since the release of Java 9 last September, the whole Platform has done a complete 180. They introduced us to modular Java, plus Mark Reinhold announced that JDK 10 would be released in March 2018 and that Java would be switching to a 6-month release cycle.

No more waiting years and years for a new Java version that’s being held up by some monstrous feature project like Project Jigsaw. Now, we’ll be getting new versions every 6 months, with long-term support versions coming every 3 years starting with JDK 11 in September 2018.

Basically, don’t get too comfortable. Oracle has big plans for the Java Platform in the next few years. For now, though, get caught up on the best of Java 9 with our VP Engineering, Niv Steingarten, right here.

Photo of Tali Soroker

Tali studied theoretical mathematics at Northeastern University and loves to explore the intersection of numbers and the human condition. In her free time, she enjoys drawing and spending time with animals.