LangChain4j: eine Java-Bibliothek für LLM-Anwendungen, kein Python-Port

Das Problem: proprietäre APIs pro Anbieter

Wer in einer Java-Anwendung mehrere LLM-Anbieter oder Vektorspeicher ansprechen will, schreibt sonst für jeden davon eigenen Client-Code. Das README nennt genau diesen Punkt als Ausgangslage: Anbieter wie OpenAI oder Google Vertex AI und Embedding-Stores wie Pinecone oder Milvus hätten jeweils eigene APIs, und LangChain4j biete eine einheitliche API, damit man nicht jede davon lernen und implementieren muss. Der Wechsel zwischen Modellen oder Stores soll ohne Umschreiben des Codes möglich sein. Das ist ein konkretes Versprechen und kein Marketing-Satz, denn es adressiert eine reale Wartungslast: Jede Anbieteränderung an Auth-Headern, Request-Bodies oder Fehlercodes landet sonst im eigenen Code. Zielgruppe sind Java-Teams, die eine Chat- oder RAG-Funktion in eine bestehende Anwendung einbauen und dabei in der JVM bleiben wollen. Das README macht außerdem eine Abgrenzung explizit: Trotz des Namens sei LangChain4j kein Java-Port von LangChain aus Python, sondern von Grund auf um Java-Konventionen herum gebaut, mit eigener API, eigenem Release-Zyklus und Unabhängigkeit vom Python-Projekt.

Zwei Achsen der Abstraktion: Modelle und Speicher

Die Bibliothek vereinheitlicht nach eigener Darstellung zwei getrennte Bereiche. Auf der einen Seite stehen die Sprachmodelle, auf der anderen die Embedding-Stores. Das README nennt 20+ unterstützte LLM-Anbieter und 30+ Embedding-Stores, jeweils verlinkt auf Integrationsseiten in der Dokumentation. Diese Trennung ist architektonisch sinnvoll, weil beide Achsen unterschiedlich schnell wechseln: Ein Modellname ändert sich häufig, das Schema eines Vektorspeichers selten. Praktisch heißt das, dass ein Anwendungsfall wie RAG aus zwei unabhängig austauschbaren Teilen besteht, dem Einbetten und Speichern von Dokumenten und dem Abrufen und Einfügen in den Prompt. Wer nur einen Anbieter nutzt, zahlt für diese Flexibilität mit einer zusätzlichen Schicht zwischen Code und HTTP-Aufruf. Wer später wechseln muss, spart sich genau diese Schicht. Die Entscheidung hängt also davon ab, wie wahrscheinlich ein Wechsel ist. Bei einem einzelnen, vertraglich fixierten Anbieter ist der Nutzen der Abstraktion geringer als bei einem Prototyp, in dem mehrere Modelle verglichen werden.

Was der Werkzeugkasten konkret enthält

Das README beschreibt den Umfang als Werkzeugkasten, der seit Anfang 2023 aus communitygebauten Anwendungen destilliert wurde. Genannt werden niedrigschwellige Bausteine wie Prompt-Templating, Chat-Memory-Verwaltung und Function Calling sowie höherstufige Muster wie Agenten und RAG. Für jede Abstraktion gebe es ein Interface plus mehrere fertige Implementierungen. Das ist die eigentliche Designentscheidung: Schnittstellen statt einer einzigen festen Pipeline. Man kann eine Chat-Memory-Implementierung austauschen, ohne den übrigen Code anzufassen. Die Kehrseite ist die Auswahl. Wer zum ersten Mal eine RAG-Pipeline baut, steht vor mehreren Implementierungen pro Abstraktion und muss selbst entscheiden, welche zur eigenen Last passt. Das README löst das nicht auf, es verweist auf ein separates Repository mit Beispielen, darunter Beispiele in reinem Java, mit Quarkus, Spring Boot, Helidon und Micronaut. Diese Beispiele sind der praktische Einstieg, nicht die README selbst.

Einbindung in bestehende Java-Stacks

Die Integration in Enterprise-Frameworks ist ein ausdrücklich genanntes Ziel. Das README verweist auf Quarkus über die Abhängigkeit quarkus-langchain4j, auf Spring Boot über ein Beispielprojekt, auf Helidon über io.helidon.integrations.langchain4j und auf Micronaut über micronaut-langchain4j. Wichtig ist die Richtung dieser Abhängigkeiten: Die Framework-Integrationen liegen außerhalb des Haupt-Repositories, teils in anderen Organisationen. Wer Quarkus nutzt, bindet also nicht nur dev.langchain4j ein, sondern zusätzlich ein Quarkus-Projekt mit eigenem Release-Takt. Das erhöht die Zahl der beweglichen Teile und damit die Wahrscheinlichkeit, dass eine Aktualisierung an einer Stelle eine Anpassung an einer anderen nach sich zieht. Für Spring Boot ist im README nur ein Beispielprojekt verlinkt, kein eigenes Integrationsartefakt. Wer dort auf automatische Konfiguration hofft, sollte die Beispiele im Repository prüfen, statt von einer fertigen Starter-Autokonfiguration auszugehen.

Versionslinie und Release-Kadenz

Die veröffentlichten Releases zeigen ein dichtes Tempo. Innerhalb weniger Tage im September 2026 erscheinen 1.20.0, 1.19.1 und 1.19.2, jeweils zusammen mit einer Beta-Version. Bemerkenswert ist der Hinweis zu 1.19.1: Diese Version sei irrtümlich veröffentlicht worden und solle nicht verwendet werden. Das ist ein ehrlicher Umgang mit einem Fehler, aber es ist auch ein Signal. Wer automatisch die neueste Version zieht, kann eine zurückgezogene Version erwischen. Eine feste Versionsnummer im Build ist hier keine Pedanterie, sondern eine konkrete Absicherung. Ebenso auffällig ist das Nebeneinander von stabilen und Beta-Artefakten im selben Release-Zug. Die Dokumentation oder die Release Notes sind die Stelle, an der man klären muss, welche Artefakte als stabil gelten und welche nicht. Aus dem README allein lässt sich das nicht ableiten. Wer die Bibliothek in einer Anwendung mit langer Lebensdauer einsetzt, sollte die Upgrade-Kosten deshalb einplanen: nicht als einmalige Migration, sondern als wiederkehrende Aufgabe.

Lizenz und was sie nicht regelt

LangChain4j steht unter Apache-2.0. Das ist eine permissive Lizenz, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt und eine Weitergabe von Änderungen nicht erzwingt. Zwei Punkte bleiben davon unberührt. Erstens betrifft die Lizenz den Code, nicht die Modelle und nicht die Vektorspeicher, die über die Bibliothek angesprochen werden. Die Nutzungsbedingungen eines LLM-Anbieters oder eines gehosteten Vektorspeichers sind davon vollständig getrennt und können restriktiver sein. Zweitens gilt die Lizenz des Haupt-Repositories nicht automatisch für die externen Integrationsprojekte wie quarkus-langchain4j, micronaut-langchain4j oder die Helidon-Integration. Wer diese einbindet, muss deren Lizenzen separat prüfen. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass Apache-2.0 hier eine von mehreren Lizenzen im Abhängigkeitsbaum ist.

Wann die Bibliothek das falsche Werkzeug ist

Der Nutzen der einheitlichen API verschwindet, wenn man sie nicht braucht. Eine Anwendung mit genau einem Anbieter, festen Modellnamen und einem einzigen Vektorspeicher kann direkt gegen dessen HTTP-API arbeiten und spart sich eine Abhängigkeit samt Transitivabhängigkeiten und Upgrade-Zyklen. Auch die Modellwahl selbst löst die Bibliothek nicht: Welches Modell für eine Aufgabe taugt, entscheidet sich an Qualität, Kosten und Latenz, nicht an der Abstraktionsschicht darüber. Ein weiterer Grenzfall sind Umgebungen, in denen keine externen Modell- oder Speicherdienste erreichbar sind. Das README nennt zwar Ollama und ONNX in den Themen, beschreibt aber keine vollständig lokale Betriebsart im Detail. Wer ausschließlich lokal arbeiten muss, sollte die entsprechenden Integrationsseiten prüfen, bevor er die Bibliothek als Lösung einplant. Und wer eine über Jahre eingefrorene API braucht, wird mit der oben sichtbaren Release-Kadenz nicht glücklich.

Alternative: direkt gegen den Anbieter oder ein Framework

Die naheliegende Alternative ist der offizielle Client des jeweiligen Anbieters, also etwa das OpenAI-SDK oder das SDK des Cloud-Anbieters, direkt im Java-Code. Der Unterschied liegt nicht in der Funktionalität, sondern in der Verantwortung für den Wechsel: Beim direkten SDK ist ein Anbieterwechsel eine Änderung an jeder Aufrufstelle, bei LangChain4j eine Änderung an der Konfiguration der Implementierung. Umgekehrt bleibt beim direkten SDK die Kontrolle über Retries, Timeouts und Fehlerbehandlung vollständig im eigenen Code, während bei LangChain4j diese Entscheidungen durch die Abstraktion mitbestimmt werden. Eine zweite Alternative ist der Verzicht auf eine LLM-Bibliothek zugunsten eines reinen HTTP-Clients plus eigener Prompt-Verwaltung. Das ist mehr Code, aber es gibt keine fremde Versionslinie im Build. Die Wahl ist damit eine Frage der Anzahl der Anbieter, die man tatsächlich anspricht: bei einem einzigen ist die Bibliothek Ballast, bei mehreren spart sie Arbeit.

Redaktionelles Fazit

Wer eine Java-Anwendung um LLM-Aufrufe, Tool Calling oder eine RAG-Pipeline erweitern will und dafür keine eigene Abstraktionsschicht schreiben möchte, findet hier eine passende Grundlage. Wer eine stabile API über Jahre braucht oder keine externen Modellanbieter einbinden darf, sollte zuerst die Release-Historie und die Abhängigkeiten der gewählten Integration prüfen, bevor er sich auf die Bibliothek festlegt.

Offizielle Quellen

1. langchain4j/langchain4j on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases