# LangChain4j: a Java LLM library that is not a LangChain port

> LangChain4j gives JVM teams one API over 20+ model providers and 30+ embedding stores, plus agents and RAG. It is built for Java rather than ported to it, and the release cadence is the thing to plan around.

**langchain4j/langchain4j** — LangChain4j is an idiomatic, open-source Java library for building LLM-powered applications on the JVM. It offers a unified API over popular LLM providers and vector stores, and makes implementing tool calling (including MCP support), agents and RAG easy. It integrates seamlessly with enterprise Java frameworks like Quarkus and Spring Boot.

- Repository: https://github.com/langchain4j/langchain4j
- Website: https://docs.langchain4j.dev
- Stars: 13,156 · Forks: 2,571
- Language: Java
- License: Apache-2.0
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/langchain4j-langchain4j

## The problem LangChain4j solves for JVM teams

Java services that call an LLM usually start with one provider SDK and end up with that SDK's types spread across the codebase. Switching to a different model, or adding a second one for cost or latency reasons, becomes a refactor. LangChain4j exists to remove that coupling: the README states the goal is to simplify integrating LLMs into Java applications through a unified API, so that providers and embedding stores can be swapped without rewriting code. The audience is specific. It is a team that already ships Java, uses dependency injection, and wants LLM calls to look like any other injected dependency rather than a side channel. The README is explicit that despite the name, this is not a Java port of LangChain (Python): the API, internals and release cycle are independent, and the design leans on Java conventions such as type safety, POJOs, annotations, interfaces and fluent APIs. That distinction matters more than the branding. If you have read the Python LangChain documentation expecting the same class names and concepts to transfer, you will be relearning rather than translating.

## Unified API, toolbox and the module layout

The mechanism is an abstraction layer plus per-vendor modules. The repository root shows the shape of it: a langchain4j-core module, a langchain4j-bom for version alignment, and one module per integration, from langchain4j-open-ai and langchain4j-anthropic to langchain4j-google-ai-gemini and langchain4j-hugging-face on the model side, and langchain4j-chroma, langchain4j-elasticsearch, langchain4j-cassandra and langchain4j-azure-ai-search on the store side. Higher-level concerns live in their own modules too: langchain4j-easy-rag, langchain4j-guardrails, langchain4j-agentic and langchain4j-agentic-mcp. The README describes the toolbox as spanning low-level prompt templating, chat memory management and function calling up to higher-level patterns like agents and RAG, with an interface plus ready-made implementations for each abstraction. The practical consequence: you program against the interface and the vendor module supplies the implementation, so the vendor choice becomes a dependency and a configuration decision rather than an architectural one. The cost is module sprawl. A RAG application pulls in a model module, an embedding module, a store module, and possibly a document loader or parser module, and the BOM exists precisely because keeping those versions aligned by hand is unpleasant.

## Installing LangChain4j and a first chat call

The README points to the getting started guide at docs.langchain4j.dev/get-started rather than listing coordinates inline, and the Maven Central badge confirms artifacts are published under the dev.langchain4j group. The repository also ships a langchain4j-bom module for aligning versions across the per-integration artifacts. A typical Maven setup therefore imports the BOM and then declares only the modules you use; the exact coordinates for each integration should be taken from the documentation for that integration, since the repository layout shows one artifact per provider or store rather than a single bundle. The repository's own build is driven by a Makefile: make build runs mvn -U -T12C clean package, make lint runs the Spotless check profile, and make format applies Spotless formatting. That is the contributor path, not the consumer path, but it tells you the project enforces a formatting standard through Spotless, so patches that skip make format will fail the lint target. For a first application, the README directs you to langchain4j-examples, which contains plain Java examples plus Spring Boot, Quarkus, Helidon and Micronaut variants. The Spring Boot example lives under spring-boot-example/src/main/java/dev/langchain4j/example in that repository, and the Quarkus samples are in the separate quarkus-langchain4j project. Read the plain Java example first: it shows the smallest possible wiring, and the framework examples add auto-configuration on top of the same interfaces.

## Where LangChain4j is the wrong tool

The release history is the clearest warning. Version 1.20.0 was published on 2026-09-04, then 1.19.1 and 1.19.2 both on 2026-09-07, with the repository noting that 1.19.1 was published in error and should not be used. A library that produces a bad release and a corrective release within the same day, three days after a minor version bump, is moving fast enough that pinning matters. If your organisation requires long deprecation windows, or you cannot absorb an upgrade every few weeks, this is friction you will feel. The README also states plainly that the library is under active development and that some features are still being worked on, while the core functionality is in place. Treat that as the project's own description of its maturity, not as a marketing hedge. A second limitation is scope. LangChain4j is a library for embedding LLM calls in a Java application. It is not a hosted service, not a workflow engine with a UI, and not a way to avoid understanding the model provider you pick. Prompt behaviour, token limits, rate limits and pricing remain the provider's, and the unified API does not make them uniform. Finally, the documentation chatbot linked from the README is labelled experimental; do not treat it as the reference.

## Spring AI and LangGraph4j as the real alternatives

The comparison people search for is LangChain4j versus Spring AI, and the difference is one of centre of gravity rather than features. LangChain4j is framework-neutral: the README lists first-class integrations with Quarkus, Spring Boot, Helidon and Micronaut, and the Spring Boot support is one example among several, living in the examples repository. Spring AI starts from the Spring ecosystem and assumes it. If your application is already Spring Boot and you want configuration to arrive through Spring's own mechanisms, Spring AI is the more natural fit; if you use Quarkus, Helidon or Micronaut, or you want the same code to run under more than one of them, LangChain4j's neutrality is the reason to pick it. The second comparison, LangChain4j versus LangGraph4j, is not really a choice between rivals. LangGraph4j is a graph-based orchestration approach for agent workflows; LangChain4j's own agentic support is split across langchain4j-agentic, langchain4j-agentic-patterns, langchain4j-agentic-mcp and langchain4j-agentic-a2a. If your problem is a fixed pipeline with a few branching steps, the agentic modules in LangChain4j are enough. If your problem is a stateful graph of many nodes with cycles, the graph-first framing is a different starting point, and you would be choosing between two mental models rather than two libraries.

## Maintenance, release cadence and the Apache-2.0 terms

The last push to the default branch was on 2026-09-09, and the most recent release in the list is 1.19.2 from 2026-09-07. The repository is not archived. The build runs through Maven, with a nightly JDK 17 workflow referenced in the README badges alongside the main CI workflow, and the Makefile exposes build, lint and format targets. The upgrade cost is the part to budget for: three releases in the first week of September 2026, one of them explicitly withdrawn, means you should pin an exact version and read the release notes before moving, rather than tracking latest. Because the project is organised as many small modules, an upgrade touches the BOM version and then whichever integration modules you declared; the BOM is what keeps that from turning into a version-resolution exercise. On licensing, the repository carries Apache-2.0 and a separate LOGO_LICENSE.md, which indicates the logo is licensed differently from the code. Apache-2.0 is permissive and includes a patent grant, but the trademark and logo terms sit outside it, so if you plan to use the name or mark in your own product, read LOGO_LICENSE.md rather than assuming the code licence covers it. This is a description of what the repository contains, not legal advice; your counsel should review redistribution plans.

## Conclusion

Adopt LangChain4j if your application is already a JVM service and you want provider swapping, tool calling and RAG behind interfaces you can inject. Do not adopt it if you need a stable API surface across upgrades, because the 1.19.x and 1.20.0 releases landed within days of each other and the project itself warns that 1.19.1 was published in error. Before writing production code, verify two things: which artifact coordinates you actually need rather than the aggregate dev.langchain4j:langchain4j, and which release notes apply to the version you pin.

## FAQ

### What is LangChain4j used for?

It is used to build LLM-powered applications on the JVM: chat, prompt templating, chat memory, function calling, agents and RAG. The README describes a unified API over model providers and embedding stores so you can switch between them without rewriting code.

### What is the difference between LangChain and LangChain4j?

LangChain4j is not a Java port of the Python LangChain project. The README states it was designed from the ground up around Java conventions such as type safety, POJOs, annotations and dependency injection, and that its API, internals and release cycle are independent.

### What is the difference between Spring AI and LangChain4j?

LangChain4j is framework-neutral and lists integrations with Quarkus, Spring Boot, Helidon and Micronaut, with Spring Boot as one example among several. Spring AI is built around the Spring ecosystem, so the choice usually follows which framework your application already uses.

### Is LangChain4j open source and free?

Yes. The repository is licensed under Apache-2.0 and the artifacts are published on Maven Central under the dev.langchain4j group. Note that the repository also carries a separate LOGO_LICENSE.md, so the logo terms are not the same as the code licence.

### How do I use LangChain4j in Java?

The README points to the getting started guide at docs.langchain4j.dev/get-started, and directs readers to the langchain4j-examples repository for plain Java examples. Higher-level patterns such as agents and RAG are provided as modules alongside the core interfaces.

## Sources

- [langchain4j/langchain4j on GitHub](https://github.com/langchain4j/langchain4j)
- [License: Apache-2.0](https://github.com/langchain4j/langchain4j/blob/main/LICENSE)
- [Project website](https://docs.langchain4j.dev)
- [README](https://github.com/langchain4j/langchain4j/blob/main/README.md)
- [Releases](https://github.com/langchain4j/langchain4j/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/langchain4j-langchain4j