为什么大多数 Eclipse 集合类型都是可序列化的？

Question

我在这里寻找设计原理。

我当然可以理解使集合类可序列化，尽管 JCF 不这样做。然而，Procedure、IntProcedure等接口尤其是不存在的主要候选者Serializable，因为无论如何它们通常都是匿名的。

制作这些接口Serializable违背了 Josh Bloch 的建议，即接口应该很少扩展Serializable[1]。

我可能需要更新我的 Eclipse 首选项，以免为每个匿名 发出串行 uid 警告Procedure。

[1] 有效的 Java 第二版。第 291 页

Answer 1

这个问题是几年前就被问到的。Serializable我将尽可能地解释使 Eclipse Collections 中的所有功能接口扩展的设计原理。这个决定是 15 年前做出的。注意：我是 Eclipse Collections 的创建者。

Eclipse Collections自 2004 年以来一直在开发。它的开发生命周期从 JDK 1.4 开始。Eclipse Collections 拥有函数式接口和函数式 API，比 Java 8 中提供 lambda 和 Streams 早了十年。为了将 Eclipse Collections 的函数式 API 与 Java 8 之前的函数式接口一起使用，我们经常必须创建匿名内部类。

我们需要序列化专有分布式缓存架构中缓存之间的功能接口，并且偶尔也需要将它们序列化到磁盘。Java 8 中向 Java 语言添加了交集类型以支持lambda 的序列化。在 Java 8 之前，我们必须选择单个接口或类来实现匿名内部类。如果我们用于匿名内部类的函数接口不是Serializable，那么我们就无法Serializable在不创建扩展函数接口和 的命名类的情况下实现它Serializable。

我们考虑的一种可能性是拥有并行的功能接口层次结构。我们可以有一个Function不扩展 的接口Serializable，然后添加第二个SerializableFunction接口来扩展Function和Serializable。分布式缓存空间中有一些采用这种并行层次结构方法的示例。例如，Oracle Coherence和Hazelcast具有扩展 JDK 等效接口和Serializable. 如果我们在 Eclipse Collections 中这样做，那么我们的函数接口类型总数（目前约为 500 个）将会增加一倍，达到近 1K 函数接口类型。

最终，我们决定 Eclipse Collections 的最佳方法是让我们所有的功能接口简单地扩展Serializable。

Java 8 发布后，我们添加@FunctionalInterface了函数式接口，并对其进行了更改以扩展 JDK 中的等效函数式接口。这使得我们拥有了Serializable可以与 Eclipse Collections 和 Java Streams API 一起使用的 JDK 接口版本。

以下是 Eclipse Collections 中包含的所有对象和原始功能接口的链接。可以看出，由于支持原始集合上的函数式 API，因此函数式接口非常庞大。

• 功能
• 原函数
• 谓词
• 原始谓词
• 程序
• 原始程序

当Valhalla 项目交付并且对原语的泛型支持包含在 LTS（长期支持）Java 版本中时，我们最终将升级 Eclipse Collections，并可能删除大多数当前的原语功能接口，因为它们将不再需要。我说可能，因为这将是一个重大更改，需要大量工作并且需要 Eclipse Collections 的主要版本。更重要的是，它将影响所有现有客户。