As java releases are coming faster do we need to migrate the old java code base to latest version?

Question

Java releases are coming faster than expected do we need to migrate the code stuff which is old version to newer one to make it more performance based and upto date.

Answer 1

do we need to migrate the old java code base to latest version?

No.

Quite the opposite. You may decide to stick with deploying only the Long Term Support (LTS) (see Wikipedia) versions of Java. The promise: A version that will be actively supported for years with updates for critical bugs/issues but no new features or changes that might break existing deployments. The first such LTS version is scheduled for 2018-09, to be known as either Java 11 or 18.9 LTS (with year and month as release number).

Oracle has announced the changes in release cadences and support policies in late 2017 and again 2018-03. So it may take some more months until we know the exact nature of what releases are supported for how long by whom at what price.

In particular, you may want to avoid ever deploying Java 9 as it has had a brief life, with free-of-cost public updates from Oracle ending this month, 2018-03. By the way, Simon Ritter wrote about 109 New Features in JDK 10.

One of the core ideas behind the new regularly-scheduled “release train” plan is that hundreds of finished features were held up for years waiting on the Java 9 release. In a project as wide and diverse as the Java platform, it makes much more sense to ship whatever features are deemed ready every quarter or semester. If you find such features useful for your future deployments, you may choose to adopt that release. Or you choose to limit yourself to mere experimentation, while waiting for a future LTS version with those features.

more performance based

Future releases may or may not have improvements related to performance. And those improvements may or may not benefit your particular deployments. You will have to make a choice at that time about whether any of the particular improvements are worth migrating any of your particular deployments.

By the way, regarding performance, work is underway to make alternate garbage collector implementations easier to build and deploy. You may wish to keep your eye on developments there.

and upto date

As discussed above, “being up-to-date” is a choice you will have to make release-by-release. Making that choice will be easier as the list of changes to each release will be shorter and therefor easier to understand, digest, and test.

While Oracle and the community are committing to make each release fully qualified as stable and definitely not a “beta” disguised as an official release, change always brings some degree of risk. You may decide to stick with LTS versions to avoid the changes.

Early access

You can still access pre-release versions of Java. At this moment with Java 9 being the official release, Java 10 release candidate is available for trial. And JDK 11 has early access builds available.

Resources

See the official Oracle Java SE Support Roadmap. And be aware that Oracle has announced and confirmed that it is busily working to make their Oracle Java implementation virtually identical to OpenJDK, including contributing some of their add-on tools that are currently commercial products.

Also, you may want to consider alternate sources of implementation and support for Java. For example: Azul Systems with Zing & Zulu, IBM/Eclipse with OpenJ9, RedHat, and so on.

Answer 2

There is no need to do it, but the question is whether the rest of your code base is distributed in e.g. 1.8 compliant.

Having 1.8 is mostly a comfort for developers, keeping old code base is fine. But I've also been revisiting a few old classes dealing with e.g. Process creation and concurrency basic bricks and I'm very happy to have done so.

So do it where you clearly gain for doing it, iff. you think you can expect such recent JRE from your clients. If you already have recent JRE dependency, do some refactoring as code is reused and you revisit old APIs, if some new feature clearly kills your old solution, but not systematically is my advice.

Biggest issue with upping Java version is clients can't run newer versions, otherwise old code runs just fine on newer JRE.