Hi Roger, using overloads here seems to be a bad idea, as a nice puzzler, what does the compiler do for these two lines of code Supplier<String> supplier = Objects.nonNullOf(null, () -> null); Supplier<String> supplier2 = Objects.nonNullOf(null, () -> "");
The other issue is that defaultSupplier should allow covariant Supplier, the signature should be: <T> T nonNullOfGet(T obj, Supplier<? extends T> defaultSupplier) otherwise apart form the remark of Stephen, the code is Ok. cheers, Rémi ----- Mail original ----- > De: "Roger Riggs" <roger.ri...@oracle.com> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Jeudi 8 Octobre 2015 00:24:26 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > non-null > > Hi, > > The original intent was to simplify the filling in of default values > (even if null). > I took Remi's point about the canonical coalescing operator not always > returning non-null > but the push seems to be in the direction of making sure the result is > always non-null. > I'd rather add a few very useful methods and avoid those with > diminishing returns. > > I note that nulls are discovered eventually, but doing more aggressive > checking is preferred. > I expect the compiler is able to squeeze out all the extra checks. > > In the current context of Objects that the jdk, I read the naming > pattern of firstNonNull to imply > access to some sequential data structure like an array or list; but it > doesn't gel with me to apply it to the arg list > (unless it was varargs). The pattern of naming us "of" as being > factory producing an object > from the arguments seems apropos and is concise. > > Please consider and comment: > > <T> T nonNullOf(T obj, T defaultObj); > <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > > Regards, Roger > > > On 10/6/2015 6:42 PM, Remi Forax wrote: > > Null coalescing is a popular operator in several languages [1] and the > > usual semantics is nullOrElse and not firstNonNull. > > In languages like Kotlin or Swift, because there is a distinction between > > Object and Object?, it's not a big deal, you can not de-reference null by > > error, anyway. > > > > Also note that nullOrElseGet, the one that takes a supplier also exists in > > Groovy and Kotlin under the name null safe navigation. > > > > So even if i prefer the semantics of firstNonNull, i think we should also > > include both nullOrElse and nullOrElseGet. > > > > regards, > > Rémi > > > > [1] https://en.wikipedia.org/wiki/Null_coalescing_operator > > > > - > >
