GWT-RPC 服务是否应该使用 java.io.Serializable 作为参数类型？

Question

我正在 GWT 中定义一个简单的“键值存储”服务；我将编写服务器，但让其他人编写客户端，因此它应该尽可能简单。我希望客户端能够使用字符串键，但可以使用任何可序列化类型的值。所以我定义了接口：

public void put(String key, java.io.Serializable value);
public java.io.Serializable get(String key);

这工作得很好，但是有一个问题：Eclipse 对这两种方法都给出了以下警告：

检查符合序列化条件的所有对象子类型

谷歌搜索该警告，看起来 GWT 将为程序中的每种类型生成一段代码。因此，这可能非常昂贵。我很困惑，因为我认为 Serialized 接口中的所有类型都已经有序列化代码，并且它可以直接调用它（但也许序列化代码仅在这种情况下生成）。

所以我有很多问题：

• 这是否会使客户端代码a）更大和/或b）更慢？这个问题有多严重？
• 我看到 GWT 提供了一个单独的接口 IsSerialized。我可以用它代替吗？我尝试过，但我注意到像 String 和 Integer 这样的基本类没有实现这个接口。
• 如果我让 RPC 层使用 byte[] 代替，但为我的客户端提供一个包装方法，将 java.io.Serialized 序列化为 byte[]，这会解决问题，还是会导致与我开始时相同的代码膨胀问题？
• 有没有更好的方法来实现键值存储，它允许任意类型的值，而无需代表客户端做太多工作？
• 如果我坚持使用可序列化，有没有办法抑制该警告？

Answer 1

我看到GWT提供了一个单独的接口IsSerializable。我可以用它代替吗？我尝试了一下，但我注意到像 String 和 Integer 这样的基本类没有实现这个接口。

是的。 IsSerialized 优于 java.io.Serializable。 GWT 常见问题解答列出了出现这种情况的原因所以：

• GWT 序列化的语义远没有标准 Java 序列化那么复杂，因此使用 java.io.Serialized 作为标记接口意味着 GWT 序列化系统的能力比其实际能力要多。
• 相反，GWT 的序列化机制比标准 Java 的序列化机制更简单，因此使用 java.io.Serialized 意味着用户需要担心的事情（例如序列化版本 ID）比实际情况要多。
• GWT 仅实现完整 Java JRE 类的一个子集，并且在 java.io 中没有具体实现任何内容。使用 java.io.Serialized 作为 GWT RPC 序列化标记接口会淡化 java.io 在 GWT 应用程序中不可用的消息。

>

如果我让 RPC 层使用 byte[] 代替，但为我的客户端提供一个包装方法来将 java.io.Serialized 序列化为 byte[]，这会解决问题，还是最终会导致和我一开始遇到的代码膨胀问题一样吗？

坏主意。在这种情况下，从对象到 byte[] 的序列化将在客户端的 JavaScript 中发生。是的，可以在客户端进行序列化，但需要使用 GWT 协议；这不是 Java 序列化。浏览器不会做得很好。

是否有更好的方法来实现键值存储，该存储允许任意类型的值，而无需代表客户端进行太多工作？

不幸的是，我认为您将无法为所有类提供一种真正的方法。我建议您尝试以下接口：

interface Store<T extends Serializable & IsSerializable> {
void put(String key, String value);
void put(String key, Number value);
void put(String key, T value);

Integer getInt(String key);
Double getDouble(String key);
BigDecimal getBigDecimal(String key);
String getString(String key);
IsSerializable get(String key);
}

泛型确保对象具有两个接口，以便您可以使用 GWT 协议（从客户端到服务器）和 Java 序列化（从服务器到数据存储）进行序列化。

编辑回复评论：

对于最后一个解决方案，通用不是意味着存储只能存储单一类型的对象，如果客户端想要存储不同类型的对象，他必须创建一个新存储？

是的，客户必须为每种类型创建一个新商店。如果它真的困扰你，解决这个问题的一个解决方案是创建一个新的接口 MySerialized，它扩展了 IsSerializes 和 java.io.Serializes；但是每个对象都必须实现它，这会创建对您的项目的依赖关系。

另外，它不要求对象既可序列化又可序列化吗？

是的，这是一个好处。否则，您可能会面临服务器端对象不是 java.io.Serialized 的风险；如果您尝试将其提供给方法 ObjectOutputStream#writeObject，异常就会当着你的面爆炸。

最后，我的第一个问题如何：仅使用 io.Serialized 实际上会影响代码大小/性能吗？

从实际使用情况来看，我不能这么说，但我不这么认为：两者都只是标记接口。两者的 GWT 序列化都是相同的。