LangChain4j is an Apache-2.0, open-source, idiomatic Java library for building LLM-powered applications on the JVM, aimed at Java developers and enterprise teams who want one unified API over many LLM providers and embedding stores without leaving the Java ecosystem.

What it is

LangChain4j is a Java library, started in early 2023, that simplifies integrating LLMs into Java applications. LLM providers such as OpenAI and Google Vertex AI, and embedding (vector) stores such as Pinecone and Milvus, each expose a proprietary API. LangChain4j offers a unified API across 20+ popular LLM providers and 30+ embedding stores, so swapping an LLM or an embedding store does not require rewriting application code. Despite the name, it is not a Java port of LangChain (Python); it is built for Java from the ground up around Java conventions — type safety, POJOs, annotations, interfaces, dependency injection and fluent APIs — with an API, internals and release cycle independent of the Python project.

The concrete problem it solves is per-provider integration work. Without it, a Java team must learn and implement each provider's and each embedding store's own API, then absorb the cost of rewriting when the provider or store changes. LangChain4j replaces that work with one API surface plus a toolbox that captures patterns the community identified since 2023: low-level prompt templating, chat memory management and function calling, up to high-level Agents and RAG. For each abstraction it ships an interface with multiple ready-to-use implementations, so a chatbot or a full RAG pipeline from data ingestion to retrieval can be assembled from existing pieces.

Key capabilities

• Unified API over 20+ LLM providers, allowing a switch between models without rewriting code.
• Integrations for 30+ embedding (vector) stores.
• Tool calling, including MCP support.
• High-level patterns: Agents and RAG, including a complete data-ingestion-to-retrieval pipeline.
• Low-level building blocks: prompt templating, chat memory management and function calling.
• First-class integration with enterprise Java frameworks: Quarkus, Spring Boot, Helidon and Micronaut.
• A companion langchain4j-examples repository with runnable examples for LLM-powered applications.

Who uses it and how

• Java teams adding chat or RAG features to services already running on Quarkus or Spring Boot, using the framework integrations and dependency injection rather than a separate runtime.
• Teams that must change LLM providers, for example moving between OpenAI, Google Vertex AI and other supported providers, without rewriting their integration code.
• Teams building chatbots that rely on chat memory management and function calling.
• Teams building RAG applications that need one pipeline from data ingestion through retrieval across a chosen embedding store.
• Teams that need tool calling with MCP support inside an existing JVM service.

Getting started

The library is published on Maven Central as dev.langchain4j:langchain4j, and the getting started guide lives at docs.langchain4j.dev/get-started. Full documentation is at docs.langchain4j.dev, with an experimental documentation chatbot at chat.langchain4j.dev.

How it compares

The facts name LangChain (Python) and the Python and JavaScript LLM libraries as the prior art LangChain4j was created to answer, so it sits in that space as the JVM-native option rather than a port of any of them. Its API, internals and release cycle are independent of the Python LangChain project, and its design targets Java conventions and Java framework integration instead of mirroring another language's idioms.

When to use it — and when not to

Choose LangChain4j when the application is Java or JVM-based and needs one API across many providers and embedding stores. Do not choose it for non-JVM stacks, and do not expect Python LangChain parity in API or semantics, since the project states the two are independent. Note that the README excerpt points offsite for getting started, active development means some features are still being worked on, and the repository carries 878 open issues — a real signal that issues can outpace resolution.