On Sat, 14 Aug 2021 15:13:39 GMT, Brian Goetz <briango...@openjdk.org> wrote:
> I object to this change. These issues were explored in the JSR 335 EG and it > was agreed that this abstraction did not carry its weight. In any case, it is > premature to bring a PR for a significant API change that has not been > discussed first on corelibs-dev. Please withdraw the PR, and if you want to > continue the discussion, bring it to corelibs-dev. I agree with the spliterator performance issues and the ability to be able to create IntStreams from Iterable<Integer>. Therefore option 1 and 2 from JDK-8272137 seem fairly unfeasible to implement. This was already hinted at there, but for different reasons. This PR however implements option 4: an option that doesn't actually make the Iterable class have a stream method, but instead abstracts the stream method to an interface. This method is then implemented by Collection and Optional. It also allows other code to implement this interface. Using this implementation, you don't have the issues that the JSR 335 EG specified that would be present if Iterable itself were to be made Streamable. You wouldn't want that anyway, because streamability and iterability are two similar but very separate concerns in Java. ------------- PR: https://git.openjdk.java.net/jdk/pull/5050
