google-cloud-java: Java client libraries for Google Cloud Platform services

One library per service, all under com.google.cloud on Maven Central

google-cloud-java is Google's collection of Java client libraries for Google Cloud Platform services. Each GCP service has its own library, distributed as a separate artifact under the com.google.cloud Maven group on Maven Central. Individual artifact IDs follow the pattern google-cloud-{service}: google-cloud-bigquery for BigQuery, google-cloud-notebooks for AI Platform Notebooks, google-cloud-api-gateway for API Gateway and so on. The group identifier com.google.cloud appears in every Maven badge in the README's API table, and each row links to a Maven Central search result confirming the group and artifact.

All service clients visible in the table carry a stable GA designation. The repository is a monorepo with a java-{service} directory for each client at the top level. A scan of the top-level directory listing shows over 80 entries starting with java-, covering services from AlloyDB and Artifact Registry through BigQuery and App Engine Admin.

Official reference documentation is at cloud.google.com/java/docs/reference. For setup and first-use instructions, the README explicitly points to the guide at cloud.google.com/java/docs/setup rather than including them inline.

Two published artifact types: individual libraries and the GCP Libraries BOM

The monorepo produces two distinct types of publishable output. Individual service libraries are what application code imports and calls; each has its own artifact ID and its own version. The GCP Libraries BOM is a separate artifact housed in the gapic-libraries-bom/ directory at the repository root. Its job is to pin a compatible set of versions for all the included libraries, so a project adding multiple GCP clients can manage all their versions through a single BOM declaration rather than tracking each one independently.

The BOM version and the aggregate repository version follow different numbering schemes. A per-library automation manifest at the repository root coordinates the publishing cadence, but a first-time user may not realize that the two numbers are unrelated. That manifest currently tracks over 180 sub-library entries, one per service client directory. A developer who adds the BOM version number to an individual library dependency instead of using it for dependency management will get unexpected results.

The last push to the repository was on 2026-10-06 and the library is Apache-2.0 licensed. The most recent automated publishing run produced 2 entries: the aggregate repository artifact and the BOM artifact, published on 2026-09-30 under separate version counters.

For the full dependency declaration in pom.xml, the setup guide at cloud.google.com/java/docs/setup covers both Maven and Gradle configurations.

GAPIC code generation and the shape of the Java client API

A generation/ directory sits at the top level alongside a generate-readme.py script. The directory name gapic-libraries-bom/ includes GAPIC, which stands for Google API Client, and refers to Google's approach of generating client libraries from protocol buffer definitions of service APIs.

Code generation from protobuf definitions shapes the Java API surface in concrete ways. Client methods correspond directly to the RPC methods in the underlying service definition, including their parameter structures and return types. An engineer who has read the protobuf definition for a GCP service will find the Java API shape predictable. For those coming from hand-designed Java libraries, the method signatures can feel mechanical, since they mirror the wire protocol rather than presenting a higher-level abstraction.

The generate-readme.py script at the repository root signals that the README's API table is programmatically maintained. Adding a new service client means adding a new directory and regenerating the index rather than editing the table by hand. For users, the implication is that the table stays current as services are added to the monorepo without manual intervention.

Finding the right artifact coordinate before writing any code

Before writing Java code that calls a GCP service, a developer needs the Maven artifact coordinate. Each row in the README's API table links to a Maven Central search result for the group and artifact. BigQuery uses com.google.cloud:google-cloud-bigquery; Artifact Registry uses com.google.cloud:google-cloud-artifact-registry; Cloud Storage uses com.google.cloud:google-cloud-storage. The group identifier is com.google.cloud for all of them.

The README does not include a full dependency declaration in pom.xml or build.gradle format. For the complete declaration, the setup guide at cloud.google.com/java/docs/setup covers both Maven and Gradle configurations, including how to import the BOM.

For a team adopting several GCP services, importing the BOM once and then declaring dependencies without version tags for each service library is the standard approach. For a team using exactly one GCP service, the BOM is still useful for forward compatibility: updating the BOM version updates all managed libraries together rather than requiring individual updates that might leave some combinations untested.

Bazel as the internal build system, Maven artifacts for consumers

Two build systems coexist in the repository. Maven parent POMs (google-cloud-jar-parent/, google-cloud-pom-parent/) define the artifact structure for what is published to Maven Central. Bazel configuration files (.bazeliskrc, .bazelrc, BUILD.bazel, WORKSPACE) drive internal builds. The .bazeliskrc file pins the Bazel version, and WORKSPACE defines workspace-level dependencies.

For a Java developer consuming these libraries from Maven Central, the Bazel build infrastructure is invisible. It matters for contributors working on the library from source and for teams that use Bazel internally and want direct source integration. Google's internal tooling historically runs on Bazel, and public Google libraries commonly carry both Maven poms and Bazel files for this reason.

CI automation uses the .kokoro/ directory, which points to Kokoro, Google's internal CI/CD system. A .tool-versions file at the root handles additional toolchain versioning beyond Bazel. An AGENTS.md file sits alongside CONTRIBUTING.md and DEVELOPMENT.md, indicating the project provides explicit instructions for AI coding assistants contributing to the repository.

Authentication via google-auth-library-java and Application Default Credentials

A google-auth-library-java/ directory lives inside the monorepo. Authentication for GCP API calls runs through this library, which provides credential types including service accounts, user credentials and Application Default Credentials (ADC).

ADC is the standard approach for server-side applications running on GCP: the runtime environment (Compute Engine, Cloud Run, GKE) supplies credentials automatically, and the application code calls the API without managing tokens directly. The library supports 3 credential types at the application level: service accounts, authorized user credentials and Application Default Credentials from the local metadata server. The google-cloud-java clients pick up these credentials by default when running in those environments.

A developer who hand-rolls HTTP calls to GCP REST endpoints takes on authentication token management, retry behavior and request serialization that the client library handles. The trade-off is explicit control over the network layer versus the overhead of a library dependency. For most Java teams calling multiple GCP services, the client library removes enough boilerplate to make the dependency worthwhile. A team calling a single service endpoint infrequently may prefer a minimal HTTP client with manual token management.

google-cloud-examples, contributor documentation and repository tooling

A google-cloud-examples/ directory lives at the top level alongside the individual service client directories. That directory is the place to look for runnable Java code before reading the full API reference, since examples show how authentication, client construction and API calls fit together in practice.

Contributor infrastructure is thorough. CODE_OF_CONDUCT.md, CONTRIBUTING.md, DEVELOPMENT.md and SECURITY.md are all present at the repository root. SECURITY.md documents the project's vulnerability reporting process.

Commit history for the monorepo is tracked at the repository level rather than per service client. Given the scale of the repository (dozens of service client directories), a single aggregate record covers changes across all of them rather than maintaining dozens of separate per-service logs.

For teams evaluating adoption risk, the relevant signal is that the project is under the googleapis organization on GitHub, all service clients carry a stable GA classification, and the googleapis organization is Google's primary open-source home for API client libraries.

When google-cloud-java is the wrong choice

google-cloud-java covers Google Cloud Platform services only. A Java application that needs to call AWS or Azure services alongside GCP must use separate SDKs for those clouds. Teams building cloud-agnostic abstraction layers that wrap multiple providers cannot use this library as that abstraction.

The library does not give full control over the HTTP layer. Each client makes decisions about retry policies, timeout defaults and connection pooling; a team that needs to override all of these at the network level will find raw HTTP calls easier to audit and modify. For debugging network behavior, an HTTP interceptor on a raw client reveals more than what the client library exposes.

Language coverage is another boundary. Google maintains separate client libraries for Python, Go, Node.js and other languages in distinct repositories from this one. This repository is Java-only.

For a team already embedded in a non-Maven build system that does not support Bazel or Maven artifacts well, the library's distribution model may not fit without wrapper tooling.

Editorial conclusion

Use google-cloud-java when your Java application needs to call GCP services and you want a typed API that handles authentication, retries and transport details. Skip it if your team prefers raw REST calls with full control over the HTTP layer, or if you are not on GCP. Before adding any library, check the current Libraries BOM version at cloud.google.com/java/docs/setup, and add the BOM to your pom.xml dependency management section rather than pinning individual artifact versions, since the BOM version and the repository's aggregate version number are two different things.

Frequently asked questions

Official sources

1. googleapis/google-cloud-java on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases