VertexWare

Java 8 to Java 21, without a rewrite

I move Java applications off unsupported runtimes and frameworks in small, tested steps while the system stays in use. It is what I do on my current project, a public-sector application moving from Java 8/Karaf to Java 21/Spring Boot.

Describe your problem

Signs it is time

  • The application still runs on Java 8 or 11, and a newer JDK breaks the build.
  • It depends on Spring Boot 2, Karaf/OSGi, or an application server nobody wants to touch.
  • Security scanners flag libraries you cannot update without updating everything else.
  • New developers need days to get the project running locally.

What usually has to change

  • JAXB, JAX-WS and other modules removed from the JDK come back as explicit dependencies.
  • The javax.* namespace becomes jakarta.* for Spring Boot 3 and current Jakarta EE.
  • Build plugins, test libraries, and bytecode tools need versions that understand Java 21.
  • Code and libraries that reach into JDK internals by reflection need replacing or explicit access.

How I approach it

  • Inventory first. I map the modules, dependencies, and runtime assumptions, and note which parts have tests and which do not.
  • A reproducible build. Before any upgrade, the project has to build and run the same way on every machine and in the pipeline.
  • Upgrade in stages. Dependencies, frameworks, and the JDK move in deployable steps rather than in one long branch that never merges.
  • Tests where the risk is. I add tests around the code the upgrade touches most, instead of chasing a coverage number.
  • Delivery continues. Feature work and bug fixes carry on during the migration. On SIB-BW2 they run alongside it.

Current project: SIB-BW2

SIB-BW2 manages street infrastructure for a German state administration. I work on its move from Java 8/Karaf to Java 21/Spring Boot, built about 30 of its reports, and developed the migration tool that moves thousands of structures (Bauwerke) to the ASB-ING standard as needed.

Read the case study

What you get

  • A written inventory of the runtime, dependencies, and risks, with an upgrade order
  • The upgraded application, deployed in stages
  • Tests around the code the upgrade changed
  • Documentation of what changed, and how to build, run, and release the application

When I would advise against it

  • The application will be replaced within a year anyway.
  • It is small enough that rebuilding it on a current stack costs less than upgrading it.

Questions about Java upgrades

Do we have to go through Java 11 and 17 first?
Not necessarily. The JDK can often move straight to 21, but libraries and frameworks usually move in stages because each has its own breaking changes. The inventory decides the order.
Do we need Spring Boot 3?
If the application uses Spring Boot 2, yes, eventually: version 2 no longer receives open-source updates. Spring Boot 3 requires Java 17 or later and the jakarta.* namespace, so it is usually part of the same project.
Can the system stay in use during the migration?
Yes. That is the point of upgrading in stages. Each stage is deployed and checked before the next one starts.
What about applications on Karaf/OSGi or an application server?
They need one more step: moving to a runtime that current frameworks support, usually Spring Boot with an embedded server. That is the move I am making on SIB-BW2.

Have a process or software problem worth checking?

A short conversation is enough to decide whether an audit, a small build, or no custom software is the right next step.

Describe your problem