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

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Oct 8 18:37:41 UTC 2015


Hi Roger, 
my point was that for me, all theses forms are ambiguous thus not readable. 

> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Jeudi 8 Octobre 2015 16:44:54
> Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to
> non-null

> Hi Remi,

> On 10/8/2015 4:49 AM, Remi Forax wrote:

> > 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 first form compiled and threw the expected NPE at runtime.
I'm not sure you can say this is the expected result. Why the compiler doesn't call <T> T nonNullOf(T, T) and return () -> null as Supplier ? 

> In the second case, the () -> "" is a supplier<String> not a
> Supplier<Supplier<String>>.
> The compiler correctly produced a error.
Why the compiler doesn't select the method <T> T nonNullOf(T, T) instead, this version compiles ! 

and if you want more weirdness, what about ? 
Object o = Objects.nonNullOf"foo", null); 

> I don't think the method name will help the developer much and just makes the
> name longer
> for everyone else who is not producing a Supplier<Supplier<T>>.
maybe "nonNullOfGet" is a bad name, my point is that when you have several overloads like this, the result is not easy to predict (I suppose that people don't know by heart the chapter 15.12.2 of the JLS). 

[...] 

> Thanks, Roger
regards, 
Rémi 

> > 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 -
> > > 
> > 
> 



More information about the core-libs-dev mailing list