Many of us are working on Java projects that have started years ago, likely implemented in Java 5 or 6. Some of them might be planned to migrate to a newer version of Java.
If you’re wondering why you should migrate, which version to choose and how to do it, look no further. Pentalog has successfully made the transition to newer Java versions for several client projects and is here to answer all your questions.
Java will no longer have “major” releases
As of Java 10, released on March 2018, Oracle has put Java on a biannual release schedule. In September 2017, Mark Reinhold, Chief Architect of the Java Platform, proposed to change the release timetable to “one feature release every six months” rather than the current three-year schedule. This decision is driven by the fact that Java now competes with multiple platforms that are evolving at a more rapid pace.
For Java to remain competitive it must not only continue to move forward but it must do so faster. Java’s twice-yearly release schedule makes the delivery of innovation more seamless.
Feature releases will be smaller and therefore easier to adopt. Public updates for these short term versions will be available for 6 months after the release, until they are replaced by the newest feature release.
Every third year, starting in September of 2018 with Java 11 will be a long-term support release (LTS) with updates available for at least three years and quite possibly longer.
Why Migrate to Newer Java Versions?
The most obvious reasons for upgrading from an older release are new language features and security improvements.
Here are some additional (but not less important) reasons to take into consideration:
New language features
Writing code more efficiently
Oracle recommendation to uninstall pre-8 versions to avoid security risks
Older releases no longer publicly supported
Increasing cost of vendor support on older releases as you have to pay for support to get security patches
Difficulty of retaining Java developers to work on Java 5/6 projects
Third party Java libraries no longer being developed and supported
Are There Disadvantages When Migrating?
No worries! There are no significant disadvantages of migrating to a newer version.
Bottom line, the longer you delay upgrading, the larger the Java version jump involved, meaning more work and potential pain involved.
Do you need an experimented Java development team? It’s ready to launch your software project in only 2 week!
What’s Your Migration Objective: Innovation or Stability?
Regardless of project demands’– ask any developer – there are 1 or 2 arguments backing up the rationale behind adopting a certain Java version:
Developers keen on rapid innovation to leverage new features in production as soon as possible, can use the most recent feature release or an update release thereof and upgrade to the next one when it deploys.
Developers who prefer stability and to pass on new features of each “feature release” can look forward to the three-year schedule for its long-term support (LTS) releases. Java 8 was quite the milestone in the Java programming language and brought Java development to a completely unprecedented level, but this version has gone through the End of Public Updates process for legacy releases. Java 11 being the most recent LTS release and 17 being the next.
The Sparkling Features of Java 8 – Java 14
|Java 8||Java 9||Java 10||Java 11||Java 12||Java 13||Java 14|
|Lambda Expressions||Modularity||Local variable type inference||Local-Variable Syntax for Lambda Parameters||JVM Changes||Text Blocks||Switch Expressions (Standard)|
|Pipelines and Streams||JShell||Application class-data sharing||A No-Op Garbage Collector||Switch Expressions||Switch Expressions Enhancements||Pattern Matching for instanceof (Preview)|
|Date and Time API||Stream improvements||Thread-local handshakes||Dynamic Class-File Constants||File mismatch() Method||Reimplement the Legacy Socket API||Helpful NullPointerExceptions|
|Default Methods||HTTP 2.0 Client API||Root certificates||Remove the Java EE and CORBA Modules||Compact Number Formatting||Dynamic CDS Archive||Records (Preview)|
|Parallel operations||Process API||Garbage collector interface||Teeing Collectors in Stream API||ZGC: Uncommit Unused Memory||Text Blocks (Second Preview)|
A Pentalog’s Client Migration Story
“Great professionalism, flexibility and the ability to keep a stable team are the key success factors of our long-lasting partnership with Pentalog.” Nicolas GIBERT, Software Development Director OSB
A Pentalog Agile software development team initiated a migration for a project from Java 6 to 8. The application was still maintained and developed. The technology stack included Java, Spring, Hibernate, Camel, ActiveMQ, PostgreSQL and CXF.
We started with an in depth analysis of Java 7 and 8 compatibility guides to predict what problems might hinder progress. Then, an additional analysis was carried out regarding 3rd party dependencies used to determine what versions to upgrade them to in order to take full advantage of Java 8 features.
We analyzed all the tools utilized (continuous integration, deployment servers, and code analysis tools) in ensure these systems were ready for Java 8.
A migration plan was prepared, presented to the client and met with enthusiasm as the benefits is and process were clearly explained and understood.
We started by building the codebase using JDK 8 to see if the application would compile and run.
We continued with the deployment phase: upgrading deployment server and deploying the application.
Non regression tests were performed, along with some minor bug fixing and we proceeded to change the JDK on developers, QA, stage and production platforms.
It was a success! Right after the migration process finished we started using the new language features, leaving the old code to be refactored as needed by submitting specific requests to our technical board.
Pentalog has over 150 highly skilled full-time Java developers.
Download your price catalog and we’ll wrap up a team for you in no time!
Additional Java Tips
Each release comes with a compatibility guide specifically ooutlining when components are not backwards compatible. This guide provides information about what one might encounter when upgrading an application from a previous version, such as from JDK 6 to 7 or from JDK 7 to 8. Those skipping a version (JDK 6 to 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 the upgrade to Java 11 at least.
Migrating to Java Versions 9/10 may bring some issues as some libraries are no longer part of JDK. While this is good news as it cleans the application, you will need to define additional dependencies for your project. Short-term rapid releases like JDK 9 and 10 are mostly treated by developers as software for testing and experimentation rather than production, which likens the pace of the new release cycle to the old one.
The best possible advice I could give if you are still on a pre-Java 8 release is to migrate to a newer version as soon as possible to avoid accumulating technical debt. Much like a snowball: the bigger the gap between yours and the latest version, the bigger the difficulty will be to migrate in terms of resources and expertise. And, after all, we all want cleaner code, better performance, minimization of security risks and a happy development team.