假设我有一个C类的对象c（来自库，因此我无法修改该类的定义），它扩展了Iterable。
在我的函数中，我想为用户提供一种处理R类型的对象流的方法，其中R类型的对象是通过对T类型的对象进行转换而获得的。
目前，我执行以下操作：
Stream<R> f(...) {
C c = ...;
return StreamSupport.stream(c.spliterator(), false)
.map(...);
}
之所以可以使用它，是因为分隔符是在Iterable类中默认实现的，但是javadoc表示出于性能原因，不建议使用默认实现。
如果用户只是想对其进行处理或应用流操作，我想返回一个流以不创建列表。
我对流的并行化属性不感兴趣，因为c中的对象只能以顺序方式读取。
因此，我想知道，如果有的话，推荐使用“干”来做这种事情。仅仅返回一个List或将使用者函数作为参数传递会更好吗？我有点担心javadoc建议不要使用默认的分隔符号。
使用上述方法，是否可以确保在基础Stream中保留元素出现的顺序？
最佳答案
该规范并不表示您不应该使用它。 It says：“通常应重写默认实现。”很明显，如果您不是类C的维护者，则不能对类C进行任何处理。但重要的一点是，使用C.spliterator()的方式不会阻止类C的维护者提供spliterator()的自定义实现，因此这没有任何问题。
毕竟，使用默认的spliterator()实现（如没有拆分功能）的缺点也适用于所有其他解决方案。您无法添加此类功能，只有C的维护者才能做到这一点。用这种方式构造的Stream不会比使用普通的Iterator表现更差，因为这正是默认实现在幕后使用的。但是使用Stream可以获取C.spliterator()将来实现的优势。
如果您知道C的特征或大小，则可以construct an optimized Spliterator，但这确实会干扰类C的未来发展，因此请谨慎使用。