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

Remi Forax forax at univ-mlv.fr
Sat Oct 31 11:17:18 UTC 2015

Hi John, I think there is a good reason to not reuse/enhance the requireNonNull prefix, requireNonNull here is used to check a precondition or an invariant (a contract), hence a name that starts with 'require' like in Eiffel. (BTW re-reading this thread, Brian already said that)

requireNonNullElseGet is not something that checks a contract and as you said, nonNull is not a good prefix too, so we should starts a new family.

what about: T coalesceNull(T, T) T coalesceNullGet(T, Supplier<? extends T>)

cheers, Rémi

PS: COALESCE is already use as an operator in SQL with the same semantics.

----- Mail original -----

De: "John Rose" <john.r.rose at oracle.com> À: "Roger Riggs" <roger.riggs at oracle.com> Cc: core-libs-dev at openjdk.java.net Envoyé: Samedi 31 Octobre 2015 08:01:03 Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 30, 2015, at 12:07 PM, Roger Riggs <roger.riggs at oracle.com> wrote: > > The longer names disambiguate adequately but add to the bulk of the code. > I see maturing systems end up being weighed down by the seemingly necessary > qualification. I agree with your statement of the problem, but (personally) am less repulsed by long names. The name length is unusual (up to "requireNonNullElseGet", if that's the new API spelling). It would be inconvenient to write manually but (IMO) that isn't a deal-killer. Coders cope with long names (check class name lengths in java.lang). It's a matter of taste, and (particularly) of how much the coder relies on name-completion commands. Given the pre-existing methods in the "nonNull" family and the "requireNonNull" family, it is tricky to fit in the new API points with either prefix. The "nonNull" family is short and sweet, but was adopted (one might say "stolen") for use as a predicate (sans "is"-prefix). The "requireNonNull" family was long-winded, even before we thought about adding "ElseGet". (How did we settle on "require", anyway?) > So in face of the tradeoffs, what were you proposing again?

Despite the length of the names involved, I'm going to clutch at my IDE and my Control-Space key, maintaining my preference for the consistency of requireNonNull* over the brevity (but inconsistency) of notNull*. As I said, I noticed the problem with "notNullElse" while using an IDE. Non-IDE users would look at my preference and say, "please, not so many keystrokes!" In the IDE, I would prefer to pretend "notNull" never happened, and type "require" and Control-Space, and then select one of the old or new API points to refine my null-checking logic. — John P.S. Going for a third way and starting a new family of methods ("notNull*", "stopNull", etc.) would make me sad too, since we already have null-stopping API points. I'd secretly welcome Objects.or(a, b, c), etc. (coupled with "require*" to throw NPEs), but only because "OR" is a sort of logical in-joke for ex-Lispers.

More information about the core-libs-dev mailing list