Java 10: What do Java developers want? Projects Amber and Valhalla! When do they want them? When they’re ready!
© Shutterstock /Leremy
Java 10 is here. In the first part of this interview series dedicated to the newest Java release, we talked with 11 Java experts about their favorite feature(s). Now it’s time to dig deeper and talk about the features they wanted to see in Java 10 but were not included.
“Java 10 is a fairly minor update to Java 9“
Java 10 was released last week but we’re still dissecting its most important feature(s) (*cough*Local-Variable Type Inference*cough*).
We talked with 11 Java experts about their favorite features and Java 10’s “unique selling proposition” and we learned that even though Java 10 is not that special, people are really excited about Local-variable type inference (JEP 286), which enhances the Java language to extend type inference to declarations of local variables with initializers.
One thing we haven’t covered yet is the elephant in the room, namely the Java SE support roadmap.
As you can see from this table, both Java SE 9 and 10 are short-term releases. Therefore, users are encouraged to transition to the next release when available.
Back to our interview series!
11 answers: What is the most important misconception about Java 10?
Meet our Java experts
Donald Smith: After almost 20 years and 9 major releases, the Java ecosystem is used to “major” releases being difficult and challenging to get used to, mostly due to the massive amount of features introduced all at once. Java 10 marks the beginning of a new era, where going from Java 9 to Java 10 should be almost as easy as going from 8u20 to 8u40.
The new release cycle allows us to introduce new features at a more reasonable pace and focus on what the community really wants.
With Java 9 (and consequently Java 10), Oracle’s support roadmap for versions of Java has changed.
Greg Luck: That it is a production Java release.
Simon Ritter: I think people will look at JDK 10 as something of a point release rather than a full release. This is incorrect because JDK 10 has gone through the complete Java Specification Request (JSR) process.
I recently wrote a blog that highlights there are 109 new features in JDK 10 so it’s not that light.
Lukas Eder: I can’t think of any.
Trisha Gee: I’m not sure it’s a misconception so much as a lack of awareness, but it’s possible that many people don’t realize that with Java 9 (and consequently Java 10) Oracle’s support roadmap for versions of Java has changed. Only certain versions will have long-term support (e.g. Java 8, Java 11), the ones in between will not have ongoing support from Oracle. Instead, we’re encouraged to move to the next version.
Markus Eisele: I believe that many developers are still waiting for Projects Amber and Valhalla. The major version bump might still imply to some that some more big ticket changes are contained. Which is not the case, obviously.
Wayne Citrin: That it’s a major release. In just about any other software product, an upgrade like this would be a minor or point release. Why couldn’t we have called it Java 9.1?
David Heffelfinger: Since the beginning, a new Java version has always been a major event, with tons of new features, this time around, since Java just changed to a 6-month release cadence, this new Java version only has a few new features.
Some may expect lots of new functionality, based on the buzz that previous Java versions have always generated, where in reality Java 10 is a fairly minor update to Java 9.
Nicolai Parlog: That the step from Java 9 to Java 10 is at all comparable to the one from 8 to 9. It’s not — not even close. Java 9 changed a ton of things, particularly under the hood, and was the most challenging release to in a long time, maybe ever. Compared to that, updating to Java 10 is like going from 9.0.1 to 9.0.4.
The only hurdle is that the bytecode level was increased (that will happen with every new release), which can be a problem for some bytecode analysis tools, like ASM, and the projects depending on them.
Richard Gall: I don’t know. After Java 9, there is not a lot of hype about Java 10 now.
If you could replace any feature in this release with a different one, what would that be?
Donald Smith: Again, I’ll channel my inner Dr. Deprecator and say I wish we could have reduced the footprint of the JDK by separating the Java EE and CORBA modules from Java 10, but alas it is targeted to Java 11 instead.
Greg Luck: I would have added:
- Value types (project Valhalla) and immutable arrays
- Variety of
defaultmethods in the collection API
Simon Ritter: I don’t think there’s anything I would like to change. My personal feeling is that Java is a great platform. I like the way people like Brian Goetz and Mark Reinhold carefully add new features without making massive changes that would stop Java feeling like Java.
I wish we could have reduced the footprint of the JDK by separating the Java EE and CORBA modules from Java 10.
Lukas Eder: Well, I’d love to have all the exciting features from projects Amber and Valhalla already, but they will take a bit more time to get right.
Trisha Gee: I’m not sure I’d replace anything in there.
There are features that don’t directly impact the way I write code (for example Consolidate the JDK Forest into a Single Repository), but I’m assuming housekeeping activities like this one help the team develop the language faster or easier (or both!), which will ultimately benefit me as a Java developer.
Markus Eisele: I can’t think of one.
Marcus Biel: Well, I personally feel that it would be much more important to remove some features and to revise wrong decisions of the past than to add new features. If it is to be a new feature, though, I would like to have pattern matching.
Wayne Citrin: I don’t find any of the new features bad, or misguided, so there are no features that I particularly dislike or would like to replace.
David Heffelfinger: Most of the new Java 10 features are internal as to how the JDK works. Perhaps one of these “behind the scenes” features could have been replaced with a user-facing feature, although I don’t have any specific suggestions or examples.
Nicolai Parlog: I’m really looking forward to primitive specialization (i.e.
List<int>) and value types, but they are still in the works. In the meantime, Project Amber will keep us on our toes. They will come out when they’re done, though, and I wouldn’t want to have them any sooner, so I’m not in the wishful thinking camp.
Richard Gall: Nothing. There are important features in development, like fibers, value types and some other. Having
var and removing some old deprecated classes is a minor thing on the big Java road.
In the third part of our interview series (three more to come), we asked our interviewees if they have already migrated to Java 9 and if they plan to migrate to Java 10.
12 JEPS for Java 10
- (JEP 286) Local-Variable Type Inference: Enhances the Java Language to extend type inference to declarations of local variables with initializers. It introduces var to Java, something that is common in other languages.
- (JEP 296) Consolidate the JDK Forest into a Single Repository: Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.
- (JEP 204) Garage Collector Interface: Improves the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface.
- (JEP 307) Parallel Full GC for G1: Improves G1 worst-case latencies by making the full GC parallel.
- (JEP 301) Application Data-Class Sharing: To improve startup and footprint, this JEP extends the existing Class-Data Sharing (“CDS”) feature to allow application classes to be placed in the shared archive.
- (JEP 312) Thread-Local Handshakes: Introduce a way to execute a callback on threads without performing a global VM safepoint. Makes it both possible and cheap to stop individual threads and not just all threads or none.
- (JEP 313) Remove the Native-Header Generator Tool: Remove the javah tool from the JDK since it has been superseded by superior functionality in javac.
- (JEP 314) Additional Unicode Language-Tag Extensions: Enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags.
- (JEP 316) Heap Allocation on Alternative Memory Devices: Enables the HotSpot VM to allocate the Java object heap on an alternative memory device, such as an NV-DIMM, specified by the user.
- (JEP 317) Experimental Java-Based JIT Compiler: Enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform.
- (JEP 319) Root Certificates: Provides a default set of root Certification Authority (CA) certificates in the JDK.
- (JEP 322) Time-Based Release Versioning: Revises the version-string scheme of the Java SE Platform and the JDK, and related versioning information, for present and future time-based release models.