JDK-8044047 : Missing null pointer checks for streams
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.stream
  • Affected Version: 8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: other
  • CPU: x86
  • Submitted: 2014-05-17
  • Updated: 2019-09-04
  • Resolved: 2014-07-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.
JDK 8 JDK 9 Other
8u221Fixed 9 b24Fixed openjdk8u212Fixed
Related Reports
Duplicate :  
JDK-8191648 - Typo in api/java/util/stream/BaseStream.html
Description
FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
There are couple of places where null checks are missing

(Int/Long/Double/)Stream.close
Int/Double/LongStream.flatmap
Int/Double/LongStream.collect(x,y, 3rd) 3rd argument not being checked


Also these methods does throw NPE but they consume the stream before throwing.
I like to think of null parameter checks as side-effect free.

Stream.forEach
Stream.forEachOrdered
Stream.sorted
Stream.toArray


REPRODUCIBILITY :
This bug can be reproduced always.
Comments
Fix Request This patch fixes the corner case in null handling in Stream API, as well as backports the tests that would be a base for upcoming testbug backports. Patch applies almost cleanly in 8u (there is one conflict in comment that removed double-word) and passes java/util/streams test.
27-02-2019
Missing null checks: Verified that calls to BaseStream.onClose, Int/Double/LongStream.flatmap, Int/Double/LongStream.collect(x,y, 3rd) do not but should throw NPE. NPEs: In general i am not sure we should enforce the constraint that the stream not be consumed if a parameter passed to an operation is incorrect and results in an NPE or say an IAE. It allows implementations to consolidate checking and avoid redundant checks. It's hard to concieve how client code would recover to meaningfully re-perform the operation. Note: for the case of Stream.forEach/Ordered there is an optimization that defers to the stream source spliterator if there are no intermediate operations, in this case the stream will be consumed before the NPE occurs, since the null check is performed by the Spliterator.forEachRemaining implementation.
02-07-2014