java.io.InvalidClassException： [英] java.io.InvalidClassException:

问题描述

InvalidClassException: local class incompatible: stream classdesc serialVersionUID = -196410440475012755, local class serialVersionUID = -6675950253085108747

我使用InvalidClassException进行结构化以下场景。在这里，我的EAR安装在4个Websphere App服务器中，并在此之间共享执行。有时我从POJO类得到异常InvalidClassException，它实现了Serializable接口。请对此有任何线索。我对此没有任何线索。

I struct with the InvalidClassException in the following scenario. Here my EAR is installed in 4 Websphere App servers and execution is shared among this. Sometimes I got the exception InvalidClassException from POJO class, Which is implements Serializable interface. Please any clue on this. I don't have any clue regarding to this.

推荐答案

当您实现java.io.Serializable接口以使类可序列化时，编译器查找long类型的名为serialVersionUID的静态最终字段。如果类没有明确声明该字段，那么编译器将创建一个这样的字段并为其分配一个值，该值来自serialVersionUID的依赖于实现的计算。此计算取决于类的各个方面，并遵循Sun提供的对象序列化规范。但是，并不保证所有编译器实现的值都相同。

When you implement java.io.Serializable interface to make a class serializable, the compiler looks for a static, final field named "serialVersionUID" of type long. If the class doesn't have this field declared explicitly then the compiler will create one such field and assign it with a value which comes out of a implementation dependent computation of serialVersionUID. This computation depends upon various aspects of the class and it follows the Object Serialization Specifications given by Sun. But, the value is not guaranteed to be the same across all compiler implementations.

此值用于检查类与序列化的兼容性，这是完成的同时反序列化保存的对象。 Serialization Runtime验证发送方类的serialVersionUID（用于保存流上对象的状态）和接收方类（用于恢复对象的类，可能在某些其他系统中）的serialVersionUID两者完全相同。如果接收器系统加载的类具有一些其他serialVersionUID而不是序列化过程中使用的类，那么我们得到一个InvalidClassException。

This value is used for checking the compatibility of the classes with respect to serialization and this is done while de-serializing a saved object. The Serialization Runtime verifies that the serialVersionUID of the sender class (which was used for saving the state of the object on the stream) and that of the receiver class (the class which is being used to restore the object, possibly at some other system) both are exactly same. If the receiver system has loaded the class having some other serialVersionUID than that of the class used while serialization process then we get an InvalidClassException.

注意 -
它是强烈建议您显式声明并初始化long类型的静态最终字段，并在要使其成为Serializable的所有类中命名为serialVersionUID，而不是依赖于此字段值的默认计算。这种计算非常敏感，并且可能因编译器实现而异，因此即使对于同一个类，您也可能因为在发送器和接收器端序列化过程中使用了不同的编译器实现而获得InvalidClassException。

NOTE-- It's highly recommended that you explicitly declare and initialize the static, final field of type long and named 'serialVersionUID' in all your classes you want to make Serializable instead of relying on the default computation of the value for this field. This computation is extremely sensitive and may vary from one compiler implementation to another and hence you may turn up getting the InvalidClassException even for the same class just because you used different compiler implementations on the sender and the receiver ends of the serialization process.

在大多数情况下，您将仅对此字段使用私有访问说明符，因为声明通常仅适用于声明它的类，我们实际上不需要在子类OR中继承此字段以从外部访问它。因此，几乎没有任何理由我们不应该将其保持为私人。

In most of the cases you would be using 'private' access specifier only for this field as the declaration normally applies only to the class declaring it and we don't really need to either inherit this field in the subclasses OR to access it from outside. So, there is hardly any reason why we shouldn't keep it 'private'.

这篇关于java.io.InvalidClassException：的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！