RFR 9: 8138963 : java.lang.Objects new method to default to non-null
Ivan Gerasimov
ivan.gerasimov at oracle.com
Thu Oct 8 16:13:23 UTC 2015
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
>>
>> -
>
>
More information about the core-libs-dev
mailing list