JacocoCoverage_jarjar_deploy.jar should shade its internal copy of Guava

[ghost]

One of my users has some ancient tests which are built against Guava 18. Upon upgrading to Bazel 4 with java_tools javac11-10.5, the test fails when running under bazel coverage.

[VerboseTestNG] java.lang.NoSuchMethodError: com.google.common.util.concurrent.Futures.withFallback(Lcom/google/common/util/concurrent/ListenableFuture;Lcom/google/common/util/concurrent/FutureFallback;Ljava/util/concurrent/Executor;)Lcom/google/common/util/concurrent/ListenableFuture;

This method was flagged as deprecated and slated for removal in Guava 20.0.

Analysis revealed that Bazel inserts JacocoCoverage_jarjar_deploy.jar near the head of CLASSPATH, and this jar contains its own, newer copy of Guava. However, the embedded Guava classes aren't shaded and so take precedence over the user's desired version.

Would this "just" require adding rule(s) to src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar ?

rule com.google.common.** com.google.testing.coverage.jarjar.@0

[ghost]

Following appears to have done the trick. bazel coverage //mycruftytarget now succeeds and produces a coverage.dat usable with lcov.

diff --git a/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar b/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar
index 56190d874c..081c5420f8 100644
--- a/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar
+++ b/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar
@@ -1,2 +1,3 @@
+rule com.google.common.** com.google.testing.coverage.jarjar.@0
 rule org.apache.commons.** com.google.testing.coverage.jarjar.@0
 rule org.objectweb.asm.** com.google.testing.coverage.jarjar.@0

[comius]

Can you submit a PR?

[JaimeLotero]

Following appears to have done the trick. bazel coverage //mycruftytarget now succeeds and produces a coverage.dat usable with lcov.

diff --git a/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar b/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar
index 56190d874c..081c5420f8 100644
--- a/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar
+++ b/src/java_tools/junitrunner/java/com/google/testing/coverage/JacocoCoverage.jarjar
@@ -1,2 +1,3 @@
+rule com.google.common.** com.google.testing.coverage.jarjar.@0
 rule org.apache.commons.** com.google.testing.coverage.jarjar.@0
 rule org.objectweb.asm.** com.google.testing.coverage.jarjar.@0

Sorry to revive this old issue but I can't find this information anywhere else. I'm getting this exact problem in one huge Java repository; I noticed this patch made it into Bazel 5, but unfortunately I'm using version 4.2.2 and upgrading is not an option for now. How did you test this in-place? Is there any way I can configure Bazel to forcefully introduce this patch to Jacoco?

[ghost]

How did you test this in-place? Is there any way I can configure Bazel to forcefully introduce this patch to Jacoco?

@JaimeLotero We build java_tools from source.

1. Determine which java_tools release corresponds to your Bazel version. It looks like Bazel 4.2.2 uses java_tools 10.6. (See jdk.WORKSPACE.)
2. Download a java_tools release artifact (e.g. java_tools_javac11_linux-v10.6.zip) and extract README.md.
3. Follow instructions from the README to build java_tools.
4. Publish your own java_tools artifacts within your organization.
5. Update your local WORKSPACE to provide its own explicit http_archive(name = "remote_java_tools_<platform>", ...) repository rules which point to your modified java_tools artifacts.

Hope this helps.

[JaimeLotero]

@beasleyr-vmw thank you so much for the detailed explanation, that did the job.