collections.emptyenumeration和emptyiterator是语义型适配器：它们不封装对象，而是直接实现enumeration/iterator接口并固化“无元素”行为，统一屏蔽空值差异，避免null传播，确保接口契约安全执行。
Collections.emptyEnumeration 和 Collections.emptyIterator 都是 Java 中用于返回“空”遍历能力的工具方法，它们本身不是适配器实现，但背后体现了适配器模式的设计思想：统一接口、屏蔽差异、复用已有结构。
为什么说它们隐含适配器逻辑？
这两个方法返回的是内部私有静态类（如 EmptyEnumeration、EmptyIterator），它们分别实现了 Enumeration<e></e> 和 Iterator<e></e> 接口，但内部不持任何数据，所有操作都返回固定结果（如 hasMoreElements() 永远返回 false，hasNext() 同样为 false）。
这种设计本质上是在「适配」客户端对遍历接口的调用需求——无论下游代码期望一个 Enumeration 还是 Iterator，你都能提供一个语义正确、行为一致、无需判空的“空实例”，避免 null 值传播和重复判断。
- 它们把“无元素”这一语义，适配到不同历史阶段的遍历接口上（
Enumeration是 JDK 1.0 的，Iterator是 JDK 1.2 引入的） - 不需要修改调用方代码，也不需要创建新集合对象，直接返回轻量级单例
- 接口行为完全符合契约：不抛异常、不破坏迭代流程、可安全传入老系统或泛型工具方法
实际使用场景中的适配价值
当你的方法签名要求返回 Enumeration 或 Iterator，但业务逻辑可能确实没有数据时，直接返回 null 会迫使调用方处处判空；而返回空集合（如 Collections.emptyList()）再转成遍历器，又多一层封装开销。这时：
-
Collections.emptyEnumeration()可直接用于需兼容javax.swing、java.beans等老 API 的场景（比如JTable的某些自定义模型） -
Collections.emptyIterator()更适合现代流式处理链，例如作为StreamSupport.stream(Spliterators.spliteratorUnknownSize(...), false)的输入源 - 二者都可用于单元测试中模拟边界条件，避免构造真实集合对象
与显式适配器（如 Enumeration2Iterator）的区别
它们不是传统意义上的“转换型适配器”（比如把 Enumeration 包装成 Iterator），而是“语义型适配器”：
- 不封装其他对象，不转发调用，而是直接实现接口并固化行为
- 解决的是“空值如何符合接口契约”的问题，而非“两个接口如何互转”的问题
- 属于 JDK 内部对适配器思想的轻量落地，比手写包装类更高效、更安全
注意事项
虽然用法简单，但需注意：
- 返回对象不可变且线程安全，可自由共享，无需同步
- 不支持
remove()（Iterator版本）或任何修改操作，调用会抛UnsupportedOperationException - 它们与
Collections.enumeration(collection)不同：后者是动态适配现有集合，前者是静态提供空能力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
