GWT能有效地序列化java.lang.Longs吗？

Question

我通过GWT RPC机制在客户端和服务器之间发送对象ID。这些ID作为Longs(8个字节)从数据存储中出来。我认为我的所有ID都只需要4个字节，但是随机情况下可能会给我一个5字节（或其他）的值。

GWT会聪明地将这些值打包到一些可变长度的编码中，以平均节省空间吗？我可以在某个地方指定它这样做吗？还是我应该编写自己的代码将Longs复制到ints，并注意那些特殊情况？

谢谢~

- Riley Lark

Answer 1

GWT在有效载荷为256字节或更大的响应中使用gzip压缩。如果您的响应中有很多零字节，那么这应该工作得很好。

从 RemoteServiceServlet.shouldCompressResponse:

确定是否应该对给定的servlet请求的响应进行GZIP压缩。仅在请求者接受GZIP编码的情况下才调用此方法。

当前实现会在响应字符串的估计字节长度超过256个字节时返回true。子类可以重写此逻辑。

因此，服务器首先检查请求者（通常是浏览器）是否接受GZIP编码。在内部，使用java.util.zip.GZIPOutputStream - 请参见RPCServerUtils。在客户端上，浏览器的工作是解压缩已压缩的有效负载 - 因为这是在本地代码中完成的，所以应该相当快。

- dslh

---

我不确定是否有文档记录，但源代码不会说谎。RemoteServiceServlet的内部工作方式令人惊讶地易于理解，如果要进行全面了解，请从processPost开始阅读，但这里相关的部分是writeResponse（以及RPCServletUtils.writeResponse）。所有操作都是按照HTTP标准进行的，设置内容编码头，因此浏览器会自动处理解压缩。 - dslh

@hambend：这很有意思，因为JS在进行编码/压缩等操作时非常慢（取决于浏览器）。我想，当处理大请求（比如100kB）时，这可能是个问题。我还没有尝试过客户端gzip压缩，但我做了一些RC4加密的实验，在IE中很快就会出现缓慢脚本警告。那么有关闭gzip选项的选项吗？ - Chris Lercher

@hambend 我也从未听说过这个，你有参考链接吗？ - Arthur Maltson

谢谢Igor，看起来不错。@chris_l: 我的理解是，大多数浏览器中解压缩是本地功能，而不是由JS处理的内容。无论如何，您可以通过覆盖servlet中的shouldCompressResponse，始终返回false来禁用它，尽管在此对用户代理进行检查可能更合适。 - dslh

@Arthur：看起来是这样。公平地说，Servlet容器只有最少的设置可以启用压缩，我怀疑它只自动应用于静态内容。快速谷歌搜索“java servlet gzip compression”显示大多数（全部？）实现都以某种方式使用GZIPOutputStream。 - dslh

Answer 2

如GWT文档所述。

long：JavaScript没有64位整数类型，因此需要特别考虑长整型。在GWT 1.5之前，长整型被简单地映射为64位JavaScript浮点值的整数范围，使得长整型变量的实际范围小于完整的64位。从GWT 1.5开始，长整型原语被模拟为一对32位整数，并可在整个64位范围内可靠工作。溢出被模拟以匹配预期行为。有几个注意事项。由于底层模拟，频繁使用长整型操作会影响性能。此外，长整型原语不能在JSNI代码中使用，因为它们不是本机JavaScript数值类型。

如果您的ID可以适合整数，则最好使用整数。否则，如果您正在使用DTO，请将ID设置为double，这在Javascript中实际存在。

- Arthur Maltson