JDK-7012540 : java.util.Objects.nonNull() incorrectly named
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2011-01-14
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b130Fixed
Related Reports
Relates :  
JDK-8011800 - Add java.util.Objects.requireNonNull(T, Supplier)
Relates :  
JDK-6889858 - Add nonNull methods to java.util.Objects
Description
The class java.util.Objects is new for JDK 7.  Its mission is to provide "null-safe or null-tolerant versions of common operations on objects."  

The methods nonNull(x) have the behavior of throwing NPE if their argument is null, and returning their argument if non-null.  It is very common in Java source bases for a method named nonNull(x) to have the behavior of coercing their argument to null; that is, it is generally associated with a null-tolerant rather than a null-safe behavior.  

These methods should be renamed to something that makes its checking/verification behavior clear, while preserving the convenient self-return property so that it can be used in cases like:

  public void fooWrapper(String s, String t) {
      foo(checkNonNull(s), checkNonNull(t));
  }
Comments
EVALUATION There was some discussion on corelibs on the subject. While there were many competing suggestions, checkNonNull() seems to be a signficant improvement over the existing confusing nonNull().
14-01-2011