deps: update dependency com.google.guava:guava-testlib to v33.4.8-jre

[renovate-bot]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
com.google.guava:guava-testlib	33.4.0-jre -> 33.4.8-jre

---

Release Notes

google/guava (com.google.guava:guava-testlib)

v33.4.7: 33.4.7

Compare Source

Prefer to upgrade straight to 33.4.8: 33.4.7 breaks the build of Android apps with a minSdkVersion below 26. We will publish a fixed version soon. This problem is fixed in 33.4.8.

Guava 33.4.7, like 33.4.6, fixes two problems that we introduced while modularizing Guava and migrating off Unsafe in 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 the effects of Guava 33.4.5 and higher on the module system.

Maven

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

Jar files

• 33.4.7-jre.jar
• 33.4.7-android.jar

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

• failureaccess-1.0.3.jar

Javadoc

• 33.4.7-jre
• 33.4.7-android

JDiff

• 33.4.7-jre vs. 33.4.6-jre
• 33.4.7-android vs. 33.4.6-android
• 33.4.7-android vs. 33.4.7-jre

Changelog

• Modified the guava module's dependency on failureaccess to be transitive. Also, modified the guava-testlib module to make its dependency on guava transitive, to remove its dependency on failureaccess, and to add a dependency (transitive) on junit. (63ecdf2)
• util.concurrent: Modified our fast paths to ensure that they continue to work when run through optimizers, such as those commonly used by Android apps. This fixes problems that some users may have seen since Guava 33.4.5. (b8dcaed, f9eff73)
• util.concurrent: Changed the guava-android copy of AbstractFuture to try VarHandle before Unsafe, eliminating a warning under newer JDKs. (7336af1)

v33.4.6: 33.4.6

Compare Source

Prefer to upgrade straight to 33.4.8: While Guava 33.4.6 fixes two problems that we introduced while modularizing Guava in 33.4.5, it still contains some small problems with the module system, and it may still cause trouble for optimizers, and the subsequent 33.4.7 breaks the build of Android apps with a minSdkVersion below 26. These problems have been fixed in 33.4.8.

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 the effects of Guava 33.4.5 and higher on the module system.

Maven

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

Jar files

• 33.4.6-jre.jar
• 33.4.6-android.jar

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

• failureaccess-1.0.3.jar

Javadoc

• 33.4.6-jre
• 33.4.6-android

JDiff

• 33.4.6-jre vs. 33.4.5-jre
• 33.4.6-android vs. 33.4.5-android
• 33.4.6-android vs. 33.4.6-jre

Changelog

• Removed the extra copy of each class from the Guava jar. The extra copies were an accidental addition from the modularization work in Guava 33.4.5. (40485b9)
• Fixed annotation-related warnings when using Guava in modular builds. The most common such warning is Cannot find annotation method 'value()' in type 'DoNotMock': .... (7e15ab3)

v33.4.5: 33.4.5

Compare Source

Use Guava 33.4.8, not Guava 33.4.5. 33.4.5 was our first attempt to modularize Guava, but we misconfigured our build, so it:

• contains an extra copy of each of its classes
• does not declare its dependencies on artifacts of annotations

33.4.5 (and 33.4.6) also may cause trouble for some optimizers (like those commonly used for Android apps), and 33.4.7 breaks the build of Android apps with a minSdkVersion below 26.

All these issues are fixed by release 33.4.8. Sorry for the trouble.

When you read the release notes for 33.4.8, you should also read the release notes for Guava 33.4.1, even if you're not upgrading from Guava 33.4.0 or earlier: Those release notes contain information about the effect of Guava 33.4.5 and higher 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.

v33.4.4: 33.4.4

Compare Source

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.8.

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)

v33.4.3: 33.4.3

Compare Source

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.8.

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)

v33.4.2: 33.4.2

Compare Source

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.8.

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)

v33.4.1: 33.4.1

Compare Source

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.8 to pick up a few small improvements with no disruption.

If you encounter trouble with 33.4.8, then read on.

Module-system trouble

First, use Guava 33.4.8, not Guava 33.4.5. 33.4.5 was our first attempt to modularize Guava, but we made a few mistakes, so it:

• contains an extra copy of each of its classes
• does not declare its dependencies on artifacts of annotations and misdeclares (as does 33.4.6) a few other dependencies

33.4.5 (and 33.4.6) also may cause trouble for some optimizers (like those commonly used for Android apps), and 33.4.7 breaks the build of Android apps with a minSdkVersion below 26.

All these issues are fixed by release 33.4.8. Sorry for the trouble.

Guava 33.4.8 (after a false start in 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.8 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)

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[dpebot]

/gcbrun

[dpebot]

/gcbrun

[dpebot]

/gcbrun

[dpebot]

/gcbrun