`requireNonNull(..., Supplier<@Nullable String> messageSupplier`?

Currently, we require a supplier that returns a non-null string:

https://github.com/jspecify/jdk/blob/457b29286178d19b73503b54c2b09461409b6deb/src/java.base/share/classes/java/util/Objects.java#L357

However, the resulting string is merely passed as an exception message, so null would be fine as a result.

The somewhat unfortunate thing is that the Java base type forces us to choose between Supplier<String> and Supplier<@Nullable String>, at least in the absence of @PolyNull. (What we'd prefer is a base type of Supplier<? extends String>, which we could then annotate as Supplier<? extends @Nullable String>.)

It's also a little sad that "Supplier<@Nullable String>" just looks more complicated in general. But then probably few people actually look at the stubs directly.

We could try Supplier<@Nullable String> and see if there's any fallout from callers who pass an explicit Supplier<@Nullable String>. My guess is that callers are using lambdas over anonymous classes, so they won't generally specify explicit types. But we might see cases in which people have declared their own APIs with Supplier<String>, in which case this change would break them, requiring them to change their own APIs or pass supplier::get as a way of translating (and setting off static analysis like https://errorprone.info/bugpattern/UnnecessaryMethodReference... :). I'll see what the Google results look like. If I see a lot of errors, I'm not sure if my conclusion will be "not worth the trouble" or "better fix this now before it gets harder"....

Start with src/java.base/share/classes/java/util/Objects.java at the linked requireNonNull overload and review the Supplier type annotation. Search for callers that explicitly declare Supplier or Supplier<@Nullable String>, then assess the compatibility fallout described in the issue. Done means reaching and documenting a decision on the nullable annotation change.