RFR 9: 8138963 : java.lang.Objects new method to default to non-null (original) (raw)
Roger Riggs Roger.Riggs at Oracle.com
Thu Oct 8 21:42:29 UTC 2015
- Previous message: RFR 9: 8138963 : java.lang.Objects new method to default to non-null
- Next message: RFR 9: 8138963 : java.lang.Objects new method to default to non-null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 nonNullOf(T obj, T defaultObj); T nonNullOf(T, obj, Supplier 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) (cf. Optional::orElseGet) - nonNullElseThrow(T,Supplier) (cf. Optional::orElseThrow) — John
- Previous message: RFR 9: 8138963 : java.lang.Objects new method to default to non-null
- Next message: RFR 9: 8138963 : java.lang.Objects new method to default to non-null
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]