Java upgrade with a local LLM: from Java 8 or 11 to 21 and 25, Spring Boot included

Upgrading Java with a local LLM in 2026

A Java upgrade from 8 or 11 to 21 or 25 with a local LLM works best in two layers. Deterministic OpenRewrite recipes do the mechanical changes first, and a coding model on a GPU in your own network then fixes what is left: build errors, removed APIs and failing tests, in a loop that compiles and tests after every change. One workstation with an NVIDIA RTX PRO 6000 Blackwell Workstation Edition or Max-Q runs such a model for a small migration team. Published tests show that the agent still needs an engineer who reviews every merge request.

This guide is for IT departments and software teams with dozens or hundreds of Java services on old versions whose code may not go to a cloud tool. It covers the target versions, what the recipes do and under which licence, what published agent tests show, the loop per service, Red Hat's route and the hardware for each stage. Our guides on COBOL modernisation with a local LLM, SAP ABAP with a local LLM and self-hosted Copilot alternatives cover the neighbouring tasks.

Which Java and Spring Boot versions to target

Oracle's Java SE support roadmap, updated on 20 October 2026, gives these dates for the long-term support (LTS) releases most services run on. Oracle states that it intends to publish an LTS release every two years, with Java 29 planned for September 2027.

Oracle Java SE Support Roadmap, page updated 20 October 2026, read on 30 October 2026; "or later" is Oracle's footnote. Dates of Oracle's own support offering; other JDK distributions publish their own.

The framework often decides the target more than the JDK. Spring Boot 3.0 required Java 17 and moved to Jakarta EE 10, and its migration guide states that "Jakarta EE now uses jakarta packages rather than javax". Spring Boot 4.0 also requires Java 17 or later; the current documentation for 4.1.2 says it is compatible up to Java 27. Its migration guide asks teams to move to the latest 3.5.x first and lists changes that touch most services: Jackson 3 moves its packages from com.fasterxml.jackson to tools.jackson, @MockBean and @SpyBean are removed in favour of @MockitoBean and @MockitoSpyBean, Undertow is dropped because it does not yet support the Servlet 6.1 baseline, and several starters are renamed, so spring-boot-starter-web becomes spring-boot-starter-webmvc. A service on Java 8 and Spring Boot 2 therefore passes through two framework generations and two package renames.

OpenRewrite recipes do the mechanical part

OpenRewrite rewrites source code with recipes that work on a lossless semantic tree of the project, a full model of its code and types. The rewrite-migrate-java repository names "Java 8, 11, 17, 21, and 25" as the current LTS versions and offers one composite recipe per step: Java8toJava11, UpgradeToJava17, UpgradeToJava21 and UpgradeToJava25, each building on the previous one. UpgradeToJava21, for example, runs 18 sub-recipes in order: it first applies the Java 17 migration, raises the build to Java 21, replaces deprecated APIs such as Thread.stop() and new URL(String), upgrades build plugins and rewrites switch statements with pattern matching. The Spring Boot 3.0 migration guide names OpenRewrite recipes among the tools that help.

The licences need a careful read before a project starts. OpenRewrite's licensing page states that the core libraries and the Maven and Gradle plugins are under Apache 2.0. The LICENSE.md files of the rewrite-migrate-java and rewrite-spring repositories point to the Moderne Source Available License, which grants use, copying, internal distribution and derivative works, and forbids making the software's functionality available to third parties as a service. The licensing page sums it up: "Individual organizations can consume and apply these recipes to their source code, but the recipes cannot be put into commercial products or be re-sold." It adds that consultancies may not charge clients for running them. By the same page, recipes for the latest Spring Boot, Spring Framework and Hibernate releases are "available to Moderne customers under the Moderne Proprietary License", so check the licence of each recipe before you build a Spring Boot step around it. For a company upgrading its own services, the recipes are therefore run by its own team; your legal counsel confirms the details for your case.

Recipes alone rarely finish the job. In the FreshBrew benchmark described below, OpenRewrite's UpgradeToJava21 recipe migrated 7.0 per cent of the projects to Java 17 under the benchmark's success conditions. For 69 of the 228 projects it could not build its syntax tree at all. The authors explain that OpenRewrite "operates deterministically; it can only apply transformations for which an explicit rule exists", and that it was built to save development time; the paper adds that it was not intended as an autonomous tool. That gap is where the model comes in.

What published agent tests show

FreshBrew is the most detailed public test of AI agents on Java upgrades. Its authors, from Google, the Max Planck Institute for Intelligent Systems, the ELLIS Institute Tübingen, Salesforce and Gologic, started from the 30,000 most-starred Maven projects on GitHub and kept 228 that build and pass their tests on Java 8, fail on Java 17, have at least 50 per cent test coverage and carry a permissive licence. A migration counts as successful only if the project compiles, all original tests pass unchanged and line coverage falls by no more than 5 percentage points, a guard against agents that delete failing tests.

FreshBrew, arXiv 2510.04852v3 of 3 October 2026, read on 30 October 2026. Share of 228 projects migrated successfully; the Java 21 column is a direct migration from 8 to 21. The paper does not state which Qwen3 size was used. Measurements by the authors.

The best agent in the test managed about half of these hard projects, so every result needs review. The open models tested then, Qwen3 and DeepSeek-V3, reached 10 to 16 per cent; for DeepSeek-V3 more than 70 per cent of failures were agent behaviour, such as loops, invented commands and edits that led nowhere, while GPT-4.1 failed most often on Java API incompatibilities. The newer open coding models were not part of the test: Qwen's card for Qwen3-Coder-Next reports 70.6 on SWE-bench Verified, a general software-repair benchmark, but no published Java migration result exists for it. A pilot on 10 to 20 of your own services, with the same three success conditions, gives the figure for your code.

The AI agent loop per service, on your own hardware

The work per service follows the same steps, and the build and the tests decide the result more than the model does.

1. Create a branch and run the OpenRewrite recipe for the next LTS step with the Maven or Gradle plugin.
2. Build with the target JDK and run the tests.
3. Hand the compiler errors and failing tests to the agent, which reads the code, edits files and runs the build again.
4. Stop when the build is green and coverage has not dropped, or after a fixed number of attempts, and record why.
5. Open a merge request that a developer reviews like any other change.

The agent is any tool that talks to an OpenAI-compatible endpoint and can run commands, such as OpenCode or Cline; our guide to Claude Code with a local model covers what changes when a vendor's CLI points at your own server. vLLM serves the model with tool calling enabled, as our guide to vLLM tool-calling parsers explains. The JDKs, Maven or Gradle and a mirror of your artifact repository run on the same network, so that builds work without internet access; our guide to an air-gapped LLM server shows the offline installation of the model side.

A practical consequence for sizing: while Maven compiles and runs tests, the agent waits and its session generates nothing. A migration engineer can therefore keep several services in the loop at once, and the GPU is sized by the sessions that generate at the same moment.

You can order the workstation alone, the setup of vLLM, Qwen3-Coder and an agent such as OpenCode alone, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Red Hat Developer Lightspeed for MTA

Red Hat offers the same pattern as a product. Developer Lightspeed is an add-on to its Migration Toolkit for Applications (MTA) that, according to Red Hat's product page, refactors Java applications in the IDE "guided by MTA's static code analysis and past migrations", with a knowledge base of earlier fixes, and lets teams use "the LLM of your choice–public or self-hosted–". The page states that the add-on is included with a Red Hat Advanced Developer Suite subscription.

The MTA 8.3 documentation, last updated on 30 September 2026, adds the details. The feature runs as a VS Code extension and is a Technology Preview, without Red Hat's production support terms. In agent mode it analyses the code, applies fixes the user approves, compiles and analyses again, with "a maximum of two attempts to fix an issue". Supported providers include cloud services, Ollama and OpenAI-compatible models served in OpenShift AI or Podman AI Lab, configured in a provider-settings.yaml file. Red Hat's own warning on model choice is plain: models deployed through Podman AI Lab "were found to be insufficient for the complexity of code changes", and the quality of the suggested fixes depends on the model's capabilities. The Konveyor project publishes a related open-source tool, Kai, under Apache 2.0, with its VS Code extension in a separate repository.

Cloud tools take the other route. AWS's documentation for Java upgrades with Amazon Q Developer, read on 31 October 2026, lists upgrades from Java 8, 11 and 17 to Java 17 and 21 for Maven projects, and requires that "your local network allows uploads to Amazon S3 buckets that Amazon Q uses to transform your code". With a local model, the code, the build logs and the prompts stay on your hardware.

Hardware for a migration team

The model choice sets the card. Qwen3-Coder-30B-A3B (30.5B parameters, 3.3B active, Apache 2.0) has 31.2 GB of FP8 weights and needs 6 GiB of cache per 64K-token session; Qwen3-Coder-Next (80B, 3B active, Apache 2.0) has 80.4 GB in FP8 and only 1.5 GiB per 64K session, as our guide to a private coding assistant derives. We size with our users-per-card rule: 90 per cent of the memory the driver reports, less 3 GiB per card, less the weights. We also cap each session at a planned 50 tokens per second from the card's memory bandwidth, an upper bound by our estimate.

Sessions of 64K tokens, BF16 cache (FP8 cache in brackets), by our users-per-card rule; usable 61.5 GiB (72 GB) and 83.0 GiB (96 GB) per card; planned = the smaller of memory and our 50 tokens-per-second ceiling from 1,344 GB/s (RTX PRO 5000), 1,792 GB/s (Workstation Edition, Max-Q) and 1,597 GB/s (Server Edition) per card (NVIDIA), about 3.3 GB (Coder-30B-A3B) and 3 GB (Coder-Next) of active weights per token. Estimates, not measurements; server rows as in our guide to a server for coding agents.

One card. For one or two engineers who work through services one after another, the RTX PRO 5000 Blackwell with 72 GB (300 W) carries Qwen3-Coder-30B-A3B. The RTX PRO 6000 Workstation Edition (600 W) or Max-Q (300 W) adds room for longer build logs and more services in the loop; a workstation with one Workstation Edition and a 350 W processor draws about 1.1 kW at the wall by our estimate (600 W plus 350 W, plus 15 per cent for the rest).

Two cards. Qwen3-Coder-Next, which Qwen's card reports at 70.6 on SWE-bench Verified, needs two cards as a TP=2 pair and leaves far more room for sessions because of its small cache. Two Workstation Edition cards are the realistic maximum for that edition; three or four Max-Q belong only in a chassis built for them with strong directed airflow.

A server. For a planned wave over hundreds of services, the inference node on our AI servers page with four RTX PRO 6000 Server Edition cards and 768 GB of DDR5 ECC memory carries two Coder-Next pairs and draws about 3.4 kW by our estimate. After the wave it keeps serving the developers' coding assistant; our guide to a server for coding agents sizes that use.

We build these workstations and servers to order; send us the number of services, their Java and Spring Boot versions and the size of your team, and our team replies with a configuration.

Planning a migration wave

A wave over many services goes faster when it is organised like a production line. Sort the services by framework and build tool, migrate one representative of each kind first, and turn the fixes that repeat into custom OpenRewrite recipes, which the licence allows for your own code. Fix the build environment early: JDK versions side by side, a local artifact mirror and build agents with enough CPU, because compiling and testing take more time than generation. Track for each service whether it compiled, whether the tests passed unchanged and how coverage moved, the three conditions FreshBrew used. Services with thin tests need more tests before the upgrade; our guide to AI test generation on-premise shows how a local model writes them. For services whose authors have left, a generated code wiki from a self-hosted DeepWiki gives the migration engineer an overview first. Prompts and answers contain source code, so decide before the first run whether your gateway logs them; our guide to an LLM gateway with keys and a query log covers the options.

The pilot on 10 to 20 services can start on one workstation; tell us about your services and we suggest the configuration that fits the pilot, the later wave and your budget.

FAQ