Objects.nonNull()

[Brian Goetz]

They are not, they are java.util.

On 1/13/2011 9:25 PM, Ben Manes wrote:
> Should these checks even be part of java.lang? It promotes creeping in
> many different assertion utility methods throughout the libraries. I
> personally prefer the more flexible Hamcrest style, e.g. assertThat(foo,
> is(not(nullValue()))), which allows extensibility through matchers.
> However, I wouldn't expect either style to be part of the core language.
>
> ------------------------------------------------------------------------
> *From:* Brian Goetz <brian.goetz at oracle.com>
> *To:* mark.reinhold at oracle.com
> *Cc:* core-libs-dev at openjdk.java.net
> *Sent:* Thu, January 13, 2011 4:52:27 PM
> *Subject:* Re: Objects.nonNull()
>
>  > I'm still troubled by the "check" prefix, though. It implies that the
>  > named condition will be tested but it doesn't clearly relate the result
>  > of that test to the method's exception-throwing behavior.
>  >
>  > Here's an idea: Why not treat this as a (degenerate) kind of conversion
>  > operation? Call it asNonNull(x) -- it (trivially) converts its argument
>  > to a non-null value, and if it can't then it throws an NPE.
>  >
>  > public Moo fooWrapper(String x, String y) {
>  > return foo(asNonNull(x), asNonNull(y));
>  > }
>  >
>  > Of all the names we've considered, this looks the most natural to me.
>
> I would like to leave room in the namespace to support both of these use
> cases:
> - I expect non-null, and if I'm wrong, fail
> - I expect non-null, and if I'm wrong, sweep it under the rug
>
> The motivation for this change is that we're currently grabbing
> nonNull(x) for one of them, using a name that is more suitable to the other.
>
> asNonNull(x) sounds like the latter to me, since asXxx suggests a
> conversion. I'm totally fine with that as the name for the
> carpet-sweeping version.
>
> Note that these are the only methods in Objects that throw anything --
> the rest of the methods in Object are more of the carpet-sweeping
> variety. So the name should definitely reflect that these are
> assertions/checks/verifications/preconditions.
>
> Someone suggested assertNonNull(x), and while that sort of captures the
> intent, people expect assertXxx methods to throw AssertionError, and it
> still may surprise the user on what it does in the common case.
>
> I suppose ifNonNull() is a possible choice, though it begs the question
> "where is the else clause"?
>
> Unfortunately brevity is somewhat important here because people will use
> this inline, such as in the fooWrapper case, which suggest that
> something is going to be left unspecified no matter how we slice.
>
> I'm still liking checkNonNull, mostly because I haven't seen something
> better yet. (But nearly all the options are better than the status quo.)
>
>