Three of the eight APIs in google-maps-services-java are now end-of-sale

Half the API surface is legacy, and that is a scheduling fact not a quality judgement

The README's most important content is an IMPORTANT callout at the top, before the project description. Three APIs this library covers are in Legacy status.

Places API (Legacy), Directions API (Legacy) and Distance Matrix API (Legacy) can no longer be enabled for new Google Cloud projects as of October 2026. Existing projects remain fully supported. The migration paths given are Places API (New) for the Places legacy surface, and the Routes API for both Directions legacy and Distance Matrix legacy.

What makes this a decision rather than a footnote is the last line of that block: the new APIs will not be added to this client library. So the library is not going to grow into a full-featured replacement. It is a wrapper over a set of web services, including three legacy APIs that cannot be enabled for new projects, and the successors are covered by separate client libraries.

The successors are named explicitly as separate Java client libraries in the Cloud Client Libraries for Java: `java-maps-places` for Places API (New), `java-maps-routing` for the Routes API, `java-maps-addressvalidation` for the Address Validation API, and `java-maps-mapsplatformdatasets` for the Datasets API. The README's instruction is to use those if you want the newer APIs, with links to both the google-cloud-java overview and its release list.

Five APIs are not flagged: Elevation, Geocoding, Maps Static, Roads and Time Zone. Those are the ones to evaluate the library against.

SLF4J is a hard dependency now, and the warning is the symptom

Since version 0.1.18 the library depends on SLF4J, and you have to add an adapter yourself. The README is explicit about why: without an adapter you get a warning message when you start using `google-maps-services`. The samples use slf4j-nop, and the README names slf4j-log4j12 and slf4j-jdk14 as alternatives that make more sense in other configurations.

Maven coordinates are straightforward, and the version is left as an explicit placeholder:

<dependency>
  <groupId>com.google.maps</groupId>
  <artifactId>google-maps-services</artifactId>
  <version>(insert latest version)</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-simple</artifactId>
  <version>1.7.25</version>
</dependency>

The Gradle equivalent puts both on the `implementation` configuration:

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.maps:google-maps-services:(insert latest version)'
    implementation 'org.slf4j:slf4j-simple:1.7.25'
}

Two details are worth pausing on. The version placeholder is a placeholder, so the README is asking you to look up the current release rather than copying a pinned one, which means you will be tracking releases yourself. And the SLF4J sample version is 1.7.25, which is a long-lived 1.7.x line; if your application is on SLF4J 2.x you should not assume the sample version drops in.

The requirements section is minimal by comparison: Java 1.8 or later, a Cloud project with the relevant APIs enabled, and an API key associated with that project.

GeoApiContext.Builder is the single entry point

The usage example constructs a context and passes it to the per-API entry point. The context is built from a builder with the API key:

GeoApiContext context = new GeoApiContext.Builder()
    .apiKey("AIza...")
    .build();
GeocodingResponse response = GeocodingApi.geocode(context, address);

That shape, one context built once and passed to each call, is the design. It means the key lives in one object, which is what makes key rotation or per-environment keys tractable, and it means the API surface is static methods like `GeocodingApi.geocode(context, address)` rather than instance methods on a service object.

The context is also the right place to hang connection pooling and timeouts, which the README does not enumerate. For a library that makes outbound HTTP calls to a metered API on a server, that is a real omission in the documentation, and you should check the javadoc before assuming defaults suit a high-throughput service.

The javadoc is the primary reference. The README points to https://www.javadoc.io/doc/com.google.maps/google-maps-services for the API documentation, and separately to developers.google.com/maps for the web service documentation, listing per-service pages for Directions, Distance Matrix, Elevation, Geocoding, Maps Static, Places, Roads and Time Zone. That split is sensible: this library tells you the Java shape, Google's docs tell you the semantics and the quota.

Android users need 0.19.0 for key restrictions to work

The README states the library is designed for use in both server and Android applications, and then makes a security point that has a hard version attached to it. If you are using this library on Android, ensure your application is using at least version 0.19.0 so that API key restrictions can be enforced.

That is a specific and useful piece of advice. Android applications have historically shipped API keys in the binary, where they can be extracted, and Android key restrictions only have value if the client library actually enforces them. If you are on an older version of this library, key restrictions are configured in the Google Cloud console but not applied.

The general guidance is to add API key restrictions to improve the security of the key, and additionally to hide the key from version control. The README links to the Maps API security best practices page, and repeats the Italian-language variant of that URL in the Markdown, which is a small sign of a link that was edited once and never revisited.

The scope of the library is a server-side client that also happens to work on Android, not an Android library. If your application is mobile-first and place or route lookup is central, the Cloud Client Libraries for Java are the ones described as covering the newer APIs, and you should compare them on that basis rather than on this library's feature list.

Three years of tags, then commits

The release history and the commit history disagree in a way that matters for how you pin. The most recent tags are v2.2.0 from 2023-03-30, v2.1.2 from 2022-11-03 and v2.1.1 from 2022-10-18. The repository is not archived and the last push was on 2026-10-06.

So the public Maven artifact line ends in 2023 while the repository itself has seen a commit this month. That gap is consistent with a library whose upstream APIs are in maintenance while the code still receives fixes, and with the README's statement that new APIs will not be added. Fixes go in; features do not.

Practically, that means you should check the CHANGELOG.md at the repository root to see what changed after v2.2.0 and decide whether the fixes in `main` matter to you, because `main` is not where a new release will come from. The project uses semantic-release, indicated by the `.releaserc` file at the top level, so tags are generated from commit messages rather than cut by hand.

The repository is a Gradle project with `build.gradle`, `settings.gradle`, `gradlew` and `gradlew.bat` committed, so building from source is a wrapper invocation rather than a setup exercise. Coverage was tracked through Coveralls, which is what the coverage badge in the README reflects.

Licence, and the practical alternative

The licence is Apache-2.0, which is permissive and carries the standard patent grant. For a client library that talks to a hosted API, the licence is the least interesting thing about it: the constraints that actually shape your decisions are the API key, the quota and the API lifecycle.

The practical alternative for the newer APIs is not another Maps library, it is a different library family. The Cloud Client Libraries for Java are what Google points to for Places (New), the Routes API, Address Validation and Datasets, and they come from the `com.google.maps` organisation's sibling repository `googleapis/google-cloud-java`, with modules named `java-maps-places`, `java-maps-routing`, `java-maps-addressvalidation` and `java-maps-mapsplatformdatasets`. They are covered by a separate client-library family; the source does not compare their authentication mechanisms with this library's API-key builder.

For geocoding, elevation, roads, time zone and static maps specifically, this library remains the documented option and nothing in the README suggests those are being retired. That is the case where the wrapper earns its place: it turns an HTTP GET with query parameters and a JSON response into a typed call, which is real work even if it is not original work.

For everything else, the README is unambiguous that you are choosing between this library and a Cloud Client Library, not between this library and calling the endpoint with your existing HTTP client.

Editorial conclusion

Adopt google-maps-services-java for Elevation, Geocoding, Maps Static, Roads and Time Zone, which are not flagged legacy and are the parts most server-side Java applications actually use. Do not adopt it for a new build that needs place search, routing or distance matrices, since Places (Legacy), Directions (Legacy) and Distance Matrix (Legacy) cannot be enabled on new Cloud projects as of October 2026 and the README states the new APIs will not be added to this library. Before starting, decide which library you want for the newer surface: `java-maps-places` and `java-maps-routing` from google-cloud-java, and pin `com.google.maps:google-maps-services` alongside an SLF4J adapter such as `org.slf4j:slf4j-simple:1.7.25` to avoid the startup warning.

Frequently asked questions

Official sources

1. googlemaps/google-maps-services-java on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases