RFR 9: 8138963 : java.lang.Objects new method to default to non-null (original) (raw)
Roger Riggs Roger.Riggs at Oracle.com
Fri Oct 9 15:46:09 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,
The primary purpose of the existing 'requireNonNull' methods is to check for null and throw an exception. It is used for explicit testing and producing a cogent exception. Returning the value was a secondary benefit that allowed it to be used in fluent expressions.
The purpose of the new methods is to provide a default value (non-null); throwing an exception is secondary. This is consistent with the behavior and intent of the Optional methods.
So, I think using the more concise naming consistent with Optional is preferred because it is more readable and usable.
New Methods:
- T nonNullElse(T,T) (cf. Optional::orElse)
- T nonNullElseGet(T,Supplier) (cf. Optional::orElseGet)
The existing methods cover the cases for checking and throwing exceptions.
- T requireNonNull(T) (cf. Optional::get)
- T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow)
Except for throwing some exception other than NPE, which is included in Optional.orElseThrow
- T requireNonNullElseThrow(T,Supplier) (cf. Optional::orElseThrow)
Combines two different purposes and I don't think it pulls it own weight in the Objects case. More general would be T requireNonNullThrow(T, Supplier). (not proposed)
Roger
webrev: http://cr.openjdk.java.net/~rriggs//webrev-object-non-null
On 10/9/2015 8:22 AM, Daniel Fuchs wrote:
Hi Brian,
On 09/10/15 13:41, Brian Goetz wrote: The semantics of require* here was that it should throw if the precondition is violated. That lead to a different naming direction than the current use case, in which null is an expected value rather than an error. Not necessarily - as the requireNonNull*(x, y) will throw if the resulting value would be null: the method either returns non-null or throws... In other words it throws if the postcondition is violated (which the existing require* method also do, since for those precondition and postcondition are the same). best regards, -- daniel
Sent from my iPhone On Oct 9, 2015, at 11:58 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
On 9 October 2015 at 01:31, John Rose <john.r.rose at oracle.com> wrote: This leads me to yet another bikeshed color, FWIW:
- T requireNonNull(T) (cf. Optional::get) - T requireNonNullElse(T,T) (cf. Optional::orElse) - T requireNonNullElseGet(T,Supplier) (cf. Optional::orElseGet) - T requireNonNullElseThrow(T,Supplier) (cf. Optional::orElseThrow) - T requireNonNull(T,String) (shorthand for common use of requireNonNullElseThrow) Note that there is already a new method in JDK 8 not listed above: requireNonNull(T, Supplier) As such, I'm not convinced that requireNonNullElseThrow will pull its weight. I can see the benefits of this consistency of naming. (FWIW, I think the "require" prefix was a mistake, but that ship has sailed). If this naming is chosen, I'd like to see all the methods next to one another in the source file, which involves moving the method added in JDK 8. Stephen
- 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 ]