Objects.nonNull() (original) (raw)

Stephen Colebourne scolebourne at joda.org
Mon Jan 17 08:53:23 UTC 2011

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

More information about the core-libs-dev mailing list