Spring AI by Example: What ThomasVitale/llm-apps-java-spring-ai Actually Contains
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?
- A catalogue of small, runnable Spring Boot samples covering chat, RAG, embeddings, tool calling and guardrails, aimed at Java teams who want to see Spring AI wired up before committing to it. The value is the breadth of the example set, not any single application.
- Who is it for?
- Adopt this repository as a reference when your team already writes Spring Boot and needs to see how Spring AI's abstractions map onto real endpoints, particularly the RAG, memory and guardrail samples that are harder to assemble from the reference docs alone.
- 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 9 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap these samples fill for Java teams
Most LLM tutorials arrive as Python notebooks. A Java team that wants to add a chat endpoint or a retrieval step to an existing Spring Boot service has to translate the concepts and guess at the idioms. This repository exists to remove that translation step. It is a set of Spring Boot applications, each demonstrating one capability against one model provider, so the wiring is visible in Java rather than described in prose. The intended reader is a developer who already knows Spring Boot and wants to know what Spring AI adds: how a chat client is declared, how a vector store is configured, how a prompt template is bound to a method argument. It is not a framework and not a library. There is nothing to depend on. The repository is a collection of directories you read and run. That distinction matters when you evaluate it, because the questions you would ask of a library (release cadence, API stability, upgrade path) do not apply in the same way here. The questions that do apply are whether the samples cover your use case and whether the Spring AI version they pin is close enough to the one you intend to use.
How the repository is organised: three axes, not one app
The layout splits along three axes, and understanding that split is most of the work of using it. The first axis is use cases: chatbot, question answering with documents, semantic search, structured data extraction and text classification. These are end-to-end applications, each with its own directory under use-cases. The second axis is models: chat models, embedding models, image models and audio models, each with per-provider subdirectories for Mistral AI, Ollama, OpenAI, ONNX Transformers and, for chat, a multiple-providers variant. The third axis is patterns: prompts, structured output, multimodality, tool calling, memory and guardrails, again split by provider where the provider supports the pattern. Data ingestion forms a fourth group, covering document readers for JSON, Markdown, PDF, text and Tika, plus document transformers. The consequence is a matrix rather than a monolith. If you want tool calling against OpenAI, there is a directory for that. If you want tool calling against Ollama, there is a separate one. The samples do not share a parent application, so each directory stands alone. That makes them easy to read in isolation and tedious to keep consistent as a set, which is a trade-off the repository accepts.
Running a sample: Java 25, Podman or Docker, and a per-directory build
The README lists two pre-requisites: Java 25 and Podman or Docker. The container runtime is not optional decoration. The Ollama-based samples need an Ollama instance, and the question answering and semantic search use cases need PGVector, both of which the samples expect you to run as containers. The README does not spell out the exact compose invocation in the material available here, so treat the per-directory README as the source of truth for the command rather than assuming a repository-level one exists. What is clear from the structure is the working pattern: you enter a sample directory such as use-cases/question-answering or patterns/tool-calling/tool-calling-openai and build it there. The provider choice is not a runtime flag you flip in one application. It is a directory choice, and the configuration keys differ accordingly, since an OpenAI sample needs an API key while an Ollama sample points at a local endpoint. Java 25 is a demanding floor. If your organisation standardises on Java 21, the samples will not compile as written, and you will be reading them for structure rather than running them. That is a real constraint, not a footnote.
Provider parity is claimed by the layout, not guaranteed by it
The directory tree implies that a pattern available for one provider is available for all. The README contradicts that in places. Moderation models are marked coming soon, with no provider listed at all. Document readers are listed for Ollama only, with no OpenAI or Mistral AI equivalents in the tree, even though the patterns section offers prompt and structured-output samples for multiple providers. Multimodality appears for Mistral AI, Ollama and OpenAI; image generation and the audio samples appear for OpenAI alone. So the symmetry is partial. If your provider of choice is, say, Mistral AI and your use case is document ingestion, the repository does not appear to have a sample for you, and you will be adapting the Ollama one. This is the single most important thing to check before planning work around the repository: match your provider and use case against the actual directory list, not against the impression the headings give. The gaps are not defects in the samples themselves, but they do mean the collection is a starting point for adaptation rather than a lookup table.
Where the repository stops being the right tool
There are no releases. The recent releases field is empty, which means there are no tagged versions to pin against and no changelog to read when something moves. Combined with a last push date in September 2026, the repository is a living sample set rather than a maintained product. Nothing in the material states a support policy, a compatibility matrix against Spring Boot versions, or a deprecation process. For a team that needs to know what a dependency will look like in eighteen months, that absence is the answer: you will not get one from here. The second limitation is architectural. These are samples, so they optimise for showing one thing clearly. The memory samples illustrate the point: basic chat memory, JDBC chat memory, Spring Security chat memory and vector store chat memory are four separate demonstrations of four storage strategies. A production service needs one of them plus a decision about eviction, cost and privacy, and the samples do not make that decision for you. Third, the guardrail samples cover input and output guardrails but the README does not describe what the guardrails enforce, so you cannot judge from the index alone whether they match your policy requirements. You will have to open the directory.
Spring AI itself is the alternative, and the difference is documentation versus demonstration
The obvious alternative is the Spring AI reference documentation, which the README links directly. The difference in approach is straightforward. The reference documentation describes each abstraction, its configuration properties and its extension points in a general form, organised by feature. This repository shows one concrete instantiation of each abstraction, organised by use case and provider, with a runnable application attached. If you are trying to decide whether Spring AI's chat client fits your service, the documentation tells you what the interface offers; a sample tells you what a working call site looks like, including the build file, the application properties and the controller. The reverse also holds. The documentation covers the full configuration surface and the edge cases; the samples cover the subset the author chose to demonstrate, and the gaps noted above are exactly where the documentation has to take over. Use them together rather than choosing between them. A team that reads only the samples will miss configuration options; a team that reads only the documentation will spend longer assembling the first working endpoint.
Licence, maintenance and what you are actually taking on
The repository is Apache-2.0. That is a permissive licence, and it means you can copy sample code into your own project without the copyleft obligations that a GPL-style licence would impose. It does not mean the samples are warranted or supported, and Apache-2.0 includes a patent grant and a liability disclaimer that you should read rather than assume. This is not legal advice; if your organisation has a policy on incorporating third-party sample code, run it past whoever owns that policy. On maintenance cost, the honest assessment from the available material is that you are adopting a snapshot, not a dependency. There is no version to upgrade, because there are no releases. What you will maintain is your own adaptation of whichever sample you copied, plus the Spring AI version you pin yourself. That is arguably cheaper than tracking an upstream library, since nothing will break underneath you, but it also means nothing will be fixed underneath you either. If Spring AI changes an API, the samples will not tell you. Your build file will.
Editorial conclusion
Adopt this repository as a reference when your team already writes Spring Boot and needs to see how Spring AI's abstractions map onto real endpoints, particularly the RAG, memory and guardrail samples that are harder to assemble from the reference docs alone. Do not adopt it as a starting codebase for a production service: there are no releases, no versioned artifacts and no stated support window, and the samples pull in Java 25 plus a container runtime for Ollama and PGVector. Before you build on it, check which Spring AI version each sample's build file pins, confirm that your target model provider has a sample matching your use case rather than assuming parity across providers, and run the specific sample directory you care about rather than the repository as a whole.
Community notes