JDK-8011800 : Add java.util.Objects.requireNonNull(T, Supplier)
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-04-09
  • Updated: 2017-05-17
  • Resolved: 2013-04-16
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.
8 b87Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
In JDK 7, java.util.Objects included several methods to check for null, including one that took a message to return if a null was found. With lambdas in JDK 8, another variant to include is a requireNonNull method which takes a string supplier instead of a string. That why the cost of creating the string message can be avoided for the non-null case. Note that the lambda capture can have a nonzero cost though.
SQE has looked at the bug and decided no additional tests are needed.

verified in b94

Core-libs review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015824.html

The non-zero capture cost does worry me. I am concerned that it will frequently erase any advantage of using a Supplier.