My point, and Daniel's point, is that requireNonNull can be re-interpreted (ret-conned) as enforcing a post-condition instead of a pre-condition. (The logic of JDK 8 rNN allows either view equally.) Then all of these API points hang together very nicely.
After I tinkered with the cross-simulation to Optional this insight just fell out of the equations: It's a rare case of Math improving English. Roger, it's a judgement call, but I don't think the API points differ as much as you say they do. — John On Oct 9, 2015, at 4:41 AM, Brian Goetz <brian.go...@oracle.com> wrote: > > 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
