Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) (original) (raw)

Paul Benedict pbenedict at apache.org
Wed Jan 26 15:44:05 UTC 2011

Alternatively, we could use the "as" prefix already established in the JDK -- since this function is a kind of conversion.

asNonNull(Object o, Object fallbackObj)

Paul

On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain <jeffhain at rocketmail.com> wrote:

Hello.

As Ulf said, I think "requireNonNull" could be the name of a method that just checks that the specified reference is not null, and would not return anything (even though we could rather use "checkNonNull" in that case, and make it return true if non null). Though, "notNullChecked" or "nonNullChecked" might seem to suppose that the non-nullity of the specified value has already being checked. A more appropriate name would be "checkNonNullAndReturnIt", but it's too verbose. I'm considering "beingNonNull" as an alternative, for "beingNonNull(x)" contains the idea that it is still "x", i.e. that it normally returns "x", and that it supposes "x" to be non null, i.e. that it checks it. Also, the passive form "being" contains the idea that we don't change anything to the value. An alternative to this alternative would be "notBeingNull", which would be more on pair with methods like "beingPrime"/"notBeingPrime" ("beingNonPrime" looking weird to me). Though, verbs in passive form in methods names might look strange to a lot of people. Regards, Jeff.

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110126/ba91f408/attachment.html>

More information about the core-libs-dev mailing list