DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • DevOps: CI/CD Tools to Watch Out for in 2022
  • Look, Ma! No Pods!
  • How to Publish Artifacts to Maven Central
  • 6 of the Best API Testing Tools in the Market

Trending

  • Unlocking the Benefits of a Private API in AWS API Gateway
  • Introduction to Retrieval Augmented Generation (RAG)
  • Non-Project Backlog Management for Software Engineering Teams
  • Role of Cloud Architecture in Conversational AI
  1. DZone
  2. Coding
  3. Java
  4. Beyond Java 8

Beyond Java 8

A majority of developers are still using Java 8.

By 
Trisha Gee user avatar
Trisha Gee
·
May. 03, 19 · Analysis
Likes (14)
Comment
Save
Tweet
Share
29.9K Views

Join the DZone community and get the full member experience.

Join For Free

This article is featured in the new DZone Guide to Java: New Developments & Features. Get your free copy for insightful articles, industry stats, and more!

If recent surveys are to be believed (including DZone readers, see page 3), most developers are still using Java 8 for the majority of their application. Before Java 8, uptake of a new version of Java was quite slow, particularly in enterprises where it can be difficult to get a new version of Java accepted for production. Java 8, with the introduction of lambda expressions and streams, was an appealing choice for many developers. The adoption of microservices, continuous delivery practices, and better-automated testing also makes it easier to use a new version of a language with far less risk than in the past.

So, given this, why is it that developers are "stuck" on Java 8, despite the fact that since Java 9, we now have two releases of Java a year? Java 12 is now the most recent version, and yet few people have made the leap to 9, 10, 11, or 12.

As you might expect, the answer is "it's complicated". There have been a number of different changes since Java 8 was released that may make organizations wary of upgrading.

Six Monthly Release Cadence

Since Java 9 (released September 2017), Oracle has been releasing a new JDK every six months, in March and September every year. In a continuous delivery world, it makes sense for our language to evolve much faster than every three years.

The new release cadence means that instead of getting huge,feature-packed releases dumped on us every few years, with the associated risks of such a big upgrade, we get much smaller releases on predictable dates. These releases have far fewer features of course, but there are several benefits to this model:

1. Easier to plan for. The predictable release cadence makes it easier not only for language developers to plan for, but also to plan our upgrades.

2. Higher quality. Frequent releases mean that if a feature isn't ready for this version of Java, it won't be long until the next release. This means far less pressure on language developers to rush to complete something, and, therefore, higher quality releases.

3. Steady supply of new features. Instead of three years of potential stagnation followed by a huge upgrade, we're getting regular updates of language features, garbage collector changes, and performance improvements.

The potential downside of moving to such a rapid release cadence is that many organizations simply can't keep up with upgrading every six months. This has been fully considered, not least of all because Oracle too will be impacted by this.

Long Term Support Releases

Oracle doesn't want to support every release for three (or more)years the way they used to support the previous releases. This would be a huge cost to them.

Image title

Figure 1: If Oracle supported every six-month release for three years, at some point in 2020 they'll be supporting six different versions of the language!

Instead, they've said one release every three years will be a Long Term Support release, which they will support for about three years. Java 8 was an LTS, the current LTS is Java 11, and presumably the next will be 17.

Image title  

Figure 2: Oracle selects a release every three years to provide long term support and updates for, and the other releases only live for six months.

The intermediate releases, though, will not be supported once the next release is out. This means that Java 9 was replaced by Java 10, and when Java 11 was released it superseded Java 10.

Image title

Figure 3: When developers upgrade from Java 8, they generally upgrade all the way to Java 11.

This explains this pattern of adoption — generally, people will not be on Java 9 or 10. If they were using it at any stage, they should have moved on to at least Java 11.

With the combination of short-term releases that one should migrate from as soon as a new release is out and long-term releases that are supported for at least three years, there are now potentially two main approaches to upgrading:

1. Upgrade to every release as it comes out. This means adopting the latest version of Java every six months. The benefit is that you'll get new features as soon as they're available, but this approach will probably only suit those who are used to upgrading their technology stack this quickly.

2. Upgrade to just the long-term support releases. This is a more familiar cadence for us Java developers. This gives us the downside of a Big Bang release every three years, but we have more time to evaluate the risks of such an upgrade.

There's a potential middle ground here: use the LTS release in production, but make sure your application is running against each six-month release in CI. Doing this should minimize the risk of a big bang upgrade while maintaining the required stability in production.

Oracle doesn't want to support every release for three (or more) years the way they used to support the previous releases. This would be a huge cost to them.

License Changes

There is a caveat to these long-term support releases. Oracle's position is that if you want support and updates for three years, you should be prepared to pay for them. So, if you want to use an LTS and get updates for three years, you will need to pay Oracle for their commercial JDK.

However, Oracle recognizes that not everyone wants to do this and that many people want to work in an open-source friendly way, so they now have two versions of their JDK (both functionally the same) with two different licenses. They have their commercial JDK, which is free to use in development and testing but you need to pay to use it in production; and they have a zero-cost OpenJDK build. The latter has an open-source GPLv2+CPE license, but will only be updated within six months of this release lifespan.

In a continuous delivery world, it makes sense for our language to evolve much faster than every three years.

This is actually good from a competition point of view. Oracle has contributed everything from their JDK back to OpenJDK, even the features that used to be commercial features like Java Flight Recorder and Java Mission Control. So, any JDK built from OpenJDK, which is pretty much everyone's JDK, will have all the features you're used to using, and maybe even some you haven't used before.

There are plenty of other vendors offering JDKs. Many are free, some will be updated or supported for different lengths of time from the Oracle JDKs. This document lists these different options, separating those that are free to download and use from those that have a commercial model. If this all seems a little overwhelming, a good starting point is to download your OpenJDK build from AdoptOpenJDK. This JDK is compatible with the Oracle JDK, you can get builds for the major operating systems and platforms, you can choose from two different JVMs (Hotspot and OpenJ9), they have committed to providing builds for the LTS releases for at least 4 years, and you have the option to purchase commercial support.

Since this topic can be quite complex, I highly recommend reading the Java Is Still Free document produced by the Java Champions for more in-depth information.

In Summary

Lots of things have changed since Java 8's release: we get releases every six months; the licensing, update, and support models have changed; and where we get our JDK from may have changed. On top of that, there were language changes, including the major changes that went into Java 9.

While all of these changes may seem daunting, their goal is to provide high quality, frequent, and predictable updates to one of the most popular languages in the world, in a way that is sustainable to those who work on and support the language.

It's worth understanding the impact these changes may have on your application and organization, because working out how to embrace them will ultimately allow you to make use of the improvements that have already gone into the language since Java 8, and will continue to evolve and improve the language every six months.

This article is featured in the new DZone Guide to Java: New Developments & Features. Get your free copy for insightful articles, industry stats, and more!

Java (programming language) Release (computing) Continuous Integration/Deployment Java Development Kit Open source

Opinions expressed by DZone contributors are their own.

Related

  • DevOps: CI/CD Tools to Watch Out for in 2022
  • Look, Ma! No Pods!
  • How to Publish Artifacts to Maven Central
  • 6 of the Best API Testing Tools in the Market

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!