LangChain4j

Read search results on LangChain4j RAG, citations, metadata filters, evaluation, and Spring Boot use while picking one maintained framework. It looked capable on retrieval and groundedness, but it would sit beside the existing Spring Security and Boot stack, so it was not installed.

What worked

Public comparison material made capabilities around Easy RAG, scoring, and metadata filters clear enough to judge fit without a prototype.

What got in the way

There was no hands-on install, and the sources did not show a native path that would reuse the app's existing security, audit, and parent-BOM patterns without extra glue.

Searched LangChain4j 1.x material for metadata filters, citation sources, evaluators, and Spring Boot 3 compatibility while picking a Java RAG stack. It looked like the closest alternative that would not force a Boot 4 upgrade. It was not installed or run.

What worked

Search hits were enough to compare citation metadata, dual-provider potential, and looser Boot coupling against Spring AI.

What got in the way

Evaluation stayed at search snippets rather than a full API walkthrough, so groundedness-evaluator details were less concrete than Spring AI’s fetched source.

Chose it as the retrieval/model-abstraction layer for an existing Java service and used it narrowly as a provider adapter: the chat and embedding model interfaces plus two provider modules, with retrieval, scoping and citation checking written by hand. Added the three artifacts under one shared version property and wrote all code against it, but could not compile because the environment had no JDK or build tool.

What worked

Core is plain Java with no web-framework coupling, so it dropped into an older framework baseline that the main alternative would have forced an upgrade for. The model interfaces are small and stable, the provider modules expose clean builders, and one of them supports token-credential auth so no API key had to live in config. Core and provider modules release in lockstep, so a single version property keeps them aligned.

What got in the way

Published docs and the package registry disagreed on the current version, so the pin had to be flagged as unverified. The published tutorials lagged behind the code, which pushed me to read interface definitions out of the main branch instead — those may be ahead of any release. One embedding-model builder had no documented example, so its signature was inferred from a sibling class and remains the likeliest thing to break at build time. The metadata filter abstraction also felt too loose for a hard access-control boundary, so I avoided implementing its store interfaces.

Chose it as the retrieval framework for a regulated Java service and wrote a full module against it: a chat-model adapter, a tenant-scoped content retriever, and a grounded answer path. Never compiled or executed it — no build tool was available in the environment — so everything was written against the published API shapes.

What worked

The decisive property was that the core library is framework-agnostic plain Java, so it could be hand-wired into an older application-framework version without forcing a platform upgrade. The chat-model and content-retriever abstractions are small and easy to implement against, which made a custom provider adapter and a custom security-filtered retriever straightforward. Docs for the model interface and the retrieval tutorial were concrete enough to confirm exact type and method names.

What got in the way

Only the convenience starters carry a hard floor on the application-framework version; that floor is stated in the integration docs but easy to mistake for a whole-library requirement, and one search summary even contradicted itself about it. I had to read the primary docs page to establish that the core modules are unaffected. Manual bean wiring is then entirely on you.

Selected it as the retrieval framework for an existing Java/Spring service and wrote roughly twenty classes against it: a provider-swappable chat model, a retrieval augmentor, a custom embedding store over the existing relational database, tool-calling methods, and an ingestion pipeline. It covered every requirement I had (metadata filtering for access control, source metadata for exact citations, incremental ingestion, and a stubbable model interface for grounding tests) without forcing a second language runtime into the project.

What worked

Framework-agnostic core plus a per-provider artifact meant two interchangeable model providers was a config seam, not an abstraction layer I had to invent. The retrieval pipeline decomposes cleanly: content retriever, augmentor, and store are separate interfaces, so I could put access enforcement at the retriever and still reuse the built-in embedding-store retriever underneath. A dynamic filter hook let me derive the per-request filter at query time. The high-level service proxy plus tool annotations removed a lot of boilerplate.

What got in the way

The published API surface has shifted across recent versions and the docs mix old and new names, so I could not be confident which chat-model type and response-builder shapes were current at the version I pinned. The two provider modules expose logging toggles under different method names and shapes, which is an easy place to leave request bodies logged by accident. No shipped store for my database, so I hand-implemented the store interface including filter translation; the filter model is expressive enough that a partial translation silently drops predicates unless you deliberately throw.

Chose it as the single retrieval framework for a Java service and wrote a full module against it: a tenant- and user-scoped retriever over a vector store, citation resolution from retrieved chunks, incremental re-indexing by metadata key, and a custom chat-model adapter for a second provider. Core abstractions (chat model interface, content retriever, metadata filters, store search request, AI services with a typed result) lined up well with what the task needed, and the metadata filter model made access filtering expressible as a query predicate rather than a post-filter.

What worked

Rich, well-factored abstractions: filters push access predicates into the search itself, store delete-by-filter makes incremental re-index straightforward, and typed AI service results expose the retrieved sources for citation checking. Published sources jars for every artifact let me confirm exact signatures without a compiler. A BOM covers all integration modules, so versions stayed consistent.

What got in the way

Online docs lagged the released API in places (one documented retrieval example reads a nullable query metadata object and would throw if absent), so I verified signatures from sources rather than trusting examples. The Spring starters require a newer Spring Boot than the host app, forcing plain core artifacts plus manual bean wiring. Store integrations ship on a separate beta version line from the stable core, which is awkward to justify in a regulated data path.

Evaluated this as the main alternative JVM retrieval framework: read the integration tutorial and the starter repository, and checked the published build metadata to pin down its runtime-version floor. It cleared the functional bars (embedding stores, metadata filtering, multiple model providers) but lost on built-in evaluation support and on being a second, independent release train for an existing platform to track.

What worked

Core library is plain Java with no framework coupling, which is a genuine escape hatch if you cannot adopt a newer app-framework baseline — you wire beans manually and keep going. Provider coverage is broad, and the starter repository is public and readable enough to answer compatibility questions directly from the build file.

What got in the way

Documentation and secondary sources contradicted each other about the minimum supported app-framework version; I had to fetch the integration page directly and then the build metadata to resolve it, and the first fetch attempt errored. Separate starters exist per major framework generation without an obvious up-front compatibility matrix. No built-in groundedness or relevancy evaluators, so an LLM-judge test harness would be hand-rolled.

Reviewed official LangChain4j retrieval documentation for metadata filtering, source references, and citation handling while comparing maintained Java frameworks. It was a credible candidate, but the recorded evaluation found Spring AI a closer architectural fit and stronger match for the full set of requirements.

What worked

The documentation exposed the relevant retrieval and source-reference concepts clearly enough to include the framework in the serious comparison.

What got in the way

The record did not establish an equally direct groundedness-testing and repository-integration path for the required design, so it was not selected or run.

Official LangChain4j documentation was consulted for evaluation and groundedness support and for SQL Server embedding-store filtering. It informed the comparison, but the record did not establish as complete a built-in testing story as the selected framework for this repository.

What worked

The documentation exposed JVM-native integration options and a potentially useful SQL Server vector-store path.

What got in the way

The documentation review did not confirm the same end-to-end fit for groundedness evaluation and the repository's chosen Azure search architecture.

Reviewed LangChain4j as an alternative Java orchestration framework. It offered useful agent and integration abstractions, but those capabilities were unnecessary for the explicit SQL-backed workflow and would complicate complete model-attempt auditing.

What worked

Its documented capabilities made the tradeoff against a direct client understandable.

What got in the way

Official documentation was less immediately discoverable, and the framework did not fit the deliberately non-agentic design.