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

Roger Riggs Roger.Riggs at Oracle.com
Thu Oct 8 21:42:29 UTC 2015


Hi John,

Thanks for the insight, I hope it will help cut down on the thrashing.

Isn't there a 4th form that throws missing?

There was quite a bit of support for a version the never returned null 
and threw an exception if the replacement was null.

Thanks, Roger


On 10/8/2015 5:26 PM, John Rose wrote:
> On Oct 8, 2015, at 12:34 PM, forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr> wrote:
>>
>> Anyway, in this case the problem is not just overloading, it is the 
>> mix of overloading and type inference as you said.
>
> Add type erasure to this cocktail, and it's perfect.
>
> My antennae go up when the erased types overlap.  When they do, 
> there's usually a sad story (with puzzlers) waiting to appear.
>
> On 7 October 2015 at 23:24, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>> 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/ 
>> <http://cr.openjdk.java.net/%7Erriggs/webrev-object-non-null/>
>
> In this case, the erased types are Object(Object, Object) and 
> Object(Object, Supplier).
>
> So the source language (usually) makes all needed distinctions, but 
> the bytecodes are full of ambiguity.  And nulls are wonderful carriers 
> of ambiguity, at both source and bytecode levels.
>
> Please align this API point with the closely analogous points already 
> found in java.util.Optional.  In particular, a third throwing form 
> looks right.
>
> Those are my substantive comments.
>
> Now for bikeshed comments.
>
> I don't like "Of" here, which doesn't appear in Optional, and seems to 
> be used more frequently for factory methods.
>
> I suggest using Optional::orElse* method names, but kill leading noise 
> word "or".  "Non-null else foo" is good programmer talk for "non-null 
> or else foo".  (Speculation:  The "or" is present in Optional mainly 
> to avoid reserved word "else".)
>
>  - nonNullElse(T,T) (cf. Optional::orElse)
>  - nonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet)
>  - nonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow)
>
> — John




More information about the core-libs-dev mailing list