A new JDK Enhancement Proposal (JEP) is making waves in the Java community: JEP 286. The proposal suggests to introduce Local Variable Type Inference in future versions of Java, in order to simplify the writing of Java applications.
In the following post we will explain what it means and how it will affect your code.
New Post: Java Community Survey Results: 74% of Developers Want Less Verbosity https://t.co/TtxVBiqFAj pic.twitter.com/TEs0VtFnpD
— OverOps (@overopshq) April 13, 2016
The var Proposal
The new language feature suggests adding some syntactic sugar to Java – simplifying it and improving developer experience. The new syntax will reduce the ceremony 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. Oracle stated that this new feature will allow, for example, declarations such as:
var list = new ArrayList<String>(); val stream = getStream();
That will replace the current syntax:
List<String> list = new ArrayList<String>(); final Stream<String> stream = getStream();
As you can see, the Local Variable Type Inference will allow using the var keyword instead of specifying the type of the variable.
Java is known to be a bit verbose, which is good when it comes to reading and understanding what you or another developer had in mind when a function was written. For those of you who always thought it was a bit tedious, the proposal marks a significant change.
This proposal is not relevant for Java 9, which is already in the making and will also change the way you code.
To JEP or Not to JEP?
A few weeks ago Brian Goetz, Java Language Architect at Oracle, published the survey results for this new proposal. The main question was: “What do you think of the proposed Local Variable Type Inference feature overall?”. 2,453 developers replied, and the result we’re mostly positive:
The second part of the survey focused on the future syntax, suggesting 5 options to choose from based on similar use in other languages, such as C#, Scala, Swift, C++ or use let. Most users chose the var/val option:
Even though most users approve of this new option, reading through the comments section shows developers who approve of this change, asking Oracle to “get with the times”, pointing out this change should apply only to val and even asking for more changes, such as multi-line strings.
My birthday is only in a few weeks, but this is one of the best gifts ever! https://t.co/QVtXwUPwEG
Soundtrack: https://t.co/dIpLKLFFEE— Erik Meijer (@headinthebox) March 10, 2016
The developers who are against this proposal 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 that “the diamond operator was a good move”, unlike the current proposal.
Don't blame language features for making developers write shitty code. Blame shitty developers! JEP286 is a *great* thing for java #var #val
— Simon Maple (@sjmaple) March 13, 2016
Where is This Change Coming From?
One of the most common complaints about Java is the amount of boilerplate coding required to write it. A few lines of Java code can be written with a single line in other languages, such as C++, C#, Scala and Go.
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 allowed writing the following code:
List<String> list = new LinkedList<String>();
And of course, on the JEP 286 summary page you’ll be able to find the following justification from Oracle 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?
Oracle knows that the community might take time to adapt and accept this new proposal. While it’s still not clear if and when JEP 286 will become a reality in future versions of Java, it’s enough to make a few developers in the community speak out.
If you’re one of those developers, you’d be happy to learn that this treatment is restricted to:
- Local variables with initializers
- Indexes in the enhanced for-loop
- Locals declared in a traditional for-loop
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.
Do Try This at Home
We at Takipi always love to try new things before they hit the market, and JEP 286 is exactly that. If you didn’t form an opinion about JEP 286, you can check it out for yourself right now.
As part of the Adopt OpenJDK program, Richard Warburton and Raoul-Gabriel Urma has publicly posted unofficial builds of the Open JDK with JEP 286 support. That way, you’ll be able to experiment with the new features, get to know what JEP 286 is all about and get a taste of it in action.
Want to experiment with type inference for #Java ?@raoulUK and I have put up binaries for JEP 286 so you can try ithttps://t.co/0YqnoguqTe
— Richard Warburton ☕ (@RichardWarburto) March 13, 2016
Final Thoughts
This new proposal is stirring things up in the Java community, getting a lot of attention. The fact that you can test drive the new feature right now will help developers realize what the future of Java might have in hold.
It is important to remember that this is an early proposal and it’s still not clear whether Oracle will implement it. That’s why we encourage you to participate in future surveys and be an active part of this JEP, and other future Java related features.
| Reference: | Java Community Survey Results: 74% of Developers Want Less Verbosity from our JCG partner Iris Shoor at the Takipi blog. |
