On Oct 8, 2015, at 12:34 PM, fo...@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.ri...@oracle.com <mailto:roger.ri...@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/~rriggs/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
