google/adk-java: A Code-First Agent Toolkit for Java Teams on Google Cloud
An open-source, code-first Java toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
At a glance
- What is it?
- ADK for Java puts agent definitions, tool wiring and multi-agent orchestration in plain Java classes with a Maven artifact. It is a good fit if your stack is already JVM and Gemini, and a poor fit if you need a stable evaluation API today.
- Who is it for?
- Adopt google/adk-java if you are a JVM team already committed to Gemini and Google Cloud, and you want agent orchestration to live in version-controlled Java rather than in a prompt file or a hosted console. Do not adopt it if you need a documented evaluation pipeline now, because the README lists agent evaluation as coming soon, or if you need a provider-neutral abstraction across several model vendors.
- 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 received new commits within the last day.
- 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
What ADK for Java is actually for
The problem this project addresses is orchestration drift. When an agent is assembled inside a hosted console or a chain of prompt templates, the definition of which model runs, which tools it may call and how sub-agents hand work to each other lives outside your repository. It cannot be code-reviewed, diffed or unit tested in the way the rest of a service is. ADK for Java moves that definition into Java source. The README states the toolkit is for developers who want fine-grained control and flexibility when building advanced AI agents tightly integrated with Google Cloud services, and that agent behavior, orchestration and tool use are defined directly in code, which the project frames as enabling debugging, versioning and deployment from a laptop to the cloud. The intended reader is a backend Java engineer, not a prompt author. The repository topics list agentic-workflow, multi-agent-system and llm, and the README's own feature list names three things: a tool ecosystem spanning pre-built tools, custom functions and OpenAPI specs, code-first development, and modular multi-agent systems composed into hierarchies. Those three claims are the whole scope. There is no visual builder, no hosted runtime and no managed memory service described in the material.
The LlmAgent builder and what the code-first claim buys you
The mechanism is a builder that produces an agent object. The README gives this example: LlmAgent.builder() with .name("search_assistant"), .description(...), .model("gemini-2.0-flash"), .instruction(...) and .tools(new GoogleSearchTool()), finished with .build(). Two details matter more than the shape of the call. First, the model is a string, and the README comments it as "Or your preferred models", so the binding is not hardcoded to one Gemini version in the API surface. Second, tools are objects passed into the builder, and the README says those tools can be pre-built ones such as GoogleSearchTool, custom functions, or OpenAPI specs. An OpenAPI spec is the interesting case: it means an existing HTTP service can be exposed to the agent without hand-writing a Java wrapper for every endpoint. Because the agent is a plain Java object, the surrounding lifecycle is ordinary JVM work. You can construct it in a test, assert on its configuration, and inject it where your application already does dependency wiring. The README also claims the interface is familiar to users of the Python ADK, and points to a separate repository, google/adk-python, as the sibling implementation. That parity claim is worth treating as a direction of travel rather than a guarantee, since the two are separate repositories with separate release cadences.
Getting it into a build: Maven coordinates and the dev UI artifact
Installation is a Maven dependency. The README shows groupId com.google.adk, artifactId google-adk, version 1.9.0, and a second dependency on com.google.adk:google-adk-dev at the same version, labelled in the README as the Dev UI. The release table in the repository metadata shows v1.9.0 dated 2026-08-31, with v1.8.0 and v1.7.1 before it at roughly two-week intervals, and the README's version block is wrapped in release-please markers, which indicates the version numbers in the documentation are generated from the release tooling rather than edited by hand. That is a small but useful signal: the documented version is less likely to drift from the published artifact. For an unreleased build, the README points at JitPack and cites an external example repository for the setup. Note the split between the two artifacts. google-adk is the runtime library you ship; google-adk-dev carries the development UI, which the README describes as a built-in UI for testing, evaluating, debugging and showcasing agents, with a screenshot borrowed from the Python project's assets. Keep the dev artifact out of production dependency scopes. Beyond Maven, the README says nothing about Gradle coordinates, a BOM, or a minimum JDK version, so confirm the Java baseline from the docs site before you pin anything.
Multi-agent composition and the A2A boundary
The README's third feature is modular multi-agent systems, described as composing specialized agents into flexible hierarchies. The material does not name the orchestration classes or show a parent-child example, so the concrete API for hierarchy is something you have to read out of the documentation site or the samples repository rather than the README. What the README does cover is the boundary between separate processes. It states that for remote agent-to-agent communication ADK integrates with the A2A protocol, links to the A2A repository, and directs readers to a2a/README.md inside this project for end-to-end setup instructions and sample commands. That file, not the top-level README, is where the transport configuration lives. The design implication is a two-tier story: in-process composition for agents that share a JVM, and A2A for agents that do not. Teams that only ever need the first tier can ignore the a2a directory entirely. Teams that plan to call agents owned by another team or another runtime should read that README before designing their service boundaries, because the protocol choice constrains how much of your orchestration stays in Java.
The evaluation gap is the sharpest limitation
The README's feature highlight section ends with a heading for evaluating agents and a single line: "Coming soon...". The dev UI is described as a place to test and evaluate agents, but the programmatic evaluation surface is not documented in this repository's README. For a toolkit that also advertises deployment, that is a real gap, and it is the item most likely to change your adoption decision. If your workflow requires a repeatable eval suite wired into CI, you are currently building that yourself on top of whatever the dev UI exposes, or waiting. Two other constraints are worth stating plainly. The README's own framing ties the toolkit to tight integration with the Google ecosystem, and the sample model is a Gemini identifier, so this is not a provider-neutral abstraction layer; the model string is configurable, but the surrounding tooling assumes Google services. Second, the README carries a Preview notice stating the feature is subject to the Pre-GA Offerings Terms, that Pre-GA features are available as is and might have limited support. That is a support-level statement, not a licence statement, and it applies on top of the Apache-2.0 code licence.
How this differs from LangChain4j and Spring AI
The nearest JVM alternatives are LangChain4j and Spring AI, and the difference is where the abstraction sits. Those projects lead with a provider-neutral chat and embedding interface: you pick a model provider through a module, and the same interface spans several vendors. ADK for Java inverts that. It is code-first and Google-first, with the agent as the primary object and the model as a parameter of that agent, and the tool surface built around Google services plus OpenAPI specs. If your requirement is to swap between model vendors behind one interface, the provider-neutral libraries are the better starting point and ADK is the wrong tool. If your requirement is to express a hierarchy of agents with tool access and deploy it against Google Cloud, the reverse holds. There is also a language-level distinction worth naming: the README positions this as the Java counterpart to google/adk-python, so a polyglot organisation can keep the same conceptual model in both languages, though the two are separate codebases and the README's parity claim is about interface familiarity rather than a shared runtime.
Maintenance cost, licensing and what to check before you pin
The licence is Apache-2.0, stated in the README badge and the licence section, which permits commercial use and modification subject to the usual notice and attribution conditions. This article is not legal advice; read LICENSE and, if you are shipping a product, have counsel confirm the Pre-GA terms alongside it, because the Preview notice sits on top of the open source licence and is a separate contractual layer. On maintenance, the observable pattern is a release roughly every two weeks across v1.7.1, v1.8.0 and v1.9.0, with the last push to main dated 2026-09-09. A cadence that fast cuts both ways: fixes arrive quickly, and minor-version bumps can carry API movement in a pre-1.10 library. Pin an exact version rather than a range, and read the release notes between the version you have and the version you want. The repository is not archived, so there is no abandonment signal in the metadata. What the material does not tell you is the minimum JDK, the Gradle setup, or the orchestration class names, so treat the docs site and the google/adk-samples repository as required reading rather than optional.
Editorial conclusion
Adopt google/adk-java if you are a JVM team already committed to Gemini and Google Cloud, and you want agent orchestration to live in version-controlled Java rather than in a prompt file or a hosted console. Do not adopt it if you need a documented evaluation pipeline now, because the README lists agent evaluation as coming soon, or if you need a provider-neutral abstraction across several model vendors. Before committing, verify three things against the current release notes rather than this article: that the google-adk artifact version you pin matches a released tag, that the A2A setup in a2a/README.md covers your transport, and that the Pre-GA terms are acceptable for a production dependency.
Community notes