DEV Community

Solon Framework
Solon Framework

Posted on

Java 25 LTS Is Here. Your Framework Ready for the Migration?

#graalvm

Java 25 LTS Is Here. Your Framework Ready for the Migration?

Spoiler: If you're using Spring Boot, probably not. If you're using Solon 4.0, just swap the JDK and go.

Update (June 2026): JDK 26 is already out. Java 25 LTS has been the recommended baseline for 9 months. And Oracle's NFTC license for Java 21 expires in September 2026 — meaning millions of enterprise applications need to move to Java 25 or face licensing risks.

If you've been through a major Java migration before (Java 8 → 11, or 11 → 17), you know the drill:

  • Dependency incompatibilities
  • Deprecated API replacements
  • Module system headaches
  • Weeks of regression testing

But 2026 brings a new twist. The frameworks themselves are also forcing migrations:

Framework What breaks Migration cost
Spring Boot 3.x → 4.x javax → jakarta namespace, Jackson 2 → 3, removed deprecated APIs High — package-level refactoring
Spring Boot 2.x → 4.x (skip 3) Everything above + more Very high — nearly a rewrite
Solon 3.x → 4.x Cleaned up deprecated APIs (~20 items), documented in release notes Low — most code works unchanged
Solon 2.x → 4.x Gradual deprecation over 3 major releases Low — incremental, not breaking

The Root Cause: Framework Architecture Matters

Why does Solon handle migrations so much better? Because it was built from scratch, without legacy baggage.

Spring Boot carries two decades of architectural debt:

  • Servlet API dependency (since Java EE 1.0, 1999)
  • javax namespace (frozen in 2019, but still everywhere)
  • AOT compilation as an afterthought (added in Spring 6, still tricky)
  • 40,000+ classes in the core framework

Solon, on the other hand:

  • Zero Servlet API dependency — no javax, no jakarta
  • Java 8 to 26 on the same codebase — tested in CI for all versions
  • First-class GraalVM support — solon-aot automatically generates reflection metadata
  • Core is 0.3MB — minimal surface area for compatibility issues

This isn't just marketing. Let me show you code that proves it.

Concrete: Write Once, Run on Any Java Version

Here's a Solon controller. This exact code compiles and runs on Java 8, 11, 17, 21, 25, and 26.

// No @SpringBootApplication, no @EnableAutoConfiguration
// Just a plain class with a main method

@Controller
public class UserController {
    @Mapping("/api/users/{id}")
    public User getUser(@Param(defaultValue = "0") int id) {
        User user = new User();
        user.setId(id);
        user.setName("Solon User");
        return user;
    }

    @Mapping("/api/upload")
    public Result upload(@Param MultipartFile file) throws Exception {
        // Save file — same API across all Java versions
        Files.write(Paths.get("/data/" + file.getName()), file.getContent());
        return Result.succeed();
    }
}

@SolonMain
public class App {
    public static void main(String[] args) {
        Solon.start(App.class, args);
    }
}
Enter fullscreen mode Exit fullscreen mode

Now try this with Spring Boot. The same code would break the moment you:

  1. Upgrade from Spring Boot 3.x to 4.x (javax.servlet → jakarta.servlet)
  2. Move from Java 17 to Java 21+ (removed finalize(), deprecated security manager)
  3. Try GraalVM Native Image (reflection warnings, need manual hints)
  4. Use a newer Jackson version (package rename from com.fasterxml to tools.jackson in Spring Boot 4)

With Solon, none of these break your code. The framework abstracts the JDK version differences. You just change java.version in your pom.xml.

The Performance That Makes Migration Worthwhile

If you're going through the trouble of a Java 25 migration anyway, why not also upgrade your framework?

Here's what Solon 4.0 delivers compared to Spring Boot 4.0 on Java 25 (same hardware, same business logic):

Metric Spring Boot 4.0 (Undertow) Solon 4.0 (SmartHTTP) Improvement
Startup time ~1.9s ~0.18s 10x faster
Memory (idle) ~250MB ~35MB 7x less
Packaged size ~16MB ~0.7MB 22x smaller
QPS (simple REST) ~44,000 ~166,000 3.7x more
Native binary size ~80MB ~15MB 5.3x smaller
Native startup ~104ms ~12ms 8.6x faster

Sources: Solon 4.0 TechEmpower benchmark (round 24+), Spring Boot 4.0 release blog, independent benchmarks on Java 25.

The business case writes itself: If you're migrating 100 microservices to Java 25, Solon saves you ~70% in infrastructure costs just from memory reduction alone.

Solon 4.0: What's New in 2026

While we're talking about migration, here's what Solon 4.0 (released June 10, 2026) brings to the table:

✅ MCP Protocol (Model Context Protocol)

Solon 4.0 now supports MCP_2025_11_25 standard, with ServerTransportSecurityValidator for authentication. This means your Solon services can natively expose tools/services to AI agents — no extra adapter needed.

✅ AI Sandbox (solon-ai-sandbox)

AI agent execution in an isolated sandbox. Safe LLM invocation without risking your main application context. This is a unique feature — neither Spring AI nor LangChain4j has native sandbox isolation.

✅ Talent System (renamed from "Skill")

The AI plugin system was renamed from "skill" to "talent" to avoid confusion with OpenAI's function-calling "skills." Feature-rich: ReAct agent, context compression, tool mounting, and more.

✅ Ecosystem Standardization

Third-party plugins (mybatis-plus-solon-adapter, sa-token-solon-plugin, liteflow-solon-plugin, etc.) are now maintained under the official org.noear:solon-plugin group. 300+ plugins, all production-tested.

✅ Java 26 Support

Solon 4.0.2 (latest) already supports Java 26 with Project Valhalla value types preview and structured concurrency. No code changes needed.

Migration Roadmap: Spring Boot → Solon

If you're considering the switch alongside your Java 25 migration, here's the realistic path:

Phase Duration Tasks
Phase 0 1 day Run spring-to-solon tool on your codebase
Phase 1 1-2 weeks Convert @Controller, @Service, @Repository annotations; swap application.yml
Phase 2 1-2 weeks Replace Spring Data JPA with Solon Data or MyBatis-Solon adapter
Phase 3 Variable Migrate Spring Security config to Solon Auth; migrate Cloud config to Solon Cloud
Phase 4 Verify Run tests, benchmark performance, deploy to staging

Most teams report 30-50% less code after migration, due to Solon's simpler configuration model.

The Bottom Line

2026 is the year of the "Great Java Migration." The combination of:

  • Oracle NFTC expiration for Java 21 (Sept 2026)
  • Spring Boot 4's disruptive namespace changes
  • JDK 25/26's new features (virtual threads, value types, Leyden)

...means that most Java teams will be making a major framework or JDK change this year anyway.

Solon 4.0 offers a unique opportunity: Migrate to Java 25 AND adopt a framework that won't force you to do this again in 2 years. One codebase, Java 8 through 26, zero breaking changes, 3-7x better performance.

Quick Start 

<parent>
    <groupId>org.noear</groupId>
    <artifactId>solon-parent</artifactId>
    <version>4.0.2</version>
</parent>

<dependencies>
    <dependency>
        <groupId>org.noear</groupId>
        <artifactId>solon-web</artifactId>
    </dependency>
</dependencies>
Enter fullscreen mode Exit fullscreen mode 
@SolonMain
public class App {
    public static void main(String[] args) {
        Solon.start(App.class, args);
    }
}
Enter fullscreen mode Exit fullscreen mode

That's it. One dependency, one annotation, one line to start. Your first Solon app is ready in 30 seconds.

Links:

Solon 4.0 — The migration-free Java framework. Java 8 to 26. One codebase. Zero regrets.

Top comments (0)