RFR 9: 8138963 : java.lang.Objects new method to default to non-null (original) (raw)

Daniel Fuchs daniel.fuchs at oracle.com
Fri Oct 9 12:22:28 UTC 2015

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

More information about the core-libs-dev mailing list