Hi Stephen, see comments below ----- Mail original ----- > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Dimanche 1 Novembre 2015 22:46:21 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > non-null > > On 31 October 2015 at 20:29, Roger Riggs <roger.ri...@oracle.com> wrote: > > And, going back nearly to the beginning of the thread, some folks are > > familiar with > > > > T firstNonNull(T, T) proposed from Guava. > > > > But since the exercise was turned into simplify: (x != null) ? x : > > requireNonNull(y); > > > > My favorite at this point is to identify the thread as a failed attempt and > > remove it. > > That would be a mistake. This is a classic simple method that the JDK > should have (given that the Elvis operator was rejected). > > John's proposal is by far the best in the thread for consistency, even > if it is long (and the long-ness mistake is the fault of the previous > JDK release). > > Thus, we should have > > - T requireNonNull(T) - exists already > - T requireNonNull(T,String) - exists already > - T requireNonNull(T,Supplier<String>) - exists already > - T requireNonNullElse(T,T) - new > > I have no great need for either of these two, although I understand > the rationale: > > - T requireNonNullElseGet(T,Supplier<T>) > - T requireNonNullElseThrow(T,Supplier<X>) > > The "require is a precondition" debate is a red herring IMO. These > methods easily make a set that check for null and "do something". > "requireNonNullElse" requires that the first argument is non-null, > just like the other three, its just that it does something softer if > it is.
I disagree. The problem with using the prefix 'require', is that the proposed methods do not 'require' something, they make sure that the result is not null. What about using the prefix 'ensure' ? public static <T> T ensureNonNull(T obj, T defaultObj); public static <T> T ensureNonNullGet(T obj, Supplier<? extends T> supplier); I know that this comment can be seen as bikeshedding again, but i think the distinction between the two semantics requireNonNull/ensureNonNull is important. requireNonNull is an precondition test, something you do upfront, it is used to avoid to *store* null in a field of a local variable, ensureNonNull is something you use when it's too late, practically some calls may return null so you have to do something, it's used to avoid to *load* null. Obvisously, given that programs do more loads that stores, it's better to avoid to store null that to try to fix the null problem after. It's part of the Java API culture, in Java, methods do null checks or range checks upfront. For the record, during a lambda EG meeting, Josh Blosch summarizes that idea by the sentence 'blow early blow often', which i think is a nice Java mantra. > > Thus, I'd recommend adding "requireNonNullElse(T,T)" alone, and move on. > > Stephen > Rémi
