Guava is a broad extension to the Java standard library
Guava packages a familiar set of missing pieces for Java code: immutable collections, multimaps, multisets, graphs, hashing, string helpers, I/O utilities, primitive helpers, caches, and concurrency types. Its best APIs remove homemade utility code and give teams shared semantics. ImmutableList communicates ownership better than an unmodifiable view over a mutable list, while Multimap avoids a repeated map-of-lists pattern. The library stays close enough to ordinary Java that adoption rarely requires a new programming model.
Version 33.7.1 comes as 33.7.1-jre and 33.7.1-android. The JRE artifact supports Java 8 or newer, while Android consumers should use the separate flavor. The release notes identify one runtime linkage dependency, failureaccess 1.0.3, plus annotation-only dependencies documented by the project. Gradle users must choose whether Guava is an implementation detail or part of the library's public API by selecting implementation or api correctly.
Stable APIs exclude anything marked Beta
Guava makes an unusually strong promise for APIs without @Beta: indefinite binary compatibility, including deprecated members, subject to an emergency such as a serious security problem. The inverse is equally important. A beta class or method may change or disappear at any time. Application code can often accept that risk behind its own boundary. A published library that exposes a beta Guava type passes the risk to every consumer and can force synchronized upgrades.
The README recommends Guava Beta Checker for library authors. That is sensible because a source review can miss a beta annotation several calls deep. Serialization has a different limit: Guava says all serialized object forms may change unless a type explicitly promises otherwise. Persist business data in an owned schema rather than Java serialization of ImmutableMap or another implementation class. These warnings are not boilerplate; they define which compatibility guarantees buyers actually receive.
What happened when we ran it
Our JDK 21 sandbox completed the Maven install stage in 48 seconds. The checkout occupied 35.4 MB and contained 3,304 files with about 795,856 source lines. The build continued for 93 seconds before failing in the guava-gwt portion. Maven could not find test-source jars for guava-testlib and guava-tests at the internal-looking 999.0.0-HEAD-jre-SNAPSHOT version.
The test command ran for 627 seconds and exited 1. Maven Surefire aggregated 4,319,941 cases: 4,318,381 passed, 3 failed, and 1,557 were skipped. The tail shows the Guava unit-test module ending in failure and one sub-summary with 865,575 tests plus 1 failure. It does not include all failing class names or messages. We therefore report the three failures without guessing whether they were timing, environment, or code defects.
Those numbers reveal a source tree built around huge generated and parameterized suites. A consumer adding one artifact from Maven Central does not need to reproduce 4.3 million cases. A contributor does need the correct snapshot reactor and artifact order. The failed build suggests the generic build command in our harness did not create or locate every test-source artifact required by the GWT module. The log says what was missing, but not which project-specific command would prepare it.
The JRE and Android split is part of the API decision
Android is not a classifier to ignore. Guava maintains distinct source and artifacts for Android compatibility, while the mainline flavor is tested across OpenJDK versions on Linux and Windows. The README also warns that some I/O features may behave differently outside Linux. Teams building shared libraries should decide their lowest platform first, because publishing signatures from the JRE artifact can make an otherwise portable library unusable to Android consumers.
Release 33.7.1 arrived on August 18, 2026, and fixed a manifest regression introduced in 33.7.0 for Java 9 and 10. The repository was pushed on August 25. Recent issues and pull requests concern JDiff generation, Gradle variant selection, concurrent collection tests, and circular class initialization under GraalVM or Android tooling. The combined GitHub count was 747 issues and pull requests, which reflects the scale and age of the project rather than 747 current defects.
One open Gradle report shows Guava variant resolution failing in a non-Java project after the java-library plugin was removed. Another asks for safer initialization order around ImmutableList in GraalVM builds. These are specialized edges, but they matter because Guava is often a transitive dependency. When a build fails before application code runs, inspect the chosen flavor, Gradle attributes, and native-image metadata before blaming whichever direct dependency brought Guava in.
Use Guava deliberately, not as a default import
Guava earns its place when an API makes code clearer or removes an error-prone local implementation. It is less compelling for a lone string helper already available in the JDK, especially in a public library where every exposed type becomes a downstream commitment. Keep beta APIs private, avoid persisting Guava serialization, select the platform flavor explicitly, and let dependency management resolve failureaccess. With those rules, the mature non-beta surface is still one of the safer third-party foundations in Java.