Skip to content

31.0
Compare
Choose a tag to compare
@cpovirk cpovirk released this 24 Sep 21:36
· 1053 commits to master since this release
v31.0
6edcfc0

Maven

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

Jar files

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

Javadoc

JDiff

Changelog

Known issue (fixed in patch release 31.0.1): guava-gwt breaks GWT compilation

Other Guava artifacts aren't affected, only users of GWT. (If you are using GWT, you would know it.)

Sorry for missing this during release: It was a known issue, and we had a partial workaround in place, but I forgot to include the problem in the list of release blockers.

To pick up the fix, upgrade to 31.0.1.

Main changes

  • Changed guava-android to generate Java 8 bytecode. We still restrict ourselves to using APIs available on Ice Cream Sandwich. So, as long as you have enabled Java 8 language features for your Android build, this change should have no effect on Android projects. This change does drop support for Java 7 JREs, as announced last year.
  • Annotated Guava much more thoroughly for nullness. For details, see the bottom of the release notes.
  • base: Changed Functions.forSupplier and Predicates.instanceOf to accept an additional type argument to specify the input type for the returned Function/Predicate. The flexibility we're adding should typically not be necessary if users follow the PECS principle, but it can be useful in some cases, particularly around nullness analysis. Note that this change may require updates to callers' source code (to specify an additional type argument). Still, it maintains binary compatibility. (75110e9)
  • collect: Added ImmutableMap.ofEntries, like Map.ofEntries but for ImmutableMap. (cd3b419)
  • collect: Added overloads of ImmutableMap.of, ImmutableBiMap.of, and ImmutableSortedMap.of for up to 10 entries. (d5c30e3)
  • collect: Renamed ImmutableMap.Builder.build() to buildOrThrow(). The existing build() method will continue to exist but may be deprecated, and the new name should be used in new code. (4bbe12c)
  • collect: Removed @Beta from Interner and Interners. (cf31f3a)
  • collect: Added @InlineMe to Streams.stream(Optional) and friends. (a176cd6)
  • graph: Made EndpointPair.adjacentNode require an N instead of accept any Object. (b0be21d)
  • hash: Removed @Beta from HashFunction. (e1cc195)
  • hash: Deprecated buggy murmur3_32, and introduced murmur3_32_fixed. (a36f08f)
  • io: Changed CharStreams.asWriter(appendable).write(string[, ...]) to reject a null string. (50e7ddd)
  • io: Fixed a bug in FileBackedOutputStream cleanup: If writing to the temp file fails, we now delete it before propagating the exception. (6e054ce)
  • net: Changed HostAndPort.fromString to reject port numbers spelled with non-ASCII digits. (53fd1d7)
  • net: Added HttpHeaders constants for X-Device-Ip, X-Device-Referer, X-Device-Accept-Language, X-Device-Requested-With, Sec-CH-Prefers-Color-Scheme, Sec-CH-UA-Bitness, and Keep-Alive. (da375be, b23b277, 281edd4, 9c88f9a)
  • primitives: Fixed a rounding bug in UnsignedLong.doubleValue(). (e61cf2e)
  • reflect: Changed the type hierarchy of Invokable: Invokable no longer inherits from AccessibleObject or GenericDeclaration, though it continues to define instance methods with the same signatures as the formerly inherited ones. This is technically a breaking API change to this @Beta API. We think it very unlikely that anyone is affected in practice. (12af215)
  • testlib: Enhanced NullPointerTester to allow a parameter of type <T extends @Nullable Object> to be null. (e856722)
  • testlib: Fixed bug affecting derived tests of custom collection test suites: The setUp and tearDown methods are now copied to derived test suites. (c7d9fef)
  • util.concurrent: Added ServiceManager.startupDurations(). (c95ba5a)
  • util.concurrent: Removed the GWT-only overloads of Futures.catching and catchingAsync that let callers omit the Executor. This matches a change made years ago to the non-GWT API. If this breaks your GWT client code compilation, you can fix it by passing an additional parameter, MoreExecutors.directExecutor() (0ff2f78)

Nullness annotations

Previously, we annotated all parameters that could be null, and we did not annotate elsewhere reliably. Now:

  • We consistently annotate return types for nullness.
  • We annotate "components" of types, like the element type of an array or list and the bound of a type parameter. (To take advantage, Kotlin users can set -Xtype-enhancement-improvements-strict-mode.)
    • However, we don't yet annotate any such locations as non-nullable.
  • In our annotations (including on parameters), we distinguish between @Nullable T ("always nullable, regardless of the type argument used for T") and T ("nullable only if the type argument is").
  • We have temporarily increased our usage of jsr305, which we will ultimately phase out.
    • We use @CheckForNull instead of a type-annotation @Nullable wherever possible. This makes the nullness information available to more Kotlin users.
    • We've introduced a custom jsr305 annotation that informs Kotlin that unannotated return types are non-null (just like our usage of @ParametersAreNonnullByDefault already did for parameter types). (To take advantage, Kotlin users can set -Xjsr305=strict.)

(Known issue: We are missing annotations on the TypeToInstanceMap classes. We'll fix this in a future release.)

By providing additional nullness information, this release may result in more errors or warnings from any nullness analyzers you might use. If so, you may need to fix or suppress them as usual. For advice, see the documentation for the analyzer you're using, such as that for the Checker Framework or for Kotlin.

If you use NullAway with the AnnotatedPackages flag set to cover com.google.common, you may see not only additional legitimate errors but also some incorrect errors because Guava no longer uses @Nullable as frequently on type-variable usages. The NullAway developers have suggested a workaround, and they are planning for NullAway 0.9.9 to treat our type-variable usages differently. However, even after 0.9.9, NullAway users are likely to see some incorrect errors if they keep com.google.common in their AnnotatedPackages. A fuller solution will require Guava and tools to adopt an annotation model that is more suited to generics. For updates on that, follow #2960.

We will be using more annotations to provide more nullness information in the future.

Assets 2
Loading