Java’s Savior Returns: Spring Founder Launches Production‑Grade JVM Agent Framework

For more than a decade the refrain “Java is dead” has been repeated, especially as AI exploded and Python became the de‑facto language for building agents. Rod Johnson, the original author of Spring, returns with a framework called Embabel that aims to let Java developers write agents on the platform they know best.

What the author did back then

When the author entered the industry, Enterprise Java Beans (EJB) dominated; they required many interfaces, XML configurations, and long deployment cycles, making Java feel bloated. In 2002 Rod Johnson published a book with a simple code example that became the Spring Framework, allowing plain Java objects to act as components without special interfaces, simplifying configuration and testing.

Spring later eclipsed EJB, and the Spring family (Spring Boot, Spring Cloud) kept Java relevant for another decade, especially as AI emerged.

The current situation mirrors the past

Surveying modern agent frameworks (LangChain, LangGraph, CrewAI) shows they are all Python‑centric. Companies often hire Python engineers or ask Java engineers to learn Python for AI projects, leaving Java developers uneasy.

In an interview Rod Johnson emphasized that while Python frameworks are competent, the JVM offers type‑safe business code accumulated over decades, mature IDEs, refactoring tools, and a large community of engineers who prefer Java.

Java’s ecosystem is the strongest: the largest developer community and the most mature industry solutions.

The author notes that Python frameworks, though impressive in demos, feel risky for production because they let large models decide each step, making auditability and reproducibility difficult.

Embabel’s idea: planning without the large model

Embabel’s core design borrows the GOAP (Goal‑Oriented Action Planning) algorithm from game AI, originally used to plan NPC behavior. Developers define only two concepts: Action (what the agent can do) and Goal (the desired outcome). The framework’s planner, not the LLM, determines the action sequence, recomputing after each step based on the latest state.

This deterministic planning means the same input always yields the same path, and the reason for each step is logged clearly, enabling precise audit trails. Because the planner does not call a model, it also saves token costs.

Strong typing is another advantage: actions exchange real domain objects (Java record or Kotlin data class) rather than generic dictionaries or strings. Compile‑time checks catch mismatches, and IDEs can locate all affected actions when a field changes, a contrast to the fragile refactoring experience in Python.

What it feels like to write

Rod Johnson likens Spring AI to the Servlet API (handling low‑level model interaction) and Embabel to Spring MVC (organizing business logic on top). A familiar Spring developer can read the code immediately:

@Agent(description = "Write and review a technical blog post")
public class BlogWriterAgent {

    @Action(description = "Research topic and draft the post")
    public BlogDraft writeDraft(Topic topic) {
        // call model to write draft
    }

    @Action(description = "Review draft and suggest edits")
    public Review reviewDraft(BlogDraft draft) {
        // call model to review
    }
}

The @Agent annotation is a regular Spring component; the class participates in component scanning, dependency injection, and packaging. The planner decides whether to draft first, review first, or run both, based on the current state. Embabel builds on Spring AI, reusing existing model connectors and vector stores without additional configuration.

What makes it "production‑grade"

The framework was released a month ago under Apache 2.0 and is available from Maven Central. Production readiness is demonstrated by three aspects:

Testing support: Agents can be unit‑tested like Spring beans; tests can mock model responses, assert that prompts contain required data, and verify temperature settings—something rarely seen in Python agent ecosystems.

Cost control: Each action can select a different model; heavy‑weight tasks use large models, lightweight classification uses smaller models, and sensitive steps can run on on‑premise models, reducing token usage and easing compliance.

Broad model compatibility: Besides OpenAI, Anthropic, and Google, Embabel supports DeepSeek, Zhipu GLM, MiniMax, and local Ollama deployments, lowering entry barriers for Chinese teams.

Additional engineering features include a stable RAG interface, bidirectional MCP (you can call external MCP tools or expose your own Agent as an MCP server), health endpoints via Spring Boot Actuator, A2A protocol for Agent‑to‑Agent communication, and optional ONNX support for local embeddings.

The documentation cites that roughly 70 % of production AI workloads run on the JVM, reinforcing the argument that integrating AI capabilities into existing Java systems is the pragmatic path.

Limitations and candid observations

The core code is written in Kotlin; the project ensures Java callers feel no friction, but it currently targets Spring Boot 3.5, with no official support for the upcoming Boot 4 yet (migration guide is on the wiki). The ecosystem is still young: GitHub stars are far below LangChain’s hundred‑thousand level, and community examples are limited. For teams outside the Spring stack that only need simple model wrappers, LangChain4j may be more convenient.

Final thoughts

The author refrains from declaring whether Embabel will replicate Spring’s historic impact. The agent space evolves rapidly, and framework longevity is uncertain. Rod Johnson believes Embabel could be the last framework chosen by humans before AI tools start making such decisions autonomously.

Embabel’s niche is to let large models handle uncertain tasks (writing, summarizing, classification) while deterministic code handles planning and workflow, allowing Java’s decades‑long strengths in type safety, testing, and auditability to shine again.

https://github.com/embabel/embabel-agent