Encountering NullArgumentForNonNullParameter when building testlib

[McDaMastR]

Hello,

I'm attempting to port Guava 33.7.1 to MacPorts (a package manager for macOS), but am unable to build the guava-testlib module. Attempting to do so results in several errors of the following form.

[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] /[...]/guava-33.7.1/guava-testlib/src/com/google/common/collect/testing/google/BiMapPutTester.java:[99,22] [NullArgumentForNonNullParameter] Null is not permitted for parameter 'key' of method 'forcePut'.
[ERROR]     (see https://errorprone.info/bugpattern/NullArgumentForNonNullParameter)
[...]
[ERROR] /[...]/guava-33.7.1/guava-testlib/src/com/google/common/collect/testing/google/MultimapAsMapGetTester.java:[76,46] [NullArgumentForNonNullParameter] Null is not permitted for parameter 'value' of method 'containsEntry'.
[ERROR]     (see https://errorprone.info/bugpattern/NullArgumentForNonNullParameter)
[...]
[ERROR] /[...]/guava-33.7.1/guava-testlib/src/com/google/common/testing/EquivalenceTester.java:[112,81] [NullArgumentForNonNullParameter] Null is not permitted for parameter 'a' of method 'equivalent'.
[ERROR]     (see https://errorprone.info/bugpattern/NullArgumentForNonNullParameter)
[INFO] 37 errors 

Any ideas on how these errors could be mitigated? I've done some research and think it may require modifications to the source code, which I certainly don't feel qualified to do given my unfamiliarity with the codebase.

Note that I have applied the following two patches on top of the v33.7.1 repo to solve other build issues. The first aims to allow the build process to use an already installed JDK rather than downloading one (MacPorts has ports for various JDK versions which can be depended on). And the second prevents Error Prone from halting the build with an error.

--- pom.xml.orig	2026-08-18 13:13:06
+++ pom.xml	2026-09-01 16:50:12
@@ -390,17 +390,10 @@
           <executions>
             <execution>
               <goals>
-                <goal>toolchain</goal>
+                <goal>select-jdk-toolchain</goal>
               </goals>
             </execution>
           </executions>
-          <configuration>
-            <toolchains>
-              <jdk>
-                <version>26</version>
-              </jdk>
-            </toolchains>
-          </configuration>
         </plugin>
         <plugin>
           <groupId>org.codehaus.mojo</groupId>

--- pom.xml.orig	2026-08-18 13:13:06
+++ pom.xml	2026-09-01 18:00:07
@@ -223,6 +223,8 @@
 
               <!-- https://errorprone.info/docs/installation#maven -->
               <arg>-Xplugin:ErrorProne -Xep:Java8ApiChecker:ERROR -XepDisableAllWarnings</arg>
+              <!-- https://github.com/google/error-prone/issues/5426 -->
+              <arg>-XDaddTypeAnnotationsToSymbol=true</arg>
               <!-- https://github.com/google/error-prone/blob/f8e33bc460be82ab22256a7ef8b979d7a2cacaba/docs/installation.md#jdk-16 -->
               <!-- TODO(cpovirk): Use .mvn/jvm.config instead (per
                    https://errorprone.info/docs/installation#maven). -->

The build command itself is as follows.

% cd /[...]/guava-33.7.1
% mvn3 package -Dmaven.repo.local=/[...]/guava-33.7.1/.m2/repository -DskipTests --define maven.javadoc.skip --define toolchain.jdk.version="[11,)" --define toolchain.skip --projects !guava-tests

And here's some likely relevant version info.

% javac -version
javac 21.0.8

% java -version
java version "21.0.8" 2025-07-15 LTS
Java(TM) SE Runtime Environment (build 21.0.8+12-LTS-250)
Java HotSpot(TM) 64-Bit Server VM (build 21.0.8+12-LTS-250, mixed mode, sharing)

% mvn3 --version
Apache Maven 3.9.16 (2bdd9fddda4b155ebf8000e807eb73fd829a51d5)
Maven home: /opt/local/share/java/maven3
Java version: 21.0.8, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home
Default locale: en_AU, platform encoding: UTF-8
OS name: "mac os x", version: "26.6.2", arch: "aarch64", family: "mac"

% uname -a
Darwin McDaAir.local 25.6.0 Darwin Kernel Version 25.6.0: Fri Jul 31 19:18:29 PDT 2026; root:xnu-12377.161.14~5/RELEASE_ARM64_T8122 arm64

Let me know if any further information is needed. And thanks for your time!

[cpovirk]

Hi, thanks for all the info!

My best guess is that, while your default javac for version 21 is 21.0.8, Maven is pulling a Java 21 that it knows about, one that is older than 21.0.8 and thus doesn't do anything for -XDaddTypeAnnotationsToSymbol=true.

On the Linux side, at least, the list of JDKs that Maven knows about is in ~/.m2/toolchains.xml. Can you look at the options for version 21 there and then judge from the jdkHome values (or ideally from actually running javac -version for the binary in those directories, as you've done for the default) whether any of the options are too old? (I'm not sure how Maven breaks ties if it sees multiple JDKs at version 21.) If it's finding one that's too old, you might be able to replace it with an entry that points to the version that you want. Or you might be able to remove maven-toolchains-plugin entirely so that Maven might fall back to your system default javac. Or, if you can find a JDK23 or higher, then using that should just work (even without -XDaddTypeAnnotationsToSymbol=true)—though you'd still need to find a way to get Maven to detect it.

Alternatively, if you want to just cut the knot, you could add -Xep:NullArgumentForNonNullParameter:OFF to the existing arg line.

I should warn after all that that, Error Prone aside, we aren't necessarily going to keep Guava buildable with Java 21 or any other particular version. For example, we've been considering releasing a separate class of Gatherer implementations, which would require building against 24+ (though it would still use -source 8 -target 8). For your purposes, that might just mean that you need another patch. But I'll keep this in mind so that, if we hear of other trouble, I have a more complete picture of whether we should try to make our build offer configuration to make it more accommodating.

[McDaMastR]

Thanks for the reply!

My best guess is that, while your default javac for version 21 is 21.0.8, Maven is pulling a Java 21 that it knows about, one that is older than 21.0.8 and thus doesn't do anything for -XDaddTypeAnnotationsToSymbol=true.

As far as I'm aware, I currently have only one JDK installed on my system (that being JDK 21.0.8). If there's another one, I can't seem to find it.

On the Linux side, at least, the list of JDKs that Maven knows about is in ~/.m2/toolchains.xml. Can you look at the options for version 21 there and then judge from the jdkHome values (or ideally from actually running javac -version for the binary in those directories, as you've done for the default) whether any of the options are too old?

I'm afraid I don't have the ~/.m2/toolchains.xml file. However, I do have a ~/.m2/discovered-jdk-toolchains-cache.xml file, whose contents are as follows.

<?xml version="1.0" encoding="UTF-8"?>
<toolchains xsi:schemaLocation="http://maven.apache.org/TOOLCHAINS/1.1.0 https://maven.apache.org/xsd/toolchains-1.1.0.xsd" xmlns="http://maven.apache.org/TOOLCHAINS/1.1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <toolchain>
    <type>jdk</type>
    <provides>
      <lts>true</lts>
      <runtime.name>Java(TM) SE Runtime Environment</runtime.name>
      <version>21.0.8</version>
      <vendor>Oracle Corporation</vendor>
      <runtime.version>21.0.8+12-LTS-250</runtime.version>
    </provides>
    <configuration>
      <jdkHome>/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

Which I think means maven could only find JDK 21.0.8.

Alternatively, if you want to just cut the knot, you could add -Xep:NullArgumentForNonNullParameter:OFF to the existing arg line.

That did work to curb those errors, though it introduced some more. It first resulted in the following.

[ERROR] Failed to execute goal on project guava-gwt: Could not resolve dependencies for project com.google.guava:guava-gwt:jar:33.7.1-jre
[ERROR] dependency: com.google.guava:guava-tests:jar:tests:33.7.1-jre (test)
[ERROR] 	Could not find artifact com.google.guava:guava-tests:jar:tests:33.7.1-jre in central (https://repo.maven.apache.org/maven2)

Which I assume means I cannot skip building the unit tests. So after removing --projects !guava-tests from the build command, I was met with the following.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.15.0:testCompile (default-testCompile) on project guava-tests: Compilation failure: Compilation failure: 
[ERROR] /opt/local/var/macports/build/google-guava-7aef0f03/work/guava-33.7.1/guava-tests/test/com/google/common/util/concurrent/AbstractFutureTest.java:[51,26] package java.lang.classfile does not exist
[ERROR] /opt/local/var/macports/build/google-guava-7aef0f03/work/guava-33.7.1/guava-tests/test/com/google/common/util/concurrent/AbstractFutureTest.java:[52,26] package java.lang.classfile does not exist
[ERROR] /opt/local/var/macports/build/google-guava-7aef0f03/work/guava-33.7.1/guava-tests/test/com/google/common/util/concurrent/AbstractFutureTest.java:[53,26] package java.lang.classfile does not exist
[ERROR] /opt/local/var/macports/build/google-guava-7aef0f03/work/guava-33.7.1/guava-tests/test/com/google/common/util/concurrent/AbstractFutureTest.java:[111,6] cannot find symbol
[ERROR]   symbol:   class ClassModel
[ERROR]   location: class AbstractFutureTest
[ERROR] /opt/local/var/macports/build/google-guava-7aef0f03/work/guava-33.7.1/guava-tests/test/com/google/common/util/concurrent/AbstractFutureTest.java:[111,30] cannot find symbol
[ERROR]   symbol:   variable ClassFile
[ERROR]   location: class AbstractFutureTest
[ERROR] /opt/local/var/macports/build/google-guava-7aef0f03/work/guava-33.7.1/guava-tests/test/com/google/common/util/concurrent/AbstractFutureTest.java:[113,11] cannot find symbol
[ERROR]   symbol:   class MethodModel
[ERROR]   location: class AbstractFutureTest

So after looking up java.lang.classfile, it appears the unit tests already require JDK 24+ to build. Does that sound right? I'll install JDK 25 soon and try to build with it to see if that's the problem here.

I should warn after all that that, Error Prone aside, we aren't necessarily going to keep Guava buildable with Java 21 or any other particular version. For example, we've been considering releasing a separate class of Gatherer implementations, which would require building against 24+ (though it would still use -source 8 -target 8). For your purposes, that might just mean that you need another patch.

That's good to know. As long as the minimum JDK is at most the latest LTS, I can simply add a dependency on the latest LTS JDK. It'll likely restrict the set of supported macOS systems, but I can attempt to patch later if that becomes a problem. It's if the minimum JDK is above any LTS version when things might get inconvenient for porting.

But I'll keep this in mind so that, if we hear of other trouble, I have a more complete picture of whether we should try to make our build offer configuration to make it more accommodating.

Sounds good :)

[McDaMastR]

I'll install JDK 25 soon and try to build with it to see if that's the problem here.

To follow-up, I've installed JDK 25 and the issues relating to Error Prone are no longer coming up. So that was likely an issue with using specifically JDK 21.0.8 to build Guava. I've thus removed the second patch from the build.

That said, there is now a new dependency error when building guava-gwt.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.11.0:unpack-dependencies (unpack-failureaccess-sources) on project guava-gwt: Execution unpack-failureaccess-sources of goal org.apache.maven.plugins:maven-dependency-plugin:3.11.0:unpack-dependencies failed: Plugin org.apache.maven.plugins:maven-dependency-plugin:3.11.0 or one of its dependencies could not be resolved:
[ERROR] 	Could not find artifact com.google.guava:guava-tests:jar:test-sources:33.7.1-jre in central (https://repo.maven.apache.org/maven2)

I interpret this error as maven failing to find the *.jar files built by guava-tests. Which is puzzling since they were definitely built; they can be seen in the corresponding target directory.

% ls -lhp /[...]/guava-33.7.1/guava-tests/target
total 9456
drwxr-xr-x  3 macports  wheel    96B  2 Sep 15:08 classes/
drwxr-xr-x  3 macports  wheel    96B  2 Sep 15:08 generated-test-sources/
-rw-r--r--  1 macports  wheel   6.0K  2 Sep 15:08 guava-tests-33.7.1-jre-sources.jar
-rw-r--r--  1 macports  wheel   4.6M  2 Sep 15:08 guava-tests-33.7.1-jre-tests.jar
-rw-r--r--  1 macports  wheel   6.0K  2 Sep 15:08 guava-tests-33.7.1-jre.jar
drwxr-xr-x  3 macports  wheel    96B  2 Sep 15:08 maven-archiver/
drwxr-xr-x  3 macports  wheel    96B  2 Sep 15:08 maven-status/
drwxr-xr-x  3 macports  wheel    96B  2 Sep 15:08 test-classes/

I'll be continuing to look into this, but please let me know if you have any ideas.

[cpovirk]

So much for my theory about toolchain discovery. I am stumped there. Maybe JDK releases are numbered a bit differently for Mac, but that doesn't sound likely.

And yes, sorry: We did already add a test that requires 24+. (I should have remembered that, since it was only Monday that I simplified our internal build setup for it to reflect that we made Java 25 our default a couple months ago... :)) We could arrange easily to run that internally only if it were to turn out to be the blocker for you, but it sounds like you've found a way around.

Your point about the LTS also makes sense. I can still imagine worlds in which we want to build with an STS, like to implement new default methods somewhere, but that seems at least less likely to come up. For more "normal" new features in an STS release, there will probably be even less reason to rush them into our open-source release. (But now that I've said that, I'm sure that someone from Bazel or something will come knocking with something that they really need :))

As for skipping the unit tests: Yes, sadly, the GWT build depends on the tests. We could probably arrange to isolate that dependency to a new, separate guava-gwt-tests project, at which point plain guava-gwt could compile without guava-tests. Granted, we are trying to keep guava-gwt alive without spending too much effort, so I'm not exactly excited by that prospect, but we could probably get AI to do most of it if that were to keep looking like a blocker.

That said, maybe you can get away with skipping guava-gwt, too? It's nice to provide what you can, but I don't know that I've come across another package manager that provides it (even those that provide plain guava).

Still, for the latest GWT issue: You may need to use install instead of package. (It is highly possible that the need for that means that we are Doing It Wrong. I think we were under the impression that Maven's cross-module dependencies didn't give us better options once upon a time. But we may have been mistaken, or Maven may have since grown some features that would help.)

[cpovirk]

(Possibly Oracle JDKs don't support -XDaddTypeAnnotationsToSymbol=true?)

[McDaMastR]

And yes, sorry: We did already add a test that requires 24+. (I should have remembered that, since it was only Monday that I simplified our internal build setup for it to reflect that we made Java 25 our default a couple months ago... :)) We could arrange easily to run that internally only if it were to turn out to be the blocker for you, but it sounds like you've found a way around.

That's all good; just depending on a newer JDK works for now.

As for skipping the unit tests: Yes, sadly, the GWT build depends on the tests. We could probably arrange to isolate that dependency to a new, separate guava-gwt-tests project, at which point plain guava-gwt could compile without guava-tests. Granted, we are trying to keep guava-gwt alive without spending too much effort, so I'm not exactly excited by that prospect, but we could probably get AI to do most of it if that were to keep looking like a blocker.

It's no big deal to compile the unit tests. I wanted to skip them mainly to save time since they're usually not necessary when upstream performs regular testing. But as long as nothing else comes up, there shouldn't be any issues with including them in the build. So don't worry about separating the two test sets.

That said, maybe you can get away with skipping guava-gwt, too? It's nice to provide what you can, but I don't know that I've come across another package manager that provides it (even those that provide plain guava).

Interesting. In that case, I think I will make guava-gwt an optional opt-in part of the port. That way, I can require JDK 22+ for the base build and JDK 24+ for the base + guava-gwt build. Which I can adjust per Guava release.

Still, for the latest GWT issue: You may need to use install instead of package. (It is highly possible that the need for that means that we are Doing It Wrong. I think we were under the impression that Maven's cross-module dependencies didn't give us better options once upon a time. But we may have been mistaken, or Maven may have since grown some features that would help.)

Indeed, that solved the issue. Though I agree that sounds like a bug with Guava's build system. Should I open a separate issue for that?

(Possibly Oracle JDKs don't support -XDaddTypeAnnotationsToSymbol=true?)

That could be it. Though I will note that without -XDaddTypeAnnotationsToSymbol=true on my JDK 21.0.8, I recall the build did fail a lot faster with an error telling me to use that option, which means it at least did something.

All that said, the build now appears to be successful both with and without guava-gwt, so I'll close this issue now. Many thanks for the help!

[cpovirk]

Still, for the latest GWT issue: You may need to use install instead of package. (It is highly possible that the need for that means that we are Doing It Wrong. I think we were under the impression that Maven's cross-module dependencies didn't give us better options once upon a time. But we may have been mistaken, or Maven may have since grown some features that would help.)

Indeed, that solved the issue. Though I agree that sounds like a bug with Guava's build system. Should I open a separate issue for that?

I think I have a fix: #8659

As it says, it fixes mvn package, though not mvn compile.

If you or someone else wants to file an issue about mvn compile, feel free :) It looks not completely trivial.