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

Louis Wasserman lowasser at google.com
Tue Oct 6 17:09:01 UTC 2015


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

Guava is moving from Objects to MoreObjects because the JDK added an
Objects class, and Guava wanted to avoid naming conflicts with the JDK.

On Tue, Oct 6, 2015 at 10:03 AM Stuart Marks <stuart.marks at oracle.com>
wrote:

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