33.4.5

Even if you're not upgrading from Guava 33.4.0 or earlier, still read the release notes for Guava 33.4.1. Those release notes contain information about Guava 33.4.5's effect on the module system.

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.4.5-jre</version>
  <!-- or, for Android: -->
  <version>33.4.5-android</version>
</dependency>

Jar files

• 33.4.5-jre.jar
• 33.4.5-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.3.jar

Javadoc

• 33.4.5-jre
• 33.4.5-android

JDiff

• 33.4.5-jre vs. 33.4.4-jre
• 33.4.5-android vs. 33.4.4-android
• 33.4.5-android vs. 33.4.5-jre

Changelog

• Changed the Guava jar (plus guava-testlib and failureaccess jars) to be a modular jar. (7a71ea0, 287c701)
• Changed various classes to stop using sun.misc.Unsafe under Java 9+. (ee63055, 80aab00, 400af25, 71d0692, d1a3cd5, b3bb29a, 1a300f6)
  • Note that, if you use guava-android on the JVM (instead of using guava-jre), Guava will still try to use sun.misc.Unsafe. We will do further work on this in the future.
• Belatedly updated the Public Suffix List data. (ee3b9c6, d25d62f)

Special thanks to @sgammon for his modularization efforts.

33.4.4

This is one of a series of releases that improve Guava's nullness annotations. For more information, including troubleshooting help, see the release notes for Guava 33.4.1. Most users can update directly to Guava 33.4.5.

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.4.4-jre</version>
  <!-- or, for Android: -->
  <version>33.4.4-android</version>
</dependency>

Jar files

• 33.4.4-jre.jar
• 33.4.4-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.4.4-jre
• 33.4.4-android

JDiff

• 33.4.4-jre vs. 33.4.3-jre
• 33.4.4-android vs. 33.4.3-android
• 33.4.4-android vs. 33.4.4-jre

Changelog

• Migrated from Checker Framework annotations to JSpecify annotations. (2cc8c5e)
• Made our usages of nullness annotations available in our GWT artifact. GWT users will need to upgrade to GWT 2.12.1, which makes GWT as tolerant of Java 8 type-use annotations as it is of other annotations. (80559d2)

33.4.3

This is one of a series of releases that improve Guava's nullness annotations. For more information, including troubleshooting help, see the release notes for Guava 33.4.1. Most users can update directly to Guava 33.4.5.

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.4.3-jre</version>
  <!-- or, for Android: -->
  <version>33.4.3-android</version>
</dependency>

Jar files

• 33.4.3-jre.jar
• 33.4.3-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.4.3-jre
• 33.4.3-android

JDiff

• 33.4.3-jre vs. 33.4.2-jre
• 33.4.3-android vs. 33.4.2-android
• 33.4.3-android vs. 33.4.3-jre

Changelog

• Migrated from @CheckForNull to the Checker Framework @Nullable. Most tools recognize both annotations, so we expect this to be a no-op in almost all cases. This release removes our dependency on JSR-305. (d997ad9)

33.4.2

This is one of a series of releases that improve Guava's nullness annotations. For more information, including troubleshooting help, see the release notes for Guava 33.4.1. Most users can update directly to Guava 33.4.5.

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.4.2-jre</version>
  <!-- or, for Android: -->
  <version>33.4.2-android</version>
</dependency>

Jar files

• 33.4.2-jre.jar
• 33.4.2-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.4.2-jre
• 33.4.2-android

JDiff

• 33.4.2-jre vs. 33.4.1-jre
• 33.4.2-android vs. 33.4.1-android
• 33.4.2-android vs. 33.4.2-jre

Changelog

• Changed @ParametricNullness into a no-op for Kotlin and IntelliJ. Before now, it was forcing many usages of type variables to have platform types, which meant that Kotlin couldn't check those usages for nullness errors. With this change, Kotlin can detect more errors. (ae36f57)

33.4.1

Today, we are releasing Guava 33.4.1 and a few other 33.4.x releases. All the releases maintain binary compatibility, but they include changes to nullness and the module system that may be disruptive to some users.

Most users can jump straight to 33.4.5 to pick up a few small improvements with no disruption.

If you encounter trouble with 33.4.5, then read on.

Module-system trouble

Guava 33.4.5 changes Guava to be a Java module. You can still use Guava without using the module system yourself. However, if your build system automatically recognizes Guava as a module, then you may see errors. As a temporary fix, you can upgrade only to 33.4.4 while you investigate the module problems.

If you see build errors (such as package com.google.common.collect is not visible), try modifying your module-info.java to include requires com.google.common;.

If you see runtime errors, then you may be performing reflection on Guava internals. We recommend not doing this, since Guava internals change frequently, potentially breaking such code. The module system is designed to call attention to this situation, but you can always silence it with --add-opens, passing the module name (com.google.common) and package name from your error message along with the name of the module that is accessing Guava's internals (which is also shown in the error message).

Nullness trouble

Nullness annotations have no effect on Java itself, but they do affect nullness checkers, such as NullAway, the Checker Framework, and Kotlin.

If you encounter only a modest number of nullness errors, we recommend upgrading straight to 33.4.5 or higher, suppressing or fixing the errors to prepare for the change.

For build errors from a Java nullness checker, you can generally silence them with @SuppressWarnings (docs: NullAway, the Checker Framework, Error Prone). Of course, we recommend inspecting at least a few new errors so that you can judge whether the errors are worth fixing instead of just suppressing.

For build errors from Kotlin, there is no supported way to suppress. (If, after reading the instructions here, you believe that one would be valuable, please share your experiences with the Kotlin developers.) You'll instead need to change your code, often in one of the following ways:

• To insert a null value into a collection, you may need to change the collection's type, like from Multiset<Foo> to Multiset<Foo?>.
  • The same kind of change can be useful for other generic types, like in changing a FutureCallback<Foo> to a FutureCallback<Foo?> so that its onSuccess method can still be declared to accept a Foo?.
• When using our immutable collections or other null-hostile types, you may need to make the opposite change, like by using ImmutableList<Foo> instead of ImmutableList<Foo?>.
  • If you are writing your own generic API, you may need to restrict your type argument to non-null types. For example, for ImmutableList<T> to be valid, you may need to change your type-parameter declaration from <T> to <T: Any>. Occasionally, you may want to keep the type-parameter declaration as it is but change to using ImmutableList<T & Any>.
• You can change the nullness of a type by using !! or a cast. These operators sometimes introduce a runtime check where there was not one before.
• Or there may be better fixes, such as changing the types of your own parameters to forbid null.

Gradual migration

If you encounter a large number of errors when upgrading, then you may wish to upgrade your Guava version incrementally. Guava 33.4.1, 33.4.2, 33.4.3, and 33.4.4 are each one step toward improving Guava's nullness annotations. You may find it easier to upgrade one version at a time. By doing so, you can handle all problems of a particular "kind" at once. Then, once you submit the upgrade, you prevent backsliding of that kind. (Almost all problems should surface in the upgrade to 33.4.1 or the upgrade to 33.4.2.)

If you take this path, you may wish to set -Xjsr305=strict before even the first Guava upgrade. That flag may identify a subset of problems ahead of the Guava changes. Note, however, that it may also cause Kotlin to detect nullness errors in your usages of any other libraries that use custom nullness annotations. If so, the flag would cause you to have to perform a larger cleanup that the Guava upgrade requires, so you'll have to judge whether that flag would be helpful on net.

Temporary emergency fallback option: Disabling current and future checking of Java APIs

In the worst case, it is possible to tell Kotlin not to produce errors for any usages of JSpecify annotations, both those in Guava and those in other libraries (such as Caffeine and the forthcoming Spring Framework 7). You can do this by setting -Xjspecify-annotations=warn. If you are considering this, we recommend instead deferring your upgrade of Guava to give yourself time to work through the nullness errors. We are making an effort not to publish a release with new APIs in the near future, so you should be able to safely defer upgrading for a while. If you do still choose to set the flag, we recommend working to remove it in the future, since it will hide more and more errors as time goes by.

For more help

We monitor for Guava questions on StackOverflow. If you believe that you are seeing a bug in a nullness checker, you can report it to the tool owners (e.g., NullAway, the Checker Framework). If you believe that you are seeing a problem with these instructions or with Guava's nullness annotations, report a bug to us.

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.4.1-jre</version>
  <!-- or, for Android: -->
  <version>33.4.1-android</version>
</dependency>

Jar files

• 33.4.1-jre.jar
• 33.4.1-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.4.1-jre
• 33.4.1-android

JDiff

• 33.4.1-jre vs. 33.4.0-jre
• 33.4.1-android vs. 33.4.0-android
• 33.4.1-android vs. 33.4.1-jre

Changelog

• Replaced our custom @ElementTypesAreNonnullByDefault annotations with the JSpecify @NullMarked annotation. (8ebb375)

33.4.0

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.4.0-jre</version>
  <!-- or, for Android: -->
  <version>33.4.0-android</version>
</dependency>

Jar files

• 33.4.0-jre.jar
• 33.4.0-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.4.0-jre
• 33.4.0-android

JDiff

• 33.4.0-jre vs. 33.3.1-jre
• 33.4.0-android vs. 33.3.1-android
• 33.4.0-android vs. 33.4.0-jre

Changelog

• Exposed additional Java 8 APIs to Android users. (6082782, 9b0109c, 6ace8bc, b650b9f, c6c2680, 984f713, f9f3fff, cdc2254)
• base: Deprecated Charsets constants in favor of StandardCharsets. We will not remove the constants, but we recommend using StandardCharsets for consistency. (45e6be2)
• base: Added ToStringHelper.omitEmptyValues(). (f5ec2ab)
• collect: Added an optimized copyOf method to TreeRangeMap. (a46565d)
• collect.testing: Fixed @Require annotations so that features implied by absent features are not also required to be absent. (81be061)
• io: Changed ByteSink and CharSink to no longer call flush() in some cases before close(). This is a no-op for well-behaved streams, which internally flush their data as part of closing. However, we have discovered some stream implementations that have overridden close() to do nothing, including not to flush some buffered data. If this change causes problems, the simplest fix is usually to change the close() override to at least call flush(). (6ace8bc)
• net: Added HttpHeaders.ALT_SVC and MediaType.CBOR. (503ba42, 7c0bf08)

33.3.1

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.3.1-jre</version>
  <!-- or, for Android: -->
  <version>33.3.1-android</version>
</dependency>

Jar files

• 33.3.1-jre.jar
• 33.3.1-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.3.1-jre
• 33.3.1-android

JDiff

• 33.3.1-jre vs. 33.3.0-jre
• 33.3.1-android vs. 33.3.0-android
• 33.3.1-android vs. 33.3.1-jre

Changelog

• Added j2objc-annotations to the Gradle runtime classpath to stop producing an Android Gradle Plugin error. (a3b5188)

33.3.0

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.3.0-jre</version>
  <!-- or, for Android: -->
  <version>33.3.0-android</version>
</dependency>

Jar files

• 33.3.0-jre.jar
• 33.3.0-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.3.0-jre
• 33.3.0-android

JDiff

• 33.3.0-jre vs. 33.2.1-jre
• 33.3.0-android vs. 33.2.1-android
• 33.3.0-android vs. 33.3.0-jre

Changelog

• base: Removed @Beta from the Duration overload of Suppliers.memoizeWithExpiration. (76fca99)
• cache: Added CacheBuilder Duration overloads to guava-android. (a5f9bca)
• collect: Removed @Beta from the guava-android Collector APIs. (c86c09d)
• collect: Added ImmutableMultimap.builderWithExpectedKeys and ImmutableMultimap.Builder.expectedValuesPerKey. (c3d5b17)
• graph: Improved Graphs.hasCycle to avoid causing StackOverflowError for long paths. (63734b9)
• net: Added text/markdown to MediaType. (2466a09)
• net: Deprecated HttpHeaders constant for Sec-Ch-UA-Form-Factor in favor of Sec-Ch-UA-Form-Factors to follow the latest spec. (b310b7e)
• testing: Changed some test libraries to throw AssertionError (instead of the more specific AssertionFailedError) in some cases. (fdfbed1)

33.2.1

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.2.1-jre</version>
  <!-- or, for Android: -->
  <version>33.2.1-android</version>
</dependency>

Jar files

• 33.2.1-jre.jar
• 33.2.1-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.2.1-jre
• 33.2.1-android

JDiff

• 33.2.1-jre vs. 33.2.0-jre
• 33.2.1-android vs. 33.2.0-android
• 33.2.1-android vs. 33.2.1-jre

Changelog

• net: Changed InetAddress-String conversion methods to preserve the IPv6 scope ID if present. The scope ID can be necessary for IPv6-capable devices with multiple network interfaces. However, preserving it can also lead to problems for callers that rely on the returned values not to include the scope ID:
  • Callers might compensate for the old behavior of the methods by appending the scope ID to a returned string themselves. If so, you can update your code to stop doing so at the same time as you upgrade Guava. Of, if your code might run against multiple versions of Guava, you can check whether Guava has included a scope ID before you add one yourself.
  • Callers might pass the returned string to another system that does not understand scope IDs. If so, you can strip the scope ID off, whether by truncating the string form at a % character (leaving behind any trailing ] character in the case of forUriString) or by replacing the returned InetAddress with a new instance constructed by calling InetAddress.getByAddress(addr).
  • java.net.InetAddress validates any provided scope ID against the interfaces available on the machine. As a result, methods in InetAddresses may now fail if the scope ID fails validation.
    • Notable cases in which this may happen include:
      • if the code runs in an Android app without networking permission
      • if code passes InetAddress instances or strings across devices
    • If this is not the behavior that you want, then you can strip off the scope ID from the input string before passing it to Guava, as discussed above. (3f61870)

33.2.0

Android users: Please test recent Guava versions

If you know of Guava Android users who have not yet upgraded to at least release 33.0.0, please encourage them to upgrade, preferably to today's release, 33.2.0. These releases have begun adding Java 8+ APIs to guava-android. While we don't anticipate problems, we do anticipate that any unexpected problems could force a disruptive rollback. To minimize any disruption, we'd like to catch any such problems early.

Please let us know of any problems you encounter.

Maven

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>33.2.0-jre</version>
  <!-- or, for Android: -->
  <version>33.2.0-android</version>
</dependency>

Jar files

• 33.2.0-jre.jar
• 33.2.0-android.jar

Guava requires one runtime dependency, which you can download here:

• failureaccess-1.0.2.jar

Javadoc

• 33.2.0-jre
• 33.2.0-android

JDiff

• 33.2.0-jre vs. 33.1.0-jre
• 33.2.0-android vs. 33.1.0-android
• 33.2.0-android vs. 33.2.0-jre

Changelog

• Dropped testing for Android versions before Lollipop (API Level 21). Guava may stop working under older versions in the future, or it may have done so already.
• Fixed a GWT compilation breakage under Gradle. (858caf4)
• collect: Made our Collector APIs (e.g., ImmutableList.toImmutableList()) available in guava-android. More Java 8 APIs will follow in future releases. (96fca0b)
  • As always, streams are available to Android code only when that code enables library desugaring or targets a new enough API Level (24 (Nougat) for many stream APIs). (But note that we test only with library desugaring, so we don't currently know if API Level 24 is high enough to use our Collector APIs unless you have also enabled library desugaring.) Guava users who avoid the Collector APIs do not need to meet this requirement.
• collect: Fixed a potential NullPointerException in ImmutableMap.Builder on a rare code path. (70a9811)
• net: Added HttpHeaders constants Ad-Auction-Allowed, Permissions-Policy-Report-Only, and Sec-GPC. (7dc01ed, 41d0d9a, 38c8017)