RFR 9: 8138963 : java.lang.Objects new method to default to non-null (original) (raw)
Brian Goetz brian.goetz at oracle.com
Fri Oct 9 11:41:38 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 ]
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.
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 ]