Spring AI vs. LangChain4j: Setup, erster Endpunkt und Designstil

Feature-Listen sagen nur begrenzt etwas aus. Was man über ein Framework eigentlich wissen will, ist, wie es sich nach ein paar Wochen Entwicklung anfühlt, und darauf gibt die Dokumentation keine Antwort. Stellen wir uns also ein Team vor, das ein neues Spring-Boot-Projekt startet und sowohl Spring AI als auch LangChain4j ausprobiert. Der Vergleich unten geht Architektur, Projekt-Setup, Konfiguration, einen ersten KI-Endpunkt und den Entwickleralltag durch. Beide Bibliotheken lösen dasselbe Problem, gehen aber sehr unterschiedlich vor.

Zwei Architekturphilosophien

Der Designunterschied prägt fast jede spätere Entscheidung, deshalb lohnt sich ein Blick darauf, bevor man Code schreibt.

Die Architektur von Spring AI

Spring AI folgt einem Muster, das jeder Spring-Boot-Entwickler wiedererkennt.

                 Spring Boot Application
                            │
                     ChatClient API
                            │
                   Spring AI Abstractions
                            │
        OpenAI | Gemini | Ollama | Claude | Azure
                            │
                     Large Language Model

Das Framework sitzt zwischen Ihrer Anwendung und dem KI-Anbieter. Statt OpenAI oder Gemini direkt aufzurufen, spricht Ihr Code mit den Abstraktionen von Spring AI. Das zahlt sich mehrfach aus. Ein Wechsel von Gemini zu OpenAI lässt den Geschäftscode meist unberührt, nur die Konfiguration ändert sich. Es ist dieselbe Idee wie bei Spring Data, wo Sie die Datenbank austauschen können, ohne die Repository-Logik neu zu schreiben.

Warum sich dieser Ansatz vertraut anfühlt

Wer seit Jahren Spring-Boot-Anwendungen baut, erkennt die Struktur sofort. Dependency Injection steht im Mittelpunkt, Beans werden automatisch konfiguriert, und Einstellungen liegen in application.yml. Es fühlt sich weniger an, als würde man ein KI-Framework lernen, sondern eher wie ein weiterer Spring-Starter, und für Enterprise-Teams ist das ein großer Vorteil.

Die Architektur von LangChain4j

LangChain4j denkt anders. Es baut nicht alles um eine zentrale Abstraktion herum, sondern gibt Ihnen mehrere wiederverwendbare Bausteine an die Hand.

Spring Boot Application
                           │
                    AI Service Interface
                           │
        ┌──────────┬─────────────┬──────────────┐
        │          │             │              │
    Chat Model   Memory       Tools       Retriever
        │
   OpenAI / Gemini / Ollama

Außerdem versteckt es KI-Konzepte nicht, sondern legt sie offen. Sie arbeiten direkt mit diesen Komponenten:

• Chat-Modelle und Embedding-Modelle
• Chat-Speicher (Chat Memory)
• AI Services
• Content Retriever und Tool Provider

Jede davon hat genau eine klare Aufgabe, und Sie setzen sie zu Ihrer eigenen KI-Pipeline zusammen. Anfangs kann das nach Mehrarbeit aussehen. Sobald die Anwendung wächst, ergibt das modulare Design aber Sinn.

Spring AI einrichten

Der Einstieg in Spring AI geht schnell. Es funktioniert genauso wie bei Spring Data JPA oder Spring Security: Sie fügen den passenden Starter hinzu.

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-gemini</artifactId>
</dependency>

Dann hinterlegen Sie Ihren API-Schlüssel in der Konfiguration.

spring:
  ai:
    vertex:
      ai:
        gemini:
          project-id: your-project
          location: us-central1

# OR
spring:
  ai:
    openai:
      api-key: ${OPENAI_API_KEY}

Spring Boot erzeugt anschließend die nötigen Beans für Sie. Keine Factory-Klassen, keine manuelle Verdrahtung, keine Builder-Objekte – alles ist bereit für Dependency Injection. Für Spring-Entwickler fühlt sich das völlig natürlich an.

LangChain4j einrichten

LangChain4j liefert ebenfalls Spring-Boot-Starter mit, und das Setup unterscheidet sich nur geringfügig.

<dependency>
    <groupId>dev.langchain4j</groupId>
    <artifactId>langchain4j-open-ai-spring-boot-starter</artifactId>
</dependency>

Die Konfiguration sieht fast genauso aus.

langchain4j:
  open-ai:
    chat-model:
      api-key: ${OPENAI_API_KEY}
      model-name: gpt-4o-mini

Auch hier legt Spring Boot die Beans automatisch an, sodass sich die Arbeit in einem bestehenden Spring-Boot-Projekt kaum von Spring AI unterscheidet. LangChain4j bietet aber eine zusätzliche Option: Sie können die Starter ganz weglassen und alles von Hand aufbauen.

ChatLanguageModel model = OpenAiChatModel.builder()
        .apiKey(apiKey)
        .modelName("gpt-4o-mini")
        .build();

Diese Flexibilität ist ein echtes Plus. In einer reinen Java-Anwendung oder in Quarkus ändert sich nichts, weil die Bibliothek nicht an Spring gebunden ist.

Ein erster KI-Endpunkt

Jetzt wird es interessant. Mit jedem Framework entsteht derselbe REST-Endpunkt. Er nimmt eine Frage entgegen und gibt eine generierte Antwort zurück.

Die Spring-AI-Version

@RestController
@RequestMapping("/chat")
public class ChatController {

    private final ChatClient chatClient;

    public ChatController(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @GetMapping
    public String chat(@RequestParam String message) {
        return chatClient.prompt()
                .user(message)
                .call()
                .content();
    }
}

Das ist überraschend aufgeräumt. Die Fluent API erinnert an Springs WebClient, und jeder Schritt liest sich natürlich.

prompt()
  ↓
user()
  ↓
call()
  ↓
content()

Wer Springs Fluent APIs kennt, versteht das Prinzip vermutlich auf einen Blick.

Die LangChain4j-Version

@RestController
@RequestMapping("/chat")
public class ChatController {

    private final ChatLanguageModel model;

    public ChatController(ChatLanguageModel model) {
        this.model = model;
    }

    @GetMapping
    public String chat(@RequestParam String message) {
        return model.generate(message);
    }
}

Diese hier ist sogar noch kürzer. Statt einen Prompt über einen Builder zusammenzubauen, sprechen Sie direkt mit dem Sprachmodell. Weniger Zeremonie, und der Code sieht fast aus wie der Aufruf eines gewöhnlichen Java-Service.

Was ist einfacher?

Das fragen Entwickler oft, und die ehrliche Antwort lautet: Beide sind hervorragend. Für eine einfache Chat-Anwendung gibt es keinen klaren Sieger. Beide brauchen nur wenige Zeilen, fügen sich in Spring Boot ein, konfigurieren ihre Abhängigkeiten selbst und liefern sauberen, lesbaren Code.

Der Unterschied liegt nicht in der Codemenge, sondern darin, wie sich eine Anwendung weiterentwickelt. Spring AI möchte, dass alles über einen ChatClient läuft, und wenn ein Projekt wächst, kommen rund um diesen Client Advisors, Speicher, Tool Calling, RAG und Observability hinzu.

LangChain4j geht den umgekehrten Weg. Statt einen zentralen Client auszubauen, setzt es auf spezialisierte AI Services, sodass eine Anwendung am Ende etwa so aussieht:

CustomerSupportAgent
DocumentAssistant
CodeReviewAgent
EmailGenerator
MeetingSummarizer

Jeder davon ist ein eigenes Java-Interface mit klar umrissener Aufgabe. Für größere KI-Anwendungen ist dieser Ansatz sehr elegant. Folgt Ihr Projekt aber bereits klassischen Spring-Service-Mustern, wirkt Spring AI vertrauter. Objektiv besser ist keines, denn beide sind auf unterschiedliche Denkweisen ausgelegt.

Was man lernt, wenn man denselben Chatbot zweimal baut

Ein erster Chatbot mit Spring AI fühlt sich an wie eine weitere Spring-Boot-Anwendung. Überraschungen gibt es kaum: Alles liegt dort, wo man es erwartet, Dependency Injection funktioniert wie gewohnt, die Konfiguration bleibt in application.yml, und ein funktionierender KI-Endpunkt steht innerhalb einer Stunde.

Derselbe Chatbot mit LangChain4j hinterlässt einen anderen ersten Eindruck. Statt eine API zu integrieren, denken Sie plötzlich darüber nach, einen intelligenten Assistenten zu entwerfen. Das ist ein feiner Unterschied, aber er verändert, wie Sie Code organisieren. LangChain4j legt Ihnen vom ersten Tag an nahe, Prompts, Tools, Speicher und Retrieval in wiederverwendbare Komponenten zu trennen, während Spring AI Sie diese Fähigkeiten nach und nach ergänzen lässt, wie sich die Anwendung entwickelt. Keine der beiden Philosophien ist falsch. Die richtige Wahl hängt davon ab, welche Art Software Sie bauen und wie Ihr Team eine Codebasis gern strukturiert.

Wo sie sich wirklich trennen

Bis hierhin sind die Unterschiede noch klein. Die eigentliche Trennung zeigt sich, sobald Sie produktionsreife KI-Funktionen bauen, etwa strukturierte Ausgaben, Tool Calling, Retrieval-Augmented Generation und Agenten. Dort zeigt jedes Framework seine wahren Stärken, und dort wird die Wahl zwischen ihnen deutlich wichtiger.