Currently, we require a supplier that returns a non-null string:
|
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"....
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
However, the resulting string is merely passed as an exception message, so
nullwould be fine as a result.The somewhat unfortunate thing is that the Java base type forces us to choose between
Supplier<String>andSupplier<@Nullable String>, at least in the absence of@PolyNull. (What we'd prefer is a base type ofSupplier<? extends String>, which we could then annotate asSupplier<? 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 explicitSupplier<@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 withSupplier<String>, in which case this change would break them, requiring them to change their own APIs or passsupplier::getas 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"....