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

Stephen Colebourne scolebourne at joda.org
Tue Oct 6 14:15:01 UTC 2015


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