7 Experts – 7 Opinions: What do you think about the new Java release cycle?
Java 13 is here! In the second part of our interview series, we talk to some of the experts about all the pros and cons of Java. Michael Simons, Tim Riemer, Michael Vitz, Sandra Parsick, Christian Schneider, Tim Zöller, and Hendrik Ebbers discuss how they feel about the new six-month Java release cycle? Is it too frequent or is it just right?
Although Java 13 is not a huge release in terms of new features, it comes with some upgrades and feature previews that are impressive.
Java 13 proves that 13 isn’t an unlucky number. Just like Java 12, it arrived right on time, adhering to the new release schedule.
Due to the faster release cadence, (every six months) this means that developers can postpone upgrading to the newest release until the next Long-Term Support (LTS) version.
Our Java experts
With several projects underway such as Valhalla, Amber, and Skara, Java 13 introduces five Java Ehnamcenet Proposals: JEP 350 (Dynamic CDS Archives), JEP 351 (ZGC: Uncommit Unused Memory), JEP 353 (Reimplement the Legacy Socket API), JEP 354 (Switch Expressions – Preview), and JEP 355 (Text Blocks – Preview).
Take a deep dive into all of the new features in this article by Falk Sippach. Sippach writes:
The goal is to finalize the preview features by the next LTS version so that they are stable enough and will look good for the next three years. In September 2021, Java 17 will take over the legacy of Java 8 and 11.
We spoke to some of the Java experts about the new features, their hopes for the next version, and how they feel about the new release cycle.
They discussed some of the pros and cons regarding the Java platform and the state of the JDK.
Let’s see what Michael Simons, Tim Riemer, Michael Vitz, Sandra Parsick, Christian Schneider, Tim Zoller, and Hendrik Ebbers have to say about the newly implemented six-month Java release cycle.
7 experts speak: What do you think about the six-month Java release cycle?
Michael Simons: As a Library Developer, I would like to use many of the new features, but I am more or less forced to use the JDK 8 compatibility. Enterprise is another world. Otherwise, we build and test against the current JDK releases.
Tim Riemer: Due to the shortened release cycle, you cannot expect “real revolutions” — like it was the case, for example, with Lambdas in Java 8 — with every new release. Instead, it has the advantage that is more similar to the evolution of the language, and that a versioning change is much less painful to achieve. Furthermore, the preview features are now offering the advantage to collect broader feedback, and maybe even let it be integrated in the next release. Personally, I am relaxed when it comes to the release frequency. Currently, our Java-based services in production are running on OpenJDK 11 and 12.
Michael Vitz: In principal, I think it’s good that there are more frequent JDK releases. Instead of waiting several years to receive a myriad of features, I now have the ability to regularly test the new features. This is also what makes the concept of preview features, features that are deliberately not perfectly balanced, possible. Yet this also led to a larger fragmentation of the versioning. A lot of my customers still remain on JDK 8, primarily to the in JDK 9 introduced modul system. Slowly, some of them are brave enough to switch to JDK 11 in order to use a release with a Long Term Support. I am curious to see, if this will further change in the future, and if I will also see releases between two LTS versions in the day-to-day project work.
Sandra Parsick: The new release policy has no impact in my daily work. Most of my customers still use Java 8 and fight with the update to Java 11. New projects start with Java 11 because it’s the current LTS version. I use the newest Java version only in my pet projects.
Christian Schneider: I keep an eye on the new releases and occasionally experiment with the new features. For actual development, we compile and test with the new Java versions but limit ourselves to the feature set of Java 8. I also currently see no real need for the newer features. Some are nice but they do not warrant to migrate to a newer Java version.
Tim Zöller: We always try to set our own, internal development to the respective, current version – it is less effort to do so with the younger versions of course. In customer projects, we still mostly have to deal with Java 8, because in my experience the joy of migration is limited. We are often still at the company-wide standard Java version, which must be used.
Hendrik Ebbers: I really like the new release train of Java and I’m 100% sure that this is the right way to go. How I handle the releases depends on the project. For small projects, it makes sense to just update the version every 6 months. Once tools like Maven and IntelliJ are ready for the next version such projects can easily migrate. Next to this, I have several customers with large applications that are already developed or maintained for several years. For such projects, an update to the next LTS version often makes more sense.
These projects are currently on Java 11 or in the middle of the migration to 11 and will stay on this version until the next LTS release. Some of those customers have commercial support for Java at a vendor like Oracle or Bellsoft to receive production ready LTS update. Next to this several companies switched to AdoptOpenJDK that provides free and ready to use LTS releases for Java 8 and 11.
Stay tuned for the next part in the series where the experts discuss what they hope to see in Java 14. And make sure not to miss the first part of the series: