Spring AI 2.0 GA Ships May 28: Java’s AI Stack, Rebuilt

Spring AI 2.0 ships as General Availability on May 28. If you have been waiting for a production-stable AI framework for the Java ecosystem — something with Spring Boot autoconfiguration, 20+ model providers, and real MCP support — this is it. The upgrade from 1.x or from any M-series build is not trivial, though. Spring Boot 4 is now a hard dependency, Jackson 3 replaces Jackson 2, and every model provider options class dropped its setters. Here is what you need to know before the GA drops.

Spring Boot 4 Is the Gate

You cannot use Spring AI 2.0 on Spring Boot 3.x. Full stop. Spring Boot 4.0 is a hard dependency, which means Spring Framework 7, Java 17 minimum (21 recommended), and Jackson 3 all come along for the ride whether you want them or not.

For most teams, the upgrade path is not one step but two: first move to Spring Boot 3.5 to surface and fix all deprecation warnings, then jump to 4.0. Skipping the intermediate step usually means being surprised by removed APIs at compile time — not a fun afternoon.

There is also a deadline forcing the issue. Spring Boot 3.5 and Spring Framework 6.2 both reach end-of-life on June 30, 2026 — exactly 33 days after the GA drops. After that date, neither version receives security patches or CVE fixes from the Spring team. Teams that want Spring AI 2.0 and long-term support do not have the luxury of a leisurely migration.

What Actually Breaks

Jackson 3: Your Highest-Risk Change

Jackson 3 moves its packages from com.fasterxml.jackson to tools.jackson. That rename is visible — it fails at compile time, you fix it, done. What is not visible: Jackson 3 changed date serialization defaults and property ordering defaults. Your JSON output can change shape silently. Downstream clients parsing Unix timestamps or depending on stable field order will break in ways that have nothing to do with your Spring AI upgrade and everything to do with a missing test.

Run your full integration test suite before and after the Jackson upgrade, and diff the JSON output explicitly. This is the change most teams will underestimate. The Spring team’s Jackson 3 migration guide covers the edge cases in detail.

Setters Are Gone — Builders Are the API

Every model provider options class — OpenAI, Anthropic, Bedrock, Mistral, Ollama, and more — dropped setter methods across the 2.0 milestones. If your codebase calls setTemperature(), setMaxTokens(), or setModel() on any AI options object, it does not compile against Spring AI 2.0. The fix is mechanical — every class has a .builder() factory:

// Broken in Spring AI 2.0
var options = new OpenAiChatOptions();
options.setTemperature(0.7);
options.setModel("gpt-4o");

// Correct — builder pattern required
var options = OpenAiChatOptions.builder()
    .model("gpt-4o")
    .temperature(0.7)
    .build();

A global search for .setTemperature, .setModel, and .setMaxTokens across your codebase will find everything that needs updating in one pass.

PromptChatMemoryAdvisor Is Removed

PromptChatMemoryAdvisor has been removed. Chat memory advisors now require an explicit conversationId. This is a correctness improvement — implicit state management was a bug waiting to happen — but it means auditing every chat memory usage in your application and wiring in explicit IDs. It is not a large change, but it is easy to miss during a dependency upgrade.

What You Gain: MCP Is Now First-Class

Model Context Protocol was a separate dependency in the 1.x series. In Spring AI 2.0 it is merged into core, running on MCP Java SDK 0.18.2 — up from 0.10.0. That is a significant jump incorporating a year of MCP spec evolution and upstream improvements.

You get @McpTool, @McpResource, @McpPrompt, and @McpComplete annotations for exposing server-side capabilities, plus client-side annotations for handling notifications, sampling, and progress. A single Spring bean can simultaneously act as an MCP client and an MCP server — which matters if you are building agent chains where one agent consumes tools from another.

Exposing an existing Java service method as an MCP tool takes a single annotation:

@Component
public class ProductTools {

    @McpTool(name = "get_product", description = "Fetch product details by ID")
    public Product getProduct(
            @McpToolParam(description = "Product ID", required = true) String id) {
        return productRepository.findById(id).orElseThrow();
    }
}

Enable the annotation scanner in application.yml and Spring AI handles the MCP protocol automatically:

spring:
  ai:
    mcp:
      server:
        annotation-scanner:
          enabled: true

The full annotation reference is in the Spring AI MCP Annotations documentation. For teams building AI agents that need to expose Java capabilities to Claude, Gemini, or any MCP-compatible client, this is the integration story that 1.x was missing.

Migration Checklist

1. Upgrade to Spring Boot 3.5 first — surface and fix all deprecation warnings before touching Boot 4. The M7 release notes list all APIs changed across the final milestones.
2. Update pom.xml to Boot 4.0 + Spring AI 2.0 — set parent version to 4.0.5, add Spring AI BOM 2.0.0
3. Fix Jackson 3 imports — change com.fasterxml.jackson to tools.jackson; replace ObjectMapper with JsonMapper where direct use is needed
4. Convert options setters to builders — global search for setter calls on AI options classes, convert to .builder().build() pattern
5. Wire explicit conversation IDs — remove PromptChatMemoryAdvisor references; supply conversationId explicitly in all chat memory advisors

Should You Ship on Day One?

For greenfield projects: yes. Spring AI 2.0 with Boot 4 is the stack to start on in 2026. The MCP-first architecture, immutable builder APIs, and stable 20+ provider abstraction give you a foundation that will not require another major migration cycle soon.

For existing 1.x applications: the decision depends on your test coverage and how close you are to the June 30 Boot 3.5 EOL. The Jackson 3 changes are subtle enough that teams with thin integration test coverage should budget a sprint for JSON output validation before cutting over. If you need commercial support during the transition, HeroDevs covers EOL Spring versions as a bridge option. The framework is ready. Whether your test suite is ready is the real question.