为什么 java.io.Serialized 在 Java 5 中没有被弃用？

Question

在 Java 5 之前，没有注释。因此，您无法将元数据添加到类中。

要将类标记为可序列化，您必须实现 Serialized 接口（这只是一个标记），并在需要时使用进一步的 transient 关键字将字段标记为不可序列化，例如：

public class MyClass implements Serializable {
   ...
   private transient Bla field;
   ...
}

现在理论上您可以使用注释（这是一个完美的使用对于他们来说）并且有：

@Serializable
public class MyClass {
   ...
   @Transient
   private Bla field;
   ...
}

但是Interface 和关键字并未被废弃，Java 5 中也没有添加注释来替代它们。

这次决定保留接口和关键字是出于什么考虑？

当然，存在与 Java 5 之前的代码的兼容性问题，但在某些时候，这个问题将会结束（例如，与泛型的新功能相关，JLS 指定 Java 编程语言的未来版本可能会禁止使用原始类型）。那么为什么不为序列化注释也做好准备呢？

有什么想法吗？ （尽管我更喜欢具体的参考资料：D，我无法找到）

Answer 1

该接口存在，因此可以定义方法来接受 Serialized 类型的对象：

public void registerObject(Serializable obj);

Answer 2

当然存在与 Java 5 之前的代码的兼容性问题......

是的。这就是问题的根源。

• 如果他们@deprecated（例如）Java 5 中的Serialized 接口，那么许多旧的 Java 5 之前的代码将发出警告（或错误，具体取决于编译器开关） ）。

• 使用Serialized实际上并没有什么问题，“强迫”人们替换它很烦人。 （人们有更好的事情要做...）

• 当人们在代码中“修复”了这个问题时，它将不再使用 Java 5 之前的编译器进行编译，也不会在 Java 5 之前的 JVM 上运行。

• 做一些让编译器系统地“狼来了”的事情是一个坏主意。

...但在某个时候这将会结束。

事实上，这种情况实际发生的可能性（IMO）很小。据我所知，Sun / Oracle从未删除过已弃用的功能。甚至没有像 Thread.stop() 之类的危险的。

---

作为脚注，Go 开发人员正在采取不同的方法来解决这个问题。当他们想要更改语言或库功能时，他们就会这么做。他们提供了一个转换器，它将根据需要自动重写您的代码。

Answer 3

Serialized 和 transient 确实是两个可以被注释取代的东西。

它们尚未被弃用，可能是因为有很多程序使用 Serialized，如果编译器突然开始吐出数千个代码，那么对于数百万人来说，这将是令人烦恼的弃用警告。

标准 Java API 中还有很多其他东西可能早就被弃用了 - 例如，遗留集合类 Vector 和 Hashtable （我相信你可以轻松找到更多东西）。还有其他一些东西可以使用注释来实现（例如关键字 volatile、strictfp 和 synchronized）。

Answer 4

弃用是针对那些积极有害的事物。你的建议是强迫八年现有 Java 代码（当时）的作者重写它，没有任何好处，只是为了关闭弃用编译器警告，回到他们在 Java 1.4 中拥有的完全正确的代码。那是没有用的。