commit | 3f61870ac6e5b18dbb74ce6f6cb2930ad8750a43 | [log] [tgz] |
---|---|---|
author | Google Java Core Libraries <java-team-github-bot@google.com> | Fri May 24 09:39:45 2024 -0700 |
committer | Google Java Core Libraries <jake-team+copybara@google.com> | Fri May 24 09:44:05 2024 -0700 |
tree | 89bc2f50d5883a0b2dd0cf6ed66751ed760697f1 | |
parent | f238ae451fd9c0b3d88c2d94b9e89257cb34fff8 [diff] |
Change `InetAddress`-`String` conversion methods to preserve the scope ID. This matches the behavior in https://bugs.openjdk.org/browse/JDK-8272215 (except still not supporting brackets []) RELNOTES=`net`: Changed `InetAddress`-`String` conversion methods to preserve the scope ID. This may lead to two kinds of problems: First, callers of those methods may be relying on the returned values _not_ to include the scope ID. For example, they 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 included a scope ID before adding one yourself.) Or they may 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)`. The other possible cause for problems is that `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, including if the code runs in an Android app without networking permission. 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. PiperOrigin-RevId: 636947430
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, 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 33.2.0-jre
or 33.2.0-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>33.2.0-jre</version> <!-- or, for Android: --> <version>33.2.0-android</version> </dependency>
To add a dependency using Gradle:
dependencies { // Pick one: // 1. Use Guava in your implementation only: implementation("com.google.guava:guava:33.2.0-jre") // 2. Use Guava types in your public API: api("com.google.guava:guava:33.2.0-jre") // 3. Android - Use Guava in your implementation only: implementation("com.google.guava:guava:33.2.0-android") // 4. Android - Use Guava types in your public API: api("com.google.guava:guava:33.2.0-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.2
. 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 OpenJDK 8, 11, and 17 on Linux, with some additional testing on newer JDKs and on Windows. Some features, especially in com.google.common.io
, may not work correctly in non-Linux environments. For the Android flavor, our unit tests also run on API level 21 (Lollipop).