| commit | cc924424c157ed99cd0ac66c9597f59e32eff13b | [log] [tgz] |
|---|---|---|
| author | cpovirk <cpovirk@google.com> | Mon Apr 17 11:37:28 2023 -0700 |
| committer | Google Java Core Libraries <java-core-libraries-team+copybara@google.com> | Mon Apr 17 11:39:38 2023 -0700 |
| tree | ed1d72caf49480a98e2741092da6cc247e06ba9e | |
| parent | 3f039fc6ad1edc4ac4a8284b8159310d0844542f [diff] |
Disable `NullPointerTester` when `com.google.common` is being tested under Android VMs. As we already started to see in cl/522315614, it can't work there with type-use annotations. So, when more type-use annotations appear in cl/522310996, we'd see more failures. `NullPointerTester` will continue to run when guava-android is tested _under a JRE_, including in our open-source tests. All that this CL affects is the additional Android-emulator tests that we run on Google infrastructure. And while it's _nice_ to run all our tests under an emulator, their _primary_ purpose is to check for usages of APIs that aren't available under old versions of Android, not to look for differences in null-handling behavior between Android and JRE (which is possible but relatively unlikely). A more principled approach would be to edit every test that _uses_ `NullPointerTester` to skip the test under Android VMs. However, this would require editing 100+ files. And it would actually require editing even _more_: In every package that we define a `PackageSanityTests` class, `NullPointerTester` runs automatically on every class `Foo` in the package _unless_ `AbstractPackageSanityTests` finds that we've defined a method like `FooTest.testNulls()`. Thus, we'd likely have to define dozens more such methods. And those new methods may be not completely trivial in some cases, if I'm remembering how much `PackageSanityTests` does automatically (to, e.g., construct instances of the class to test against). Finally, if it helps, we did something similar to silently disable `SerializableTester` under GWT way back in cl/25672151, though I'm not sure I'd stand by that one today, since we could have modified _that_ class's users to skip the testing under GWT more easily :) In a fun twist, we have to keep the `@AndroidIncompatible` annotations in `ClassSanityTesterTest` and `NullPointerTesterTest`: - Before, those tests failed because they didn't see type-use `@Nullable` annotations and thus tried to pass `null` where it wasn't valid. - Now, those tests fail because they try to make `NullPointerTester` fail on badly annotated classes, but it doesn't fail because it's doesn't run at all! RELNOTES=n/a PiperOrigin-RevId: 524904788
Guava is a set of core Java libraries from Google that includes new collection types (such as multimap and multiset), immutable collections, a graph library, and utilities for concurrency, I/O, hashing, caching, primitives, strings, and more! It is widely used on most Java projects within Google, and widely used by many other companies as well.
Guava comes in two flavors:
android directory.Guava's Maven group ID is com.google.guava, and its artifact ID is guava. Guava provides two different “flavors”: one for use on a (Java 8+) JRE and one for use on Android or by any library that wants to be compatible with Android. These flavors are specified in the Maven version field as either 31.1-jre or 31.1-android. For more about depending on Guava, see using Guava in your build.
To add a dependency on Guava using Maven, use the following:
<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>31.1-jre</version> <!-- or, for Android: --> <version>31.1-android</version> </dependency>
To add a dependency using Gradle:
dependencies { // Pick one: // 1. Use Guava in your implementation only: implementation("com.google.guava:guava:31.1-jre") // 2. Use Guava types in your public API: api("com.google.guava:guava:31.1-jre") // 3. Android - Use Guava in your implementation only: implementation("com.google.guava:guava:31.1-android") // 4. Android - Use Guava types in your public API: api("com.google.guava:guava:31.1-android") }
For more information on when to use api and when to use implementation, consult the Gradle documentation on API and implementation separation.
Snapshots of Guava built from the master branch are available through Maven using version HEAD-jre-SNAPSHOT, or HEAD-android-SNAPSHOT for the Android flavor.
APIs marked with the @Beta annotation at the class or method level are subject to change. They can be modified in any way, or even removed, at any time. If your code is a library itself (i.e., it is used on the CLASSPATH of users outside your own control), you should not use beta APIs unless you repackage them. If your code is a library, we strongly recommend using the Guava Beta Checker to ensure that you do not use any @Beta APIs!
APIs without @Beta will remain binary-compatible for the indefinite future. (Previously, we sometimes removed such APIs after a deprecation period. The last release to remove non-@Beta APIs was Guava 21.0.) Even @Deprecated APIs will remain (again, unless they are @Beta). We have no plans to start removing things again, but officially, we're leaving our options open in case of surprises (like, say, a serious security problem).
Guava has one dependency that is needed for linkage at runtime: com.google.guava:failureaccess:1.0.1. It also has some annotation-only dependencies, which we discuss in more detail at that link.
Serialized forms of ALL objects are subject to change unless noted otherwise. Do not persist these and assume they can be read by a future version of the library.
Our classes are not designed to protect against a malicious caller. You should not use them for communication between trusted and untrusted code.
For the mainline flavor, we test the libraries using only OpenJDK 8 and OpenJDK 11 on Linux. Some features, especially in com.google.common.io, may not work correctly in other environments. For the Android flavor, our unit tests also run on API level 15 (Ice Cream Sandwich).