RFR 9: 8138963 : java.lang.Objects new method to default to non-null (original) (raw)

Remi Forax forax at univ-mlv.fr
Tue Oct 6 22:42:18 UTC 2015

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.marks at oracle.com> À: "Stephen Colebourne" <scolebourne at joda.org>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Roger Riggs" <Roger.Riggs at 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, DEFAULTVALUEFORFIELD); 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.Riggs at 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.Riggs at 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 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 >>>> >>

More information about the core-libs-dev mailing list