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

[Roger Riggs]

Hi Ivan,

It was there, for compile time, to confirm the type signature of the 
return value;
the type checking on == isn't as strong as assignment.
But it would not be needed more than once.

Roger



On 10/8/2015 12:13 PM, Ivan Gerasimov wrote:
> Hi Roger!
>
> In the test, why the 'result' variable is needed?
>
>  242         String result;
>  243         errors += (result = Objects.nonNullOf(nullString, 
> defString)) == defString ? 0 : 1;
>  244         errors += (result = Objects.nonNullOf(nonNullString, 
> defString)) == nonNullString ? 0 : 1;
>  245         errors += (result = Objects.nonNullOf(nonNullString, 
> null)) == nonNullString ? 0 : 1;
>
> I don't see its value being used anywhere.
>
> Sincerely yours,
> Ivan
>
> On 08.10.2015 1:24, Roger Riggs wrote:
>> 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
>>>
>>> -
>>
>>
>