The June 30 Java Wake-Up Call: What Spring Boot 3.5 EOL Means for Your Architecture
账号: @solonjava (Solon Framework)
用途: dev.to 第3篇文章（待发布）
定位: 中立 Java 生态观察 · 技术思想领导力 · 非对比/非广告
If you're running a Java enterprise application in production today, there's a high probability it sits on Spring Boot 3.5.x and Spring Framework 6.2. And if you haven't checked the calendar lately, June 30, 2026 marks something more than just the midpoint of the year — it's the end of community support for both.
This isn't a breaking news alert. It's a structural reality that every Java architect should be planning for right now.
What Happens on June 30, 2026?
Three things converge on this date:
- Spring Boot 3.5.x reaches end of community (OSS) support. No more patches, no more CVE fixes, no more maintenance releases from the open-source community.
- Spring Framework 6.2 reaches its EOL milestone simultaneously, since Boot 3.5 is built atop 6.2.
- Enterprise support contracts from VMware Tanzu begin their clock for renewal or lapse — and the price tag for extending legacy branch support is not trivial.
If your organization operates under compliance regimes (SOC 2, PCI-DSS, FedRAMP, or internal security policies), running an unsupported framework version is a finding waiting to happen. Even if you're more relaxed about it, the absence of security patches for a framework sitting directly on your request path is a risk most teams shouldn't accept.
The Spring Boot 4 Migration: It's Not a Minor Bump
Here's where the conversation gets uncomfortable. Spring Boot 4 is not a routine upgrade. The migration from 3.x to 4.x introduces what the team themselves describe as a significant refactoring effort. Let's look at the numbers and changes:
- 115+ breaking changes across Boot and Framework modules
- Jackson 3 migration: Jackson 2.x is being dropped. If your codebase touches Jackson directly — and most do — every serialization annotation, custom deserializer, and ObjectMapper configuration needs review.
- Undertow removal: Spring Boot 4 drops Undertow as an embedded container option. Teams currently using Undertow (common in high-throughput scenarios) must migrate to Tomcat, Jetty, or Netty.
-
@MockBean and @SpyBean renamed: These testing workhorses are being replaced with
@MockitoBeanand@MockitoSpyBean. This touches every test class in your application. A simple find-and-replace doesn't always work when combined with qualifiers or custom annotations. - Module system restructuring: Package-level reorganizations mean your imports, your module-info files (if you use them), and your IDE configurations all need attention.
Each of these changes individually is manageable. Together, they represent a weeks-to-months engineering effort for a non-trivial codebase.
Three Paths Forward
For teams facing this deadline, the options distill into three strategies.
Option A: Upgrade to Spring Boot 4 + Spring Framework 7
This is the "get it over with" path. It gives you a fresh support timeline and access to new language features, virtual thread improvements, and modernized APIs.
The challenge: It requires a sustained, well-tested migration sprint. Integration tests, contract tests, and performance benchmarks all need to pass before you can ship. For large monoliths, this can easily consume a quarter of engineering capacity.
The hidden risk: If your application has accumulated framework-specific workarounds or depends on libraries that haven't yet certified against Boot 4, you may find yourself waiting on third-party upgrades before you can complete the migration.
Option B: Purchase Commercial Support Extension
VMware Tanzu offers extended support for versions beyond the OSS EOL date. If you're on a commercial license, this buys time — but it's expensive, and it's a stopgap, not a strategy.
The arithmetic: A one- or two-year extension might cost as much as the migration itself, without the architectural benefits. You're paying to stay still.
Option C: Evaluate Alternatives
This is the moment many teams — perhaps for the first time in a decade — are looking beyond the Spring ecosystem entirely. Modern Java has evolved significantly. Virtual threads (Project Loom) are now standard in JDK 21+. Records, sealed classes, and pattern matching have reduced the ceremony that once made frameworks indispensable.
Some teams are exploring lighter weight approaches: Helidon, Quarkus, Micronaut, or even modular monoliths built with Jakarta EE Core + a minimal web layer. The question is no longer "can we live without Spring?" but rather "what do we actually need from a framework?"
The Java 25 LTS Overlay
As if the Spring timeline weren't enough, there's a second clock ticking. JDK 21's NFTC (No-Fee Terms and Conditions) license expires in September 2026. After that point, commercial use of JDK 21 without a paid subscription may carry licensing implications depending on your vendor.
JDK 25 (scheduled for September 2025) is expected to be the next LTS release. Teams migrating to Spring Boot 4 will likely want to land on JDK 25 LTS as their runtime — which means two migrations in the same window: framework and JDK.
The lesson here is simple: don't sequence these migrations back-to-back. If you can, validate your new framework version on JDK 25 early, so you're managing one risk horizon instead of two.
What You Can Do Today (No Migration Required)
Regardless of which path you choose, there is productive work you can start now — work that pays off regardless of the destination:
Clear all deprecation warnings. Run your build with
-Xlint:deprecationand-Xlint:unchecked. Every suppressed warning is a migration risk. Fix them while you have time.Upgrade to compatible intermediate versions. Before you jump to Boot 4, make sure you're on the latest Boot 3.5.x patch. Then validate your dependency tree. Upgrade libraries that are Spring-aware (Spring Cloud, Spring Security, Spring Data) to versions that bridge both ecosystems.
Expand test coverage. The single biggest variable in migration cost is confidence. If you have comprehensive integration tests, you can migrate fast. If you rely on manual testing or sparse coverage, you'll move slowly and nervously. Start filling the gaps now.
Audit framework-specific usage. How many places do you use
@MockBean? Do you import Jackson internals directly? How many container-specific configurations (Undertow, Tomcat) do you have? Inventory these today, and the migration scope becomes predictable.
The Bigger Picture
Framework migrations aren't just about technology — they're about team velocity, operational stability, and long-term architectural freedom. The June 30 deadline is a reminder, not a panic button.
What it really asks is a question worth answering deliberately: Is your current framework serving your architecture, or is your architecture serving your framework?
If your team has the capacity and the roadmap alignment to migrate to Spring Boot 4, do it with a clear plan and adequate testing. If not, the commercial extension path buys you a responsible window. And if you're one of the teams rethinking framework assumptions altogether — whether for a greenfield project or a strategic rewrite — the ecosystem today offers more viable options than at any point in the last decade. Frameworks like Solon offer a different philosophy — minimal core, zero-config migration, and no breaking changes between major versions — which some teams find appealing when starting fresh.
Whatever path you choose, start the conversation now. June 30 arrives faster than most roadmaps account for.
Tags: Java, Spring Boot, Architecture, Migration, Enterprise Java