Enable NullAway's JSpecify mode and fix resulting issues

[marcphilipp]

Overview

In order to check nullability annotations on generics in the build.

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[vlsi]

Does it really make sense to force all Invocation implementations to return @Nullable value?
Would it be better to keep an older Invocation<T extends @Nullable Object> approach so every implementation declares if it really wants to produce nullable value or not?

[vlsi]

In most of the cases, the proper signature for Function-receiving methods is as follows:

Suggested change

	public static LoggingListener forBiConsumer(BiConsumer<@Nullable Throwable, Supplier<String>> logger) {
	public static LoggingListener forBiConsumer(BiConsumer<? super @Nullable Throwable, ? super Supplier<String>> logger) {

That would allow users to pass even something that implements BiConsumer<@Nullable Object, @Nullable Object>.

Unfortunately, Java uses use-site variance, so effectively it requires users to add super and extends for almost every method that uses generic parameters.

[vlsi]

It does not sound right for invokeConstructor to return null. Does it mean the null signals the failure?

[marcphilipp]

@vlsi Thanks for your feedback! I have since talked to @sdeleuze who told me that NullAway's JSpecify mode currently only works properly with JDK 24 because some compiler fixes haven't yet been backported to JDK 21.

[marcphilipp]

Superseded by #4628