RFR 9: 8138963 : java.lang.Objects new method to default to non-null

[Remi Forax]

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.Riggs at Oracle.com>
> À: "core-libs-dev" <core-libs-dev at 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
> >
> > -
> 
>