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

[cpovirk]

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

jdk/src/java.base/share/classes/java/util/Objects.java

Line 357 in 457b292

public static <T> T requireNonNull( @Nullable T obj, Supplier<String> messageSupplier) {

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"....

[cpovirk]

The change works fine in the Google depot.

[wmdietl]

Do you see any code that is incorrect when using Supplier<String>?
It seems odd to go through the trouble of providing a supplier, just for it to return null. I see how it is more flexible, but are we encouraging better code with that flexibility?
I agree that using PolyNull would be nicest.

[cpovirk]

I'm not aware of any trouble from the Supplier<String> type. And actually, it turns out that the method has so few callers in our depot (ignoring third-party code) that I can look at them all. And they're all definitely fine—mostly things like String.format and string concatenation, as you'd expect.