RFR 9: 8138963 : java.lang.Objects new method to default to non-null

John Rose john.r.rose at oracle.com
Sat Oct 31 07:01:03 UTC 2015


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