Java 10 after 9 is fine; Java 10 after 8 (or earlier) be feared

“The community only wants a new version of Java every 3-4 years”

Java 10 was released a few weeks ago but we’re still dissecting its most important feature(s) (*cough*Local-Variable Type Inference*cough*), the features that didn’t make the cut and the migration process. While we’re at it, we need to talk about the new release cadence and the need for (or quite the opposite!) a legacy guide.

Does the new release cadence lead to release fatigue? Dr. Wayne Citrin weighs in on this inevitable problem in this article.

Look, I get it: It took three years after Java 8 for Java 9 to be released, people started getting frustrated, and Oracle got some probably-well-deserved heat. But I think that the pendulum has swung too far in the other direction. With a release every six months, we’ll get new releases loaded with minor new features that few are ready for, and that few care about. If the old two-year cycle is too slow, why not relieve release fatigue by splitting the difference and having a one-year cycle?

And now, the friendly reminder: Java SE 9 and 10 are short-term releases. Therefore, users are encouraged to transition to the next release when available. In short, this means that if you don’t give them a chance when they are out, you won’t have another shot at playing with them later on.

Source: Oracle Java SE Support Roadmap

Back to our interview series!

Donald Smith: While it is going to take time for the ecosystem to build up comfort with the new release cadence and what it means, we are confident that the new release cycle will ultimately make it easier for developers to transition from one version to the next.

Migrating from Java 9 to Java 10 will not be like migrating from 7 to 8. The amount of innovation delivered remains the same, but the pace at which it’s delivered increases, without disrupting the developer’s experience.

Modern application development expects simple open licensing, and a predictable time-based cadence and the new model delivers on both.

Migrating from Java 9 to Java 10 will not be like migrating from 7 to 8.

Greg Luck: Yes, it is too much. The community only wants a new version of Java every 3-4 years.

Oracle is speeding up Java releases combined with reducing the support period for these new releases unless you are a customer of theirs. Java 9 and Java 10 are only supported for 6 months! So, Java 9 is now unsupported as of March 2018!!

If you’re a customer, you can do better with a “Long Term Support” (LTS) release. The first one of those will be Java 11 due in September this year. Oracle have not yet announced for how long public updates will be available. But if you are a support customer, you can get Premier Support until 2013 and Extended Support until 2026.

Customers seeking longer support and maintenance periods for feature releases are encouraged to migrate to the Oracle Java SE product offerings (Oracle Java SE Advanced, Oracle Java SE Advanced Desktop and Oracle Java SE Suite). For releases after Java SE 8, Oracle Java SE product releases not designated as LTS releases will be maintained until the subsequent release. See Oracle Java SE Roadmap.

Why would you use a version of Java you cannot get new updates for? Java 9 and Java 10 should be considered beta versions from a production standpoint. And the jury is out on Java 11. If Oracle aggressively pursues monetization from Java, then Java 11 will have a short public (free) maintenance window, then it too will be considered non-production.

I think almost the entire Java user base is going to stay with Java 8 and await Oracle’s final position on all this after their monetization strategy plays out. We will likely be waiting a few years more on this.

In the meantime, what we already see happening is business booming for Azul Systems, who provide a Java support alternative to Oracle. We can expect the non-Oracle Java support business to grow with perhaps new entrants.

Also, I think these changes are in part driving the growth of other programming languages. At Hazelcast, we accommodate this with clients for C++, .NET, Scala, Node.js, Python and just released, Go.

Simon Ritter: I think we’ll have to wait and see!  The release cadence is fast, which is great because it enables developers to get their hands on new features more quickly; this is something many developers have been asking for.

However, for deployment and having access to bug fixes and security patches, this is going to be more of a challenge. We, at Azul, are trying hard to make this easier for people with our Zulu builds of OpenJDK.

Lukas Eder: No, I don’t see a problem with this. Sure, library vendors will have a bit of an extra effort, but then again, once Java 9 is de-supported (in March 2018!), no one cares about Java 9 anymore…

Trisha Gee: It definitely sounds very ambitious! However, these days many apps, tools and products do multiple releases a day, so two a year for Java is still “slow” compared to this. Of course, language updates are a little bit different to tiny changes to the way Facebook works, for example.

But being able to a) have regular, predictable updates to the language (instead of the, mmm, interesting wait for Java 9, for example) makes planning in organisations that use Java much easier, and b) as a developer I can now look forward to improvements (be they in performance, syntax, or whatever) in Java a couple of times a year, which is quite exciting.  It helps that these releases will be much smaller in the past, as well, because as a developer I only need to get to grips with a small set of changes instead of a massive release.

Markus Eisele: I am wearing two hats to answer this questions. First of all, I do believe that every Java developer is eagerly waiting for faster progress of the runtime. Having new features that reflect today’s requirements better is a must to stay productive and deliver value to customers.

On the other hand, it will be a big challenge for enterprises to adopt this fast-paced release cadence. The official support windows had to shrink, too. It will be interesting to hear more concrete customer stories about their process and experiences getting deeper into the new release cadence.

But even for enterprises, this might just be a new and accelerated process. The biggest challenge is buried for library developers and open source projects. The support range for Java versions requires them to keep various versions and support a reasonable subset of JDK versions that are used by their consumers. The keyword here is the Multi-Release JAR. If that will work out for everybody is another question that will be answered over time.

Marcus Biel: Well, as a true German I should probably say that everything is horrible now and that it was so much better in the past! Ok, more serious now: even though it is still unfamiliar to get yet another Java release so quickly, I really welcome the new, faster release cadence. It’s definitely a step in the right direction!

SEE ALSO: Java 10 is finally here! A closer look at the new features

Wayne Citrin: I’m on record as saying that it’s too soon for a new feature release and that the twice-a-year cadence is too much. There’s a real danger of “release fatigue,” as the Java community’s excitement over new releases is squandered.

David Heffelfinger: I think it may be too early to tell. We’ve gotten used to getting a new Java version every few years, the new release cadence will certainly require some adjusting. There are still some open questions about how the new release cadence will impact Java IDEs and training materials (books, etc), some fear that IDEs may not be able to keep up with the rate of change and that training materials may become obsolete too soon.

Nicolai Parlog: That’s a fair question. While I see the possibility of the release cadence splintering the ecosystem into a plethora of incompatible version ranges, I don’t think it’s the most likely outcome. I guess we have to wait and see.

Richard Gall:  It is just a different approach. Feature releases come no matter what. If there are even small new features: it is released. Major new features still may lag. The development has a pace, it is just how often you create a release from the current state of the development. It is business. Creating release has costs. On the other hand, the sooner a feature is released the sooner it is used in production to create value.

Should legacy developers worry about how they can take advantage of Java 10? Do we need something like a legacy guide to Java 10 or is this release too small/unimportant for something like that?

Donald Smith: The new cadence is meant to accelerate the pace of innovation while minimizing the disruption of developers’ experiences. We believe the new features introduced in Java 10 will contribute to maximizing efficiencies rather than make it more difficult for legacy developers to leverage Java.

Greg Luck: When almost no one is going to use Java 10, I don’t think we should refer to the Java 10 people as legacy. Instead, I think we can refer to the Java 10 sideshow.

The changes are minor enough to be gradually integrated into the existing codebase. It’s not as disruptive as Java 9 and the module system. If your application works on Java 9, it’ll most probably work on Java 10 too.

Simon Ritter: I don’t think there is enough in JDK 10 to require a legacy guide.  However, if developers are considering moving from JDK 8 (or earlier) to JDK 10, then they will need to take into consideration how to migrate to the Java Platform Module System (JPMS) that was introduced in JDK 9.  That’s still there so developing for JDK 10 will still require developers to address JPMS issues.

With the faster release cadence, what makes more sense is less of a “Guide to Java 10/11/12” every six months and more of a living “How to use modern Java” type guide.

Lukas Eder: It’s rather unimportant from what I can tell. Even JEP 286 seems like a very minor change compared to e.g. lambdas, method references, interface methods, etc.

Trisha Gee: This is a good question. I think with the faster release cadence, what makes more sense is less of a “Guide to Java 10/11/12” every six months and more of a living “How to use modern Java” type guide which is updated with relevant features (and annotated with their release version) as they become available.

Markus Eisele: I would advise to not overestimate this particular release. The only new feature for developers is Local-variable type inference (JEP 286). The one thing the ecosystem can start to learn is to handle the co-existence of various JDK versions in the development lifecycle. Our industry expects us to stay up to date with new releases in various ways and staying on top of them is the most important requirement to me personally.

Marcus Biel: With the release being rather small, I wouldn’t expect any big issues.

Wayne Citrin: Unless you’re a developer with very specialized needs directly addressed by some of the new features in Java 10, this release is really too small and unimportant for legacy developers to worry about. I tried to put together a legacy developer’s guide to Java 10 since my legacy developer’s guide to Java 9 was popular, but I really couldn’t find anything to say.

David Heffelfinger: Most of Java 10 changes are “under the hood” (improved garbage collection, etc), the only user-facing feature is local variable type inference, which is a relatively minor feature. A legacy guide to Java 10 sounds like overkill, perhaps a blog post or an online article will suffice for competent Java developers to get up to speed with new Java 10 features.

Nicolai Parlog: If they managed to get everything working on Java 9, updating to Java 10 will be a breeze, so there’s no use for a migration or legacy guide.

But that doesn’t mean that the release is unimportant. Every new version is a step on a long path. Some steps are larger, the aforementioned value types for example, but all o them are important.

Richard Gall: Definitely a small release. You can create a legacy guide. Here it is: “Hey guys! You can use ‘var’ when you do not want to explicitly define the type of a local variable.” And that is it.

In the last part of our interview series, our interviewees weigh in on the modular ecosystem and present their Java 11 wish list. 

12 JEPS for Java 10

Just to freshen up your memory, Java 10 includes 12 new enhancements defined through the JDK Enhancement Proposals (JEPS):

1. (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.
2. (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.
3. (JEP 204) Garage Collector Interface: Improves the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface.
4. (JEP 307) Parallel Full GC for G1: Improves G1 worst-case latencies by making the full GC parallel.
5. (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.
6. (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.
7. (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.
8. (JEP 314) Additional Unicode Language-Tag Extensions: Enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags.
9. (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.
10. (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.
11. (JEP 319) Root Certificates: Provides a default set of root Certification Authority (CA) certificates in the JDK.
12. (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.

Source:-jaxenter