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

[Paul Benedict]

Brian,

My implementation of asNonNull() is as follows: return (o != null) ? o :
fallbackObj.

That is a conversion that can succeed.

However, the conversation clearly has shown we need this (1) a null-safe
conversion method and (2) and a NPE-throwing check method. I was only
referring to the #1 and that's why I think "as" works here. For the latter,
I prefer "check" or "validate" to throw NPE when null is an error.

Paul

On Wed, Jan 26, 2011 at 9:48 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> This ground has been already covered.  "as", "to", etc, are fine for
> conversions -- but by definition this is a conversion will never succeed.
>  At the same time, we need to leave room in the namespace for a conversion
> operation that *will* succeed.  (If we didn't need both, this whole
> conversation would be moot!)  as/to/make are all fine for the
> "carpet-sweeping" version of this method, but that's not what's being
> discussed.
>
>
> On 1/26/2011 10:44 AM, Paul Benedict wrote:
>
>> 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
>> <mailto: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/3bfc9eed/attachment.html>