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 ----- Mail original ----- > De: "Stuart Marks" <stuart.ma...@oracle.com> > À: "Stephen Colebourne" <scolebou...@joda.org>, "core-libs-dev" > <core-libs-dev@openjdk.java.net>, "Roger Riggs" > <roger.ri...@oracle.com> > Envoyé: Mardi 6 Octobre 2015 19:03:34 > Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to > non-null > > I agree that with Stephen that Guava's semantics of disallowing a null > default > are preferable. It would seem very odd if a method that has "nonNull" in its > name is allowed to return null. > > It seems to me that the point of this and related methods is to provide a > fluent > way for a class to separate the nullable world outside with the non-nullable > world inside. Thus, > > void setValue(T arg) { // arg is nullable > field = Objects.firstNonNull(arg, DEFAULT_VALUE_FOR_FIELD); > assert field != null; > } > > If the default value can be null, why bother checking arg at all? It seems to > me > that it's a programming error if the default value is null, so this should be > checked. > > * * * > > As an aside I notice that Guava's Objects.firstNonNull() is deprecated, with > a > recommended replacement of MoreObjects.firstNonNull(). [1] The semantics are > the > same, though, as far as I can see. I'm curious as to what's going here, > though. > > [1] http://google.github.io/guava/releases/18.0/api/docs/ > > s'marks > > > > On 10/6/15 7:15 AM, Stephen Colebourne wrote: > > What the existing code does would seem to be irrelevant. What is > > important is deciding what the correct semantics should be for a core > > method on Objects. > > > > If there a desperate need for the webrev semantics, how about two methods? > > > > firstNonNull(a, b) - result must not be null > > firstOrElse(a, b) - result is null only is b is null > > > > (although I struggle to see much point in the latter) > > > > Stephen > > > > > > > > > > On 6 October 2015 at 15:09, Roger Riggs <roger.ri...@oracle.com> wrote: > >> Hi Stephen, > >> > >> Guava's firstNonNull is a useful semantic, but would not be a drop in > >> replacement for existing code which > >> would need to be examined for behavioral changes due to possibly throwing > >> an > >> exception. > >> So perhaps the nonNullorElse name would be more accurate. > >> > >> Thanks, Roger > >> > >> > >> > >> On 10/6/2015 10:00 AM, Stephen Colebourne wrote: > >>> > >>> Guava uses firstNonNull(a, b). It ensures that the result is never > >>> null, by checking that b is not null. > >>> I think the semantics of Guava's method is correct. I tend to think > >>> the method name isn't bad either. > >>> > >>> Calling it nonNull(Object,Object) clashes with the existing > >>> nonNull(Object) method. Those two have nothing much to do with each > >>> other. > >>> > >>> Stephen > >>> > >>> > >>> On 6 October 2015 at 14:43, Roger Riggs <roger.ri...@oracle.com> wrote: > >>>> > >>>> Java.lang.Objects contains a number of convenience methods to make it > >>>> easier > >>>> to handle references that are null. > >>>> For example, toString(obj, nullDefault), > >>>> > >>>> A new method is proposed to return the reference or a default value if > >>>> the > >>>> reference is null. > >>>> static <T> T nonNull(T obj, T nullDefault); > >>>> > >>>> Alternatives to the method name include > >>>> nonNullOrElse ( using the java.util.Optional name pattern) or > >>>> nonNullOrDefault > >>>> > >>>> Please review and comment. > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ > >>>> > >>>> Issue: > >>>> https://bugs.openjdk.java.net/browse/JDK-8138963 > >>>> > >>>> Thanks, Roger > >>>> > >> >
