Backend application migration ideas

Dear All,

Festival Greetings for a Happy new year 2024,

We're on a planning, discovery to migrate a heavy load backend application from Java 1.8 . What are the factors do I need to consider and prepare a check list to do further study for selecting a different jvm based languages like Go/kotlin? If I'm considering to suggest to stick with higher java version for backend development, what're the highlighting points I should compare before choosing higher version of Java. What are the studies do I need to carry on to draw a drafted proposal? Any high level ideas would help me here to follow a direction. I'm new to this kind of study task. I should also keep in mind that the application should cloud neutral. should support different types of caches. Looking for some different suggestions/advices please. Some useful links will either help.  Thank you.

As a professional shop, I'd consider one of the LTS (Long-Term Support) releases of Java as a new base. Java 11, 17, and 21 are LTS releases, I think.

The biggest hurdle will be upgrading from Java 8. After Java 8, the introspection processes of Java changed significantly and as a result, the compiler will probably make many complaints. Be ssure also that when doing builds with libraries that you're using libraries that are compatible with newer Java as well.

Tim Holloway wrote:As a professional shop, I'd consider one of the LTS (Long-Term Support) releases of Java as a new base. Java 11, 17, and 21 are LTS releases, I think.

The biggest hurdle will be upgrading from Java 8. After Java 8, the introspection processes of Java changed significantly and as a result, the compiler will probably make many complaints. Be ssure also that when doing builds with libraries that you're using libraries that are compatible with newer Java as well.

Thanks for sharing your ideas. 1. Long Term Support
2. Compatibility (Noted) -  I wonder if you can mention some use cases where I can compare and choose a better compatibility match? For example, After Jdk 8, JAXB, CORBA were become obselete. During migration we should find equivalent replacements for the same  libraries. Do you mean the same? If so, jakarta replacement would be better or do I need to deep dive before considering this selection?

3. What different studies needed in terms backend migration? Any other ideas would you like to provide?

Good point that you should consider moving to Jakarta EE at the same time. Or at least upgrade Java, test everything and then do a Jakarta upgrade. Tomcat's last non-Jakarta release was Tomcat 9, I think, and most of the commercial JEE servers are selling Jakarta.

For most of the libraries that you'd pull using a system like Maven, you can find newer release versions of the same library. In a few cases I found when researching an upgrade for libraries used by the Ranch Forum webapp the package name changed because the ownership of the code had changed. Nothing specific to just because the Java version had changed.

JAXB has simply moved out of of the core Java distro and is fairly easily imported from its new external home. CORBA has been dead technology for about half the life of the Universe at this point and if you've got production apps running CORBA, I'd prioritize getting them to something that actually has support. In many cases, the equivalent these days would be Web Services, although I suppose that certain migrations might do using Remote Enterprise JavaBeans.