是否有必要在发送事件时由服务器发送电子邮件时使用HttpServlet中的serialVersionUID

Question

我试图在应用引擎中创建特定类型的请求时发送电子邮件 所以我使用TaskOptions.Builder.withUrl("path/to/httpServlet/class")来启动servlet，但在servlet类中，我收到警告可序列化的类sendEmail不声明long类型的静态final serialVersionUID字段。那么是否有必要定义这个serialVersionUID？

Answer 1

是否有必要取决于可序列化的类以及它将如何使用。

如果类的实例根本不会被序列化，那么它绝对没有区别。 serialVersionUID仅在对象序列化和反序列化时使用。

的serialVersionUID领域的效用时，代理商做的序列化和反序列化可能潜在使用不同版本的类或者可以在不同的Java平台上运行的出现。以下是Object Serialization Spec所说的内容：

流唯一标识符是类名称，接口类名称，方法和字段的64位散列。该值必须在除第一个类之外的所有类的版本中声明。它可以在原始类中声明，但不是必需的。该值对所有兼容类都是固定的。如果没有为类声明SUID，则该值默认为该类的哈希值。动态代理类的serialVersionUID和enum类型的值始终为0L。数组类不能声明明确的serialVersionUID，因此它们始终具有默认的计算值，但对于数组类，可以免除匹配serialVersionUID值的要求。

注 - 强烈建议所有可序列化类中明确声明serialVersionUID值，因为默认serialVersionUID计算是类的细节可能取决于编译器实现变化高度敏感，并因此可能导致反序列化过程中意外serialVersionUID冲突，造成反序列化失败。

总结说：

• 如果你不声明serialVersionUID，你可以得到所造成的不属于真正的冲突无端例外。 （例如，如果你只是改变了方法名不改变类的代表性语义。）

• 但是，如果你声明serialVersionUID，而你做的做了不兼容的变化的一类，那么你应该要更改serialVersionUID的值......除非您要使用对象序列化提供的“即时”转换的其他机制之一。

注意SUIDs试图提供一个切实可行的解决方案到schema evolution problem。这是一个非常困难的问题。

---

^{1 - 从类型论的角度来看这听起来不太合理。违反类型抽象有许多方法。然而，SUID机制是非常实用的，并且鉴于Java编程语言的性质，对效率的需求等等，它是可能的。}