Sun Microsystems first introduced Java to the development world in 1995. Since 2012, the platform-independent language has ranked at or near the top of the list of most popular programming languages.
Much of Java’s popularity stems from its cross-functionality, portability, powerful development tools and increasing language diversity.
Many companies that have relied on Java for years continue to run older versions, but recent changes to support for legacy versions and an accelerated feature release schedule have many IT teams wondering if now is a good time to migrate to the latest Java version. The short answer is, “Yes.”
To migrate or not to migrate? It’s not really a question.
When Java 10 was released in March 2018, Oracle overhauled the feature release schedule as well. Historically known for its slow release cadence, Oracle announced it were switching Java to a biannual feature release schedule, replacing the drawn-out three-year cycle that normally centered around major feature changes.
Java’s more agile release cadence with smaller, easy-to-implement features helps developers innovate and stay competitive in a rapidly changing marketplace. Some long-term Java programmers originally balked at having to update so frequently.
With public support for the Java 8 long-term support (LTS) version having ended in 2019 and the three-year tenure of Java 11 LTS coming to a close in 2021, the release of Java 17 LTS in September 2021 is a good catalyst to start planning a migration to the latest Java version (or at least a newer one than you are running now).
Each new version of Java introduces new language features and security improvements, but those aren’t the only reasons to consider an upgrade. Other reasons include to:
- Optimize performance.
- Write code more efficiently.
- Mitigate security risks.
- Have public support.
- Receive access to security patches.
- Gain access to third-party Java libraries.
- Improve staffing (not many Java developers still work on Java 5/6 projects).
Although migration projects require effort and budget, in the long run, there are no significant disadvantages of migrating to a newer Java version and plenty of benefits.
Get started with your Java migration.
Now that you’ve decided to migrate to a newer Java version, the question becomes “Which version is the best fit for my needs?” The short answer is, ‘It depends. On what your’e trying to accomplish.”
Before committing to a specific version, you first need to understand your migration objective: Is it innovation or stability?
Innovation: Migrate to the latest version.
Developers keen on rapid innovation who want to leverage new features in production as soon as possible should migrate to the latest release. These developers are willing to update frequently so they can use the latest and greatest features and plan to upgrade to each new Java version as it deploys to ensure continued support.
Stability: Migrate to the most current LTS.
Developers who prefer stability and don’t plan to leverage each new feature update should migrate to the most current long-term support version. This version is updated on a 3-year cycle and will include the latest features and functionality and extended support without the need for frequent updates.
Compare key features by version.
| Java 8 | Java 9 | Java 10 | Java 11 | Java 12 | Java 13 | Java 14 | Java 15 |
| Lambda Expressions | Modularity | Local variable type inference | Local-Variable Syntax for Lambda Parameters | JVM Changes | Text Blocks | Switch Expressions (Standard) | Edwards-Curve Digital Signature Algorithm (EdDSA) |
| Pipelines and Streams | JShell | Application class-data sharing | A No-Op Garbage Collector | Switch Expressions | Switch Expressions Enhancements | Pattern Matching for instanceof (Preview) | Sealed Classes (Preview) |
| Date and Time API | Stream improvements | Thread-local handshakes | Dynamic Class-File Constants | File mismatch() Method | Reimplement the Legacy Socket API | Helpful NullPointerExceptions | Hidden Classes |
| Default Methods | HTTP 2.0 Client API | Root certificates | Remove the Java EE and CORBA Modules | Compact Number Formatting | Dynamic CDS Archive | Records (Preview) | Pattern Matching for instanceof (Second Preview) |
| Parallel operations | Process API | Garbage collector interface | Teeing Collectors in Stream API | ZGC: Uncommit Unused Memory | Text Blocks (Second Preview) | A Scalable Low-Latency Garbage Collector | |
| Nashhorn JavaScript Engine | Microbenchmarks | Time-based release versioning | Java Strings New Methods | FileSystems | Text Blocks | ||
| Records (Second Preview) |
Some Pro Tips for Successful Migration
Every Java release comes with a compatibility guide outlining which components are not backward-compatible. This guide lets developers know what to expect when upgrading an application from a previous version, such as from JDK 6 to JDK 7 or from JDK 7 to JDK 8. Those skipping a version, for example from JDK 6 to JDK 8, should consult the JDK 7 guide for any informational gaps.
Java 8 is backward compatible with previous versions. So, the migration process should run smoothly. But, as Java 8 has gone through the End of Public Updates process, you have to consider upgrading to at least Java 11.
Migrating to Java 9 or Java 10 may create issues as some libraries are no longer part of JDK. Although this is good since it cleans the application, you will need to define dependencies for your project.
Short-term releases such as JDK 9 and JDK 10 are normally used by developers for testing and experimentation rather than production, which likens the pace of the new release cycle to the old one.
Case study: A Java 8 Migration Success Story
“Great professionalism, flexibility and the ability to keep a stable team are the key success factors of our long-lasting partnership with Belatrix.”
—Nicolas Gibert, software development director, OSB
When a client needed help migrating a project from Java 6 to Java 8, a Belatrix team jumped in to help make it a success.
The application being migrated was still being maintained and developed, and the technology stack included Java, Spring, Hibernate, Camel, ActiveMQ, PostgreSQL and CXF. So, the Belatrix team started with an in-depth analysis of Java 7 and Java 8 compatibility guides to predict what problems they might run into.
The team then carried out an additional analysis to identify third-party dependencies and determine what versions to upgrade them to in order to take full advantage of Java 8 features.
Next, the team analyzed all of the tools being used on the project, including continuous integration, deployment servers and code analysis tools, to ensure each of the systems was ready for the migration to Java 8.
After the analyses were complete, Belatrix prepared and presented the migration plan to the client. When the benefits and processes were clearly explained and fully understood, the client enthusiastically approved the plan and it was time to get started.
The team began building the codebase using JDK 8 to determine whether the application would compile and run, then continued with the deployment phase, upgrading the deployment server and deploying the application.
After they performed non-regression tests and fixed some minor bugs, the Belatrix team proceeded to change the JDK on the development, QA, stage and production platforms.
It was a success! As soon as the migration process finished, the client started using the new language features, leaving the old code to be refactored by request through the Belatrix technical board.
Learn More About Migrating
If you’re still on a pre-Java 8 release, it’s time to migrate to avoid accumulating technical debt. Like a snowball, the longer you wait to migrate, the bigger the feature gap becomes. And in the end, we all want cleaner code, better performance, fewer security risks and happier development teams.
Editor’s note: This post was originally published in June 2019 and has been updated for accuracy and comprehensiveness.
