Java 9 survey

What Java 9 features are developers yearning for most?

Alex Zhitnitsky
Debate illustration via Shutterstock

Alex Zhitnitsky takes a look at Takipi’s survey of the most requested Java 9 features in the community.

This post was originally published on the Takipi blog – Java and Scala exception analysis and performance monitoring.

When we asked the Java community to share their thoughts about Java 9, we could hardly imagine that the best comment we’ll receive won’t have anything to do with Java: “To make fun of Microsoft, they should skip Java 9 and go straight to Java 10”, wrote John Doe. So thank you anonymous commentator, wherever you are.

Over 350 Java developers participated in this project, which gives us a great overview of the features developers really want to see in the next version. We did see some of the usual suspects, but there were also some features we were surprised to see at the top of the list.

SEE ALSO: Oracle announces more new Java 9 features!

We then asked 3 JCP experts to share the features they’d like to see the most in the next releases, to get a better understanding about the way the actual release is heading down.


Percent of responses interested in each feature.

Almost 50% of developers mentioned Project Jigsaw as the most anticipated feature of Java 9
Postponed from Java 8 and heading towards Java 9, Jigsaw’s promise to break the JRE into interoperable components and introduce a new module system is getting everyone excited.

46% of developers want a standardized Java way to handle JSON
Surprisingly, a native Java way of handling JSON had the same interest as Jigsaw. But will it change the habits of relying on external libraries for this purpose? We’ll have to wait to the upcoming 2016 Java release to find out.

HTTP 2 is a must have in Java 9
Although the new standard hasn’t been finalized yet, it’s only a few months away and developers are expecting Java to provide full support. 103 out of 353 respondents agree.

Language changes and tools interest developers more than internal JVM changes
We see that changes that have less visible impact on the day to day of most developers generate less interest – Although they offer performance improvements.

java 9 future

Percent of responses interested in each of the changes

Looking beyond Java 9, we’ve compiled a short list of planned (and fictional) changes coming to your JDK to see how they pique your interest.

Project Valhalla is the Jigsaw of beyond Java 9, taking the top 3 spots
Generating the greatest interest is Project Valhalla, exploring advance Java VM and possible language features, led byBrian Goetz. Definitely epic.

Value Types are the most expected feature in Valhalla according to 48% of developers
Reified Generics and Generic Specialization are the runner ups, while Enhanced Volatiles is one of the least expected feature out of those we asked about.

Project Sumatra is Valhalla’s runner up – bringing Java to the GPU
Sumatra’s promise is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs).

Operator overloading had a 34% support and came in 5th
Our random imaginary features did less well but that’s why we also asked you about your thoughts.

So why don’t we just remove the semicolon if we’re already at it?

To see which other features you’ve set your eyes on for the future, we asked you to let go of any limitation and just say what you’d like to see coming to Java. 190 comments later from the survey itself and reddit, here are the top and most interesting features you suggested:

No more boilerplate code
A common complaint is that Java classes include large amounts of boilerplate code. Two projects aiming to solve this exact issue were suggested to address this: Project Lombok which was started by Reinier Zwitserloot and Roel Spliker, and Auto by Google with Gregory Kick and Christian Gruber. Scala’s Case Classes were also mentioned a couple of times.

Introduce Properties to Java
Saying goodbye to getters and setters.

Support for multiline strings
Check out Stephen Colebourne’s analysis on this right here.

Remove the semicolon
Honestly, this was just a suggestion to get the comments going but it was one of the popular choices after all! Removing null was also suggested a few times by the way (edit: this is probably why, thanks reddit)

Elvis operator ?
This little guy turned up a few times. A binary operator which results in the value of the left hand side if it is not null, otherwise, the right hand side is evaluated and returned. Stephen Colebourne was involved in promoting this one as well.

Enhanced Class Redefinition – JEP 159
This one is a super interesting Java Enhancement Proposal that we were directed to, imagine hot swapping classes while your application is still running without the need to restart it. Mind. Blown.

Additional suggestions were Named Parameters, Tail Call Optimization, Type Inference improvements, and adding Val, Var or even For Each statements.

What do the experts have to say about this?

To add more insight, we turned to Java Executive Committee members: Gil Tene and Werner Keil, together with Richard Warburton, a London Java Community member. Here’s what they had to say about their own expectations for Java’s future.

Which feature (or features) would you like to see most make their way to Java 9?

Warburton: “A lot of lambda related features were proposed for the streams API in Java 8 which didn’t make the cut in terms of time. Its already a good API, but I would like to see some time and investment put into giving it the polish that it deserves. For example:

Parallel Stream Control: At the moment control over the way that parallel streams use CPU resources is incredibly limited. Exposing the necessary hooks for this is a thorny problem but one which would provide significant benefits.

Missing Methods: There are many methods which would make sense in the context of a stream processing framework. For example takeWhile, dropUntil, zip and prefixSum are all things which would be of value to end users of the Stream API. These are things I’ve been asked about when talking about Java 8 in support of my book. It might also be time to re-evaluate the existing API in order to see if there is more scope to add method variants that take lambda expressions.

Performance Tuning: Whilst a significant amount of thought has been put into the overall architecture of the lambdas and streams framework it seems like there is still quite a lot of low hanging fruit in terms of performance tuning. Some stream API sources, such as BufferedReader.lines(), have implementations which don’t perform that well and have potential scope for improvement.”

Tene: “In Java SE 9, I’d very much like to see some community-led (as opposed to Oracle-led) features make it into the platform. Oracle has done (and continues to do) a great job developing and leading the platform, but for OpenJDK and the Java SE platform to show true community-driven behavior, we really need demonstrated community contribution that goes beyond comments and localized bug fixes. And I think that this is a matter of walking the walk.

When it comes to talking and walking, the main thing I’m working on with Java SE 9 in mind these days is the object layout related work currently captured in the org.ObjectLayout package (see With the new object relationships expressible through the various org.ObjectLayout classes, I believe that idiomatic Java data structures can finally match the access speeds of similar flat-data-layout data structures in C-style languages.”

Werner: “Modularity (codenamed Jigsaw) must finally be done right in Java 9. Some of the other features feel a bit redundant. If thanks to proper modularity you could install only the JSON, Rich UI (Swing vs. JavaFX) or Date/Time API you need for your application, that would of course be less of a burden. We heard, for Java SE 9 is unlikely to untangle the 3 Date/Time APIs that were thrown into 8 so far (java.util.Date, java.util.concurrent.TimeUnit vs. java.time.temporal.TemporalUnit) so on SE the Java community won’t get rid of this redundancy.

Also due to the fact that “legacy” code inside the JDK or Java EE (just take java.sql.Date etc.) is unlikely to ever leverage the “new” ones due to their monolithic closed and over-engineered design. JavaFX and its Date/Time subsystem can be fully avoided, and looking at Java ME, the existing java.util.Date is the only true platform neutral one that holds the “Write once Run Anywhere” promise of Java. All others are niche solutions.”

Is there any chance to see the Units of Measurement API in Java 9 (JSR 363)?

Werner: “There is currently no JEP and we prefer the JDK team at Oracle gets Jigsaw right now. In a more modular future of Java it will matter less if a JSR like Units of Measurement or Money, etc. are included. As “feature modules” one could add them to a custom profile. So depending on where Jigsaw could lead from there, we see a good chance of a “Sensor Web” or “IoT” profile where 363 should play its role.

A project of certain interest to JSR 363 is “Valhalla”, mainly its “Value Types” proposal. Languages like Scala offer this for a while now. Without going into detail, Java plans something similar, but it may not make it into Java 9. Based on JSR 363, Value Types for Units of Measurement could then either be a separate module or (probably not before Java 10) even one to choose during Java install.

Unlike other JSRs, the embedded nature makes JSR 363 very small and modular. Thus it targets Java ME at least as much as SE, which is why “JDK integration” is of lesser importance to it than working properly under ME 8 or 9, too.”

Java/Scala developer? Takipi detects all exceptions and errors in your code and tells you why they happen. Installs in just 1 minute: Try Takipi.

Alex Zhitnitsky
Alex works at OverOps – God mode in production code, helping Java and Scala developers solve bugs in production.

Inline Feedbacks
View all comments