llm-apps-java-spring-ai: a sample catalogue for Spring AI, not a framework
Samples showing how to build Java applications powered by Generative AI and LLMs using Spring AI and Spring Boot.
At a glance
- What is it?
- Thomas Vitale's repository is a set of Gradle modules that show Spring AI patterns one at a time, from chat and RAG to guardrails and tool calling. It is a teaching resource for Java developers already on Spring Boot, and it expects Java 25 plus Podman or Docker before anything runs.
- Who is it for?
- Adopt this repository if you are a Java developer on Spring Boot who wants a working reference for one Spring AI pattern at a time, and you can supply Java 25 plus Podman or Docker. Do not adopt it if you need a supported library with versioned releases, because there are none, or if you are not on the Spring stack, because every module assumes it.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What llm-apps-java-spring-ai actually is
This is a catalogue, not a library. The top-level README describes it as "Samples showing how to build Java applications powered by Generative AI and Large Language Models (LLMs) using Spring AI". There is no artifact to add to a dependency block and no release to pin. What you get is a Gradle multi-project build whose settings.gradle pulls in a set of directories, each one a self-contained Spring Boot application demonstrating a single capability.
The intended reader is a Java developer who already writes Spring Boot services and now has to wire an LLM into one. The repository answers the question "what does the Spring AI code look like for this pattern" rather than "how do I operate an LLM in production". That distinction matters when you decide whether to clone it. If you want to understand how Spring AI represents a chat client, a prompt template, a vector store or a tool call, the modules are small enough to read in one sitting. If you want a starting skeleton for a service you will run for years, you will be copying code, not depending on it.
The scope is broad in subject and shallow in depth per subject. Use cases, models, patterns, data ingestion, RAG, MCP and observability each get their own top-level directory, and the README enumerates the submodules underneath them. Breadth here is the point: you can compare the same pattern across Ollama, OpenAI and Mistral AI without leaving the repository.
How the modules are organised and how a request flows
The layout is the architecture. Top-level directories group by concern: use-cases/, models/, patterns/, data-ingestion/, rag/, mcp/ and observability/. Inside models/, the split is by modality first and provider second, so models/chat/chat-ollama, models/chat/chat-openai, models/chat/chat-mistral-ai and models/chat/chat-multiple-providers sit side by side. Embedding models follow the same shape, with an extra variant for ONNX Transformers that runs without a remote provider.
That provider-per-directory convention is the most useful design decision in the repository. Because each variant is a separate application, you can diff two directories and see exactly what changes when you move from a local Ollama model to a hosted OpenAI one. In Spring AI terms that difference lives in configuration and auto-configuration rather than in your service code, and the repository makes that visible instead of asserting it.
The data flow in the retrieval modules follows the standard shape the README implies through its directory names. Documents are read by a document reader (JSON, Markdown, PDF, text or Tika), passed through document transformers, embedded, and written to a vector store. The question-answering and semantic-search use cases then query that store. PGVector is named as the store for both. The patterns/ directory covers what happens around that flow: prompts and templates, structured output, multimodality, tool calling, memory and guardrails. Memory is itself split four ways (basic, JDBC, Spring Security, vector store), which is a good signal that the author treats conversation state as a design choice rather than a default.
Getting started with a Spring AI example module
The README states two pre-requisites and nothing else: Java 25 and Podman or Docker. There is no published install command because there is nothing to install. You clone the repository and run one of its Gradle modules.
The repository ships a Gradle wrapper, so you do not need a local Gradle. The .sdkmanrc file at the top level is the author's own toolchain pin, and devbox.json and devbox.lock describe a reproducible shell. The README does not give a runnable command for any module, so the only commands the repository itself documents are the pre-requisites. What it does give is the path of each module, for example models/chat/chat-ollama for the Ollama chat sample, which is the variant to try first because it needs no API key.
For the retrieval use cases, the README names PGVector as the vector store, which means a database container is part of the setup rather than an optional extra. The README does not document the individual container commands. Check the module's own directory for its own instructions.
If you would rather not run a local model, the OpenAI and Mistral AI variants under models/chat are the alternative. Those require provider credentials, and the README does not describe how they are supplied. The repository's own convention is Spring Boot configuration, so expect a property or environment variable in the module, and read that module before assuming a name.
Where this repository stops being the right tool
There are no releases. The releases list is empty, which means there is no version to pin, no changelog to read before upgrading, and no compatibility statement tying a given commit to a given Spring AI version. You are tracking a branch. For a sample you read once, that is fine. For anything you intend to depend on, it is not.
The maintenance signal is mixed and worth stating plainly. The repository is not archived, and the last push was on 2026-09-06. But recency of a push is not a support commitment, and with no releases the only upgrade path is to re-read the diff. If Spring AI changes an API, the samples change with it and your copy does not.
Java 25 is a second boundary. Many production Java services are still on 17 or 21, and the README lists 25 as a pre-requisite without qualification. If your platform team controls the JDK, this repository is a reading exercise for you rather than something you can run in place.
The third boundary is scope. The README lists moderation models as "Coming soon". If content moderation is the pattern you came for, it is not here yet. Similarly, the README does not document rollback, deployment topology or failure handling for any module, because the modules are demonstrations. Do not read a working local run as evidence that the pattern is production-ready.
Spring AI PetClinic is not in here, and what to compare against
People searching for a Spring AI PetClinic will not find one in this repository. The use cases are chatbot, question answering, semantic search, structured data extraction and text classification. There is no reference application that ties all of them into one domain model.
That points at the real alternative, which is not another sample collection but the official Spring AI reference documentation that the README links to. The difference in approach is concrete. The documentation explains the API surface and its contracts; this repository shows one working configuration per feature and per provider. Documentation tells you what a ChatClient does. The chat modules here show what a Spring Boot application that uses one looks like, including the build file and the configuration that the documentation only describes in the abstract.
A second alternative is a single-purpose sample that mirrors your actual deployment. If you need to see how a vector store behaves under a real document corpus, a smaller repository focused on that one pipeline will teach you more than a catalogue that covers twelve patterns at demo scale. The catalogue wins when you are choosing between patterns. It loses when you have already chosen and need depth.
Editorial conclusion
Adopt this repository if you are a Java developer on Spring Boot who wants a working reference for one Spring AI pattern at a time, and you can supply Java 25 plus Podman or Docker. Do not adopt it if you need a supported library with versioned releases, because there are none, or if you are not on the Spring stack, because every module assumes it. Before you copy a module, check the module's own build file for the Spring AI version it was written against, confirm the model provider you intend to use has a matching directory under models/chat or models/embedding, and read the module's own README, since the top-level README only links to it.
Frequently asked questions
What is llm-apps-java-spring-ai?
It is a repository of samples showing how to build Java applications powered by generative AI and LLMs using Spring AI and Spring Boot. It groups the samples into use cases, models, patterns, data ingestion, RAG, MCP and observability directories.
What is Spring AI in Java, and how does this repository use it?
Spring AI is the framework the samples are built on, and the README links to its reference documentation. Each module in the repository is a separate Spring Boot application demonstrating one Spring AI capability, such as chat, embeddings, structured output or tool calling.
What are the pre-requisites for running the samples?
The README lists Java 25 and Podman or Docker. There is no install step because the repository is a Gradle multi-project build you clone and run, and it ships a Gradle wrapper.
Does llm-apps-java-spring-ai support multiple model providers?
Yes. The models directory has chat and embedding samples for Mistral AI, Ollama and OpenAI, plus an ONNX Transformers embedding sample, and there is a dedicated chat-multiple-providers sample. Each provider gets its own directory, so you can compare configurations directly.
What is an LLM app in the context of this repository?
Based on the use cases listed, it is a Spring Boot application that calls a large language model to do something specific: chat, answer questions over documents, search semantically, extract structured data or classify text.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/thomasvitale-llm-apps-java-spring-ai)