Java序列化查询 [英] Query on Java Serialization

问题描述

在现有的类中添加新的成员方法后，我面临以下问题。Response实现了Serializable {} 。没有声明明确的串行版本ID。多次尝试，得到的序列号是相同的。

I am facing below issue, after adding new member methods in existing class Response implements Serializable{}. There is no explicit serial version id declared. On multiple try, am getting the same serial numbers.

Error communicating with the webserver: com.abc.xyz.app.util.common.Response;
local class incompatible: stream classdesc serialversionUID = 
-3900355805473150430, local class serialversionUID = 
-6706527232726476603

在阅读了一些文档之后，我尝试用以下附加行修改 class Response ： private final static long serialVersionUID = 1L ; 。

After going through some documentation, i tried modifying the class Response with additional line: private final static long serialVersionUID = 1L; .

进行此更改后，以下是错误：

With this change, below is the error:

Error communicating with the webserver: com.abc.xyz.app.util.common.Response;
local class incompatible: stream classdesc serialversionUID = 
-3900355805473150430, local class serialversionUID = 1

这些类位于tomcat的 webapps 文件夹中，并在客户端计算机上作为 xyz.jnlp 加载。 。新鲜的客户端计算机用于从远程Web服务器加载 xyz.jnlp 。

These are the classes that sit in webapps folder of tomcat and get loaded as xyz.jnlp on client machine. Fresh client machine is taken to load xyz.jnlp from remote webserver. But things does not work!!!

请帮助我理解这个问题。

Please help me understand this problem.

推荐答案

序列化对象时，将类的序列号UID写入流中。如果该类没有一个类，则使用确定性算法自动生成该类。

When serializing an object, the serial version UID of the class is written to the stream. If the class doesn't have one, it's automatically generated using a deterministic algorithm.

反序列化给定类的对象时，将使用本地类的串行版本UID（硬编码或生成）与流中的那个进行比较。如果它们不匹配，则会出现异常：这意味着这些类不兼容。

When deserializing an object of a given class, the serial version UID of the local class (hard-coded or generated) is compared to the one in the stream. And if they don't match, you get an exception: that means the classes are not compatible.

因此，要解决您的问题，您有2个选择：

So, to fix your problem, you have 2 choices:

1. 确保服务器和客户端始终共享同一类。那是最好，最简单的解决方案。但这要求每次更新服务器时都要更新所有客户端。


2. 确保这些类始终兼容。由于您的旧类没有硬编码的serialVersionUID，并且您想更改该类并保持兼容，因此您需要对serialVersionUID进行硬编码，其值应与为的初始版本自动生成的值相同班级。当然，您必须知道，如果添加字段，接收方将无法读取它们，并且如果您删除字段，则这些字段的接收方值将为null，这可能会破坏不变式。 / li>
   

1. make sure the server and the client always share the same class. That is the best, easiest solution. But it requires that all the clients are updated every time the server is updated.
2. make sure the classes are always compatible. Since your old class didn't have a hard-coded serialVersionUID, and you want to change the class and keep it compatible, you need to hardcode a serialVersionUID with a value that is identical to the one that was automatically generated for the initial version of the class. And of course, you have to be aware that if you add fields, the receiver won't be able to read them, and that if you remove fields, the receiver's value for these fields will be null, which might break the invariants.

除非您完全了解所做更改的含义，这很困难并且需要阅读序列化规范，否则我的建议是选择1：使客户端和服务器保持最新状态。

Unless you completely understand the implications of your changes, which is hard and requires reading the serialization specification, my advice would be to go with option 1: keep the client and the server up to dates.

这篇关于Java序列化查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！