为何不引入通用Streamable接口？该方案是否存在弊端？

我们知道Collection和Optional都自带stream()方法，在执行flatMap操作时必须手动调用这个方法才能将它们转换为流，比如原代码要这么写：

myStream.flatMap(obj -> obj.getCollection().stream())
// 或者
myStream.map(MyObject::getCollection).flatMap(Collection::stream)

如果给Stream.flatMap新增一个接收Streamable（定义为包含stream()方法的接口）类型的重载，就可以简化成：

myStream.flatMap(MyObject::getCollection)

Optional的场景也同理。但这种方案存在不少弊端：

主要弊端分析： #

• 编译歧义风险：如果某个类同时实现了Streamable和其他flatMap已支持的类型（比如Iterable、Supplier<Stream<?>>），编译器会无法确定选用哪个重载，直接抛出编译错误。例如自定义类同时继承Collection（属于Iterable）和实现Streamable，调用flatMap时就会出现歧义。
• API复杂度提升：JDK的Stream API一直保持简洁性原则，新增重载会增加API的认知成本。开发者需要区分不同重载的适用场景，尤其是新手容易混淆，反而降低开发效率。
• 兼容性隐患：现有代码中如果存在返回自定义“类Streamable”（即包含stream()方法但未实现标准接口）的方法，新增重载后可能会意外改变原有代码逻辑——原本需要先map再flatMap的逻辑，现在会被直接处理为扁平化操作，导致运行结果不符合预期。
• 语义可读性下降：flatMap的核心语义是“将元素转换为流并扁平化”，直接传入Collection或Optional虽然代码更短，但对不熟悉该重载的开发者来说，需要额外理解背后的隐式转换逻辑，反而降低了代码的直观可读性，团队协作时容易产生误解。
• Optional的版本与行为混淆：Optional.stream()是Java 9才引入的特性，如果这个重载要兼容Java 8环境会直接失效。同时，直接将Optional传入flatMap，可能会让开发者忽略其“可能为空”的特性，虽然逻辑上是正确的，但容易弱化对空值处理的关注度。

总结 #

这种简化写法确实能减少代码行数，但带来的类型歧义、API复杂度、兼容性等问题，实际上超过了简洁性带来的收益，这也是JDK官方至今没有添加此类重载的重要原因。

内容的提问来源于stack exchange，提问作者Bogdan Tischenko