Update Guava to 31.1.

[haxorz]

Main motivation is to be able to use the new
ImmutableMap.Builder#buildKeepingLast.

Jars were downloded from Maven Central:

• https://repo1.maven.org/maven2/com/google/guava/guava/31.1-jre/
• https://repo1.maven.org/maven2/com/google/guava/guava-testlib/31.1-jre/

This is the same as commit 5d55643, but I'm doing it as a GitHub PR
rather than a Gerrit change, so that way we can run it through the CI
pipeline and figure out why it didn't work (5d55643 was reverted in
b9bfde8).

[haxorz]

Hi Alex and Kevin. Looks like some GitHub automation added you because I modified src/test/java/com/google/devtools/build/android/desugar/BUILD.

Just a heads up that this PR isn't complete yet. If my modification to that BUILD file works out, then I need to modify all other consumers of //third_party:guava-jars.

[meteorcloudy]

You probably need to split this into two filegroups

filegroup(
    name = "guava-jar",
    srcs = ["guava/guava-31.1-jre.jar"],
)

filegroup(
    name = "guava-failureaccess-jar",
    srcs = ["guava/guava-31.1-jre.jar"],
)

distrib_jar_filegroup(
    name = "guava-jars",
    srcs = [
        ":guava-jar",
        ":guava-failureaccess-jar",
    ],
    enable_distributions = ["debian"],
)

Then you can add them separately above:

"--classpath_entry $(location //third_party:guava-jar) " +
"--classpath_entry $(location //third_party:guava-failureaccess-jar) " +

[haxorz]

Experimentally, it seems like it's not necessary to do literally that. 6fbe89e passes CI. Is that commit fine? And do I really need to have used distrib_jar_filegroup for the new //third_party:guava-failureaccess-jar?

[haxorz]

Also, if srcs in :guava-jars has more than one element then we run into the issue mentioned in b98be959.

[meteorcloudy]

I see, it looks good. Using distrib_jar_filegroup is for the Bazel Debian build to switch to system installed libraries easily (eg. /usr/share/java/guava.jar), it's better to keep this pattern in case we want to package a new Bazel for Debian.

[haxorz]

Okay, 6fbe89e passed CI.

@meteorcloudy Is the restriction mentioned in #14357 (comment) still a thing? If so, I will need to do 3 PRs: One to add a new //third_party:guava-failureaccess-jar target to third_party/BUILD, one to preemptively use it in //src/test/java/com/google/devtools/build/android/desugar:desugar_guava_at_head, and a final one to update the jar files used by //third_party:guava-jars and //third_party:guava-testlib. Then I will do 2 more PRs after that (one to update compile.sh and one to delete the old Guava jars). Please confirm this is what I need to do. Then I will add a comment explaining the issue 5d55643 tickled.

[meteorcloudy]

Yes, #14357 (comment) is still true, what you described sounds good to me!

[haxorz]

[me] Then I will add a comment explaining the issue 5d55643 tickled.

@cushon and @michajlo figured this out. Guava 31.1 newly contains google/guava@46093e2. They verified that code causes the Desugaring step at

bazel/src/test/java/com/google/devtools/build/android/desugar/BUILD

Line 2094 in ae41448

name = "desugar_guava_at_head",

to think about class InternalFutureFailureAccess, whereas it previously didn't need that class. So we now need to make sure Desugar has the jar containing that class on its classpath.

[haxorz]

My sequence of changes needs to involve 5 commits. @katre advised me to do 5 separate PRs, so that he can vet and merge each one separately. So I'll close this one and then mail those out.