Objects.nonNull()

[Stephen Colebourne]

On 17 January 2011 05:26, Brian Goetz <brian.goetz at oracle.com> wrote:
>> My aversion to checkNonNull naming pattern comes from experience.  Long,
>> long ago in a code base far, far away I wrote a big set of unit tests
>> using this pattern.  Coming back to it months later I had to read the
>> code very closely and keep reminding myself that the checkFoo procedures
>> were ensuring the Foo condition rather ensuring nonFoo.

I generally use the 'check' prefix for methods that return a boolean.

> I see your point now.  Perhaps you'd prefer requireNonNull() for the
> throwing version?
>
>  public void fooWrapper(String s, String t) {
>     foo(requireNonNull(s), requireNonNull(t));
>  }

Both 'require' and 'ensure' are possible, with 'require' being
slightly better in the fluent pattern. However...

> I get your point about maybe we should just remove this, but I do think that
> a method that acts on all object references ignorant of the reference type,
> fits within the mission of juO.

You should definitely remove this now!! Its too late in the release
cycle to be adding a risky method like this one (which to my eyes is
unsuited to the style of the core JDK) whatever you call it.
Especially when many of us really want a
Validate/Preconditions/Assert/ArgChecker class, not this method (I
have used Validate/Preconditions/Assert/ArgChecker to check every
public methods arguments in large codebases for the last 10 years -
its a vital class!)

Stephen