Javadoc fails with "cannot access InternalFutureFailureAccess"

[archiecobbs]

I am not convinced that this is ultimately Guava's fault, but Guava seems to be causing the problem.

My builds fail during Javadoc because of Guava, like this:

[INFO] --- javadoc:3.5.0:jar (default) @ guava-javadoc-bug-module ---
[INFO] No previous run data found, generating javadoc.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for guava-javadoc-bug 1.0.0:
[INFO] 
[INFO] guava-javadoc-bug .................................. SUCCESS [  0.395 s]
[INFO] guava-javadoc-bug-module ........................... FAILURE [  0.691 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.242 s
[INFO] Finished at: 2023-10-12T14:55:10-05:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project guava-javadoc-bug-module: MavenReportException: Error while generating Javadoc: 
[ERROR] Exit code: 1
[ERROR] /Users/archie/bugs/guava-javadoc-bug.0/module/src/main/java/com/example/MyFuture.java:6: error: cannot access InternalFutureFailureAccess
[ERROR] public abstract class MyFuture extends AbstractFuture<Void> {
[ERROR]                 ^
[ERROR]   class file for com.google.common.util.concurrent.internal.InternalFutureFailureAccess not found
[ERROR] warning: unknown enum constant Level.FULL
[ERROR]   reason: class file for com.google.j2objc.annotations.ReflectionSupport$Level not found
[ERROR] 1 error
[ERROR] 1 warning
[ERROR] Command line was: /opt/homebrew/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home/bin/javadoc @options @packages
[ERROR] 
[ERROR] Refer to the generated Javadoc files in '/Users/archie/bugs/guava-javadoc-bug.0/module/target/apidocs' dir.

To reproduce the bug, first verify you are using JDK 17. Then:

$ git clone [email protected]:archiecobbs/guava-javadoc-bug.git
$ cd guava-javadoc-bug
$ mvn

The problem goes away if you remove the <Automatic-Module-Name>${automatic.module.name}</Automatic-Module-Name> in the JAR plugin configuration.

[archiecobbs]

FYI, the version of Maven I'm using:

$ mvn --version
Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /opt/homebrew/Cellar/maven/3.9.4/libexec
Java version: 17.0.8.1, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "13.5.2", arch: "aarch64", family: "mac"

[cpovirk]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.3.0:enforce (enforce-java) on project guava-javadoc-bug: 
[ERROR] Rule 0: org.apache.maven.enforcer.rules.version.RequireJavaVersion failed with message:
[ERROR] Detected JDK version 11.0.20-1 (JAVA_HOME=/usr/local/buildtools/java/jdk11) is not in the allowed range [17,).

Thank you for that. I am not so good at following directions on the first try... :)

If this is Guava's fault, it's very likely my fault in one way or another. I'll poke around a little and see if anything jumps out to me.

[cpovirk]

<debug>true</debug> on the maven-javadoc-plugin configuration shows:

--module-path
'/usr/local/google/home/cpovirk/.m2/repository/com/google/errorprone/error_prone_annotations/2.21.1/error_prone_annotations-2.21.1.jar:/usr/local/google/home/cpovirk/.m2/repository/com/google/guava/guava/32.1.3-jre/guava-32.1.3-jre.jar:/usr/local/google/home/cpovirk/.m2/repository/org/checkerframework/checker-qual/3.37.0/checker-qual-3.37.0.jar:/tmp/tmp.2ZFSJIuik9/guava-javadoc-bug/module/target/guava-javadoc-bug-module-1.0.0.jar' 

InternalFutureFailureAccess is part of failureaccess, a dependency of Guava. That artifact isn't a part of the modulepath. I would hope that maven-javadoc-plugin automatically pulls in transitive dependencies normally, but just to be safe, I added:

        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>failureaccess</artifactId>
            <version>1.0.1</version>
        </dependency>

And I still saw the same error and the same modulepath.

So the problem may be that Guava isn't a real module (#2970) and thus doesn't declare its dependency on failureaccess. It's also possible that failureaccess itself would have to be made into a proper module (or perhaps just acquire an Automatic-Module-Name, since it doesn't have deps).

...OK, I built and installed a failureaccess-1.0.2 locally with <Automatic-Module-Name>com.google.common.util.concurrent.internal</Automatic-Module-Name>, and the modulepath picked up failureaccess, and the error went away.

We were trying to release only one version of failureaccess ever, but obviously we failed at that once already. I think that a change that doesn't touch any .class files should be fine, but I'll probably hold off until I have a moment to think about this a little more deeply.

(Thanks for the report!)

[archiecobbs]

Wow, that's pretty subtle. Thanks for quickly figuring out what's going on.

[archiecobbs]

I'm curious though who is really to blame for this bug. Can this be considered a Maven bug?

• We have a project configured with some set of dependencies (whatever they are)
• The maven-compiler-plugin compiles them just fine
• The maven-javadoc-plugin fails

It seems like if you can compile something, you should also be able to javadoc it....

More support for this view: there doesn't seem to be any way to configure the maven-javadoc-plugin to workaround this problem - which means this failure can't be blamed on a mere misconfiguration.

Your thoughts?

[cpovirk]

You will not have to twist my arm too hard to get me to admit that Maven might have bugs :)

Speaking of which, I can't seem to get maven-compiler-plugin to output its command line to a file, even when I set debugFileName and fork and debug and verbose (the latter two of which sound unrelated, but just to be safe), whether I set that in the parent pom or the child... :) But the plugin prints more info when I pass -X, so I'll go with that.

Anyway, it looks like maven-compiler-plugin is passing -classpath, not --module-path.

I note your observation of "THIS SEEMS TO TRIGGER THE BUG" in your maven-jar-plugin config. My guess would that maven-javadoc-plugin looks at the jar (which of course maven-compiler-plugin can't because the jar doesn't exist at that point), sees the Automatic-Module-Name, and goes into "modules mode."

And oh, look at this: https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-707. I have only skimmed it, but it immediately seems very clearly related:

The next release of the javadoc plugin (3.6.0) will offer a new switch (legacyMode) which should make this work for you. please try with <legacyMode>true</legacyMode> either with the current snapshot or the next release.

(There's also a workaround given that could work today. It involves moving things to different phases. That seems like a shame.)

We could still try to give failureaccess a module name, since that's probably a good idea, anyway. But the problem you're seeing should go away if you're willing to set legacyMode on the new maven-javadoc-plugin release.

[archiecobbs]

Ah! Actually updating to 3.6.0 fixes the problem, even without legacyMode:

diff --git a/pom.xml b/pom.xml
index 7faae4a..72e3f56 100644
--- a/pom.xml
+++ b/pom.xml
@@ -21,6 +21,7 @@
         <java.version>17</java.version>
         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
         <guava.version>32.1.3-jre</guava.version>
+        <maven-javadoc-plugin.version>3.6.0</maven-javadoc-plugin.version>
     </properties>
 
     <!-- Versions for dependencies used by multiple modules -->

So maybe this is really just MJAVADOC-769.

[cpovirk]

The fix is now released as part of 33.0.0.

[archiecobbs]

Thanks!