The semantics of require* here was that it should throw if the precondition is violated. That lead to a different naming direction than the current use case, in which null is an expected value rather than an error.
Sent from my iPhone > On Oct 9, 2015, at 11:58 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > >> On 9 October 2015 at 01:31, John Rose <john.r.r...@oracle.com> wrote: >> This leads me to yet another bikeshed color, FWIW: >> >> - T requireNonNull(T) (cf. Optional::get) >> - T requireNonNullElse(T,T) (cf. Optional::orElse) >> - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet) >> - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow) >> - T requireNonNull(T,String) (shorthand for common use of >> requireNonNullElseThrow) > > Note that there is already a new method in JDK 8 not listed above: > requireNonNull(T, Supplier<String>) > As such, I'm not convinced that requireNonNullElseThrow will pull its weight. > > I can see the benefits of this consistency of naming. (FWIW, I think > the "require" prefix was a mistake, but that ship has sailed). If this > naming is chosen, I'd like to see all the methods next to one another > in the source file, which involves moving the method added in JDK 8. > > Stephen
