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<String> list = new ArrayList<String>();
Stream<String> stream = getStream();
Will be replaced with this new, simplified syntax:
var list = new ArrayList<String>();
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<String> list = new LinkedList<String>();
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:
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:
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:
- Local variables with initializers
- Indexes in the enhanced for-loop
- Locals declared in a traditional for-loop
The Java team at Oracle states that it will not be available for:
- Method parameters
- Constructor parameters
- Method return types
- Fields
- Catch formals (or any other kind of variable declaration)
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:
- Thread-Local Handshakes (JEP 312) – This will introduce a new way to execute a callback on threads, so it will be both possible and cheap to stop individual threads and not just all threads or none
- Heap Allocation on Alternative Memory Devices (JEP 316) – Allowing the HotSpot VM to allocate the Java object heap on an alternative memory device, which will be specified by the user
- Additional Unicode Language-Tag Extensions (JEP 314) – The goal is to enhance java.util.Locale and its related APIs, to make it possible to implement additional unicode extensions of language tag syntax (BCP 47)
- Experimental Java-Based JIT Compiler (JEP 317) – Oracle wants to enable its Java JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform
- Root Certificates (JEP 319) – The goal here is to open source the root certificates in Oracle’s Java SE
- Root Certification Authority (CA) program, making OpenJDK builds more appealing to developers. It also aims to reduce the difference between the OpenJDK and Oracle JDK builds
- Consolidate the JDK Forest into a Single Repository (JEP 296) – The main goal of this JEP is to do some housekeeping, and combine the numerous repositories of the JDK forest into a single repository
- Remove the Native-Header Generation Tool (javah) (JEP 313) – This one is plain and to the point – remove the javah tool from the JDK
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.
| Published on Java Code Geeks with permission by Iris Shoor, partner at our JCG program. See the original article here: How Java 10 will CHANGE the Way You Code Opinions expressed by Java Code Geeks contributors are their own. |
I feel a bit uneasy about the introduction of this “var” keyword. The fact that it’s limited to essentially local variables does, however, satisfy my concerns.
Local type inference certainly has a lot to recommend it. However, if you want the variable to be typed by the interface – List – rather than the class – LinkedList – I suspect type inference is not for you. There is definitely something faulty in the syntax and idiom of Java. Whenever I think of coding something, I think immediately in terms of interfaces and classes and the underlying structure. Then when I get in front of my IDE—whichever Java IDE I happen to hate the least at that time—I feel like I’m fighting the syntax nonstop. And what’s… Read more »
I don’t like this “var” keyword. I know it from programming C#. It is not nice for maintaining software that you didn’t make. You can’t read the type of the var with your eyes.