google/guava

Guava is worth adopting for the problem it still solves well: writing everyday Java without hand-rolling immutable collections, collection helpers or concurrency plumbing. For greenfield code, though, check what the JDK and newer libraries already cover before adding it.

The problem

A Java developer needs a reliable immutable list, a multimap that maps one key to several values, a graph structure, or a bounded cache, and does not want to write and test those building blocks. Without a library, that work is repeated in every codebase, with subtle bugs around copying, null handling and concurrent access. Guava replaces that custom scaffolding with tested types that plug into ordinary Maven or Gradle builds, so a team can spend its time on application logic instead. The result is fewer homegrown utilities, but it also means one more dependency to declare and keep current.

What's different

Guava's distinguishing trait is its compatibility promise. Non-@Beta APIs are stated to remain binary-compatible indefinitely, and the README notes that the last release to remove such APIs was Guava 21.0. That matters for shared libraries: a downstream consumer can upgrade Guava without a forced rewrite. The @Beta annotation marks the opposite bargain, since those APIs can change or disappear, and the project recommends a beta checker for libraries whose APIs are consumed elsewhere.

The library is large and covers many areas at once, from collections to I/O, hashing, primitives and strings. Two flavors exist: one for JDK 1.8+ and an Android flavor with source in the repository. Guava also carries a runtime dependency on failureaccess, plus annotation-only dependencies, so dependency analysis tools and shading decisions must account for them. The README's own warnings set boundaries that affect design choices: Java serialization is not stable across versions, and the classes are not intended to mediate between trusted and untrusted code. The com.google.common.io features may not work correctly outside Linux.

Who should try it

Good fit: a Java team maintaining a shared library or a codebase that already relies on Guava types in public signatures and wants a stable, documented collection toolkit. The compatibility commitment and the Android flavor are concrete reasons to choose it over an ad-hoc internal utility jar. A developer building with Kotlin might find enough in the Kotlin standard library to avoid the dependency, as one commenter reported porting most usage away (2023-11-08, comment); that is an anecdote, not a project claim.

Poor fit: a project that needs only one or two helpers the JDK now offers, or one whose dependency scanners flag Guava advisories for functionality that is barely used. In the latter case, the cost is ongoing triage rather than a one-time setup decision. An Android developer should use the Android flavor rather than the JRE one, per the README.

Requirements and limitations

Start with the artifact choice: -jre requires JDK 8+, while -android exists for Android and libraries that want Android compatibility; the README explains both Maven and Gradle declaration paths. If Guava types appear in your public API, you must expose them deliberately through api rather than implementation, which affects everything downstream.

The bigger cost is ongoing. Guava's size and breadth mean it is often flagged by vulnerability scanners; commenter discussion from 2023-11-08 notes the chore of dealing with advisories for functionality that did not actually rely on Guava (comment). That is a community observation, not a statement of project policy, but it is the kind of maintenance burden a team should price in. A second boundary: avoid @Beta APIs if your code is itself a library, because they can change without notice.

HotRepo's take

The dated HotRepo sample is thin: Guava appeared on the daily board on 2026-08-06 through 2026-08-09, rising from 51,575 to 51,885 stars, and later showed +15 stars on a Java weekly board at #12 on 2026-10-27. These are isolated observations, not a continuous series, so they cannot establish momentum either way. For a 2014-era repository, appearance on the trending board is a snapshot of attention, not proof of fitness for your build. Before adopting it, verify the compatibility and dependency notes against how your public API exposes Guava types.