kar*_*hik 8 java serialization
InvalidClassException: local class incompatible: stream classdesc serialVersionUID = -196410440475012755, local class serialVersionUID = -6675950253085108747
我在以下场景中使用InvalidClassException进行结构化.在这里,我的EAR安装在4个Websphere App服务器中,并在此之间共享执行.有时我从POJO类得到异常InvalidClassException,它实现了Serializable接口.请对此有任何线索.我对此没有任何线索.
amo*_*mod 33
当您实现java.io.Serializable接口以使类可序列化时,编译器将查找名为"serialVersionUID"的类型为long的静态最终字段.如果类没有明确声明该字段,那么编译器将创建一个这样的字段并为其分配一个值,该值来自serialVersionUID的依赖于实现的计算.此计算取决于类的各个方面,并遵循Sun提供的对象序列化规范.但是,并不保证所有编译器实现的值都相同.
此值用于检查类与序列化的兼容性,这是在对已保存对象进行反序列化时完成的.Serialization Runtime验证发送方类的serialVersionUID(用于保存流上对象的状态)和接收方类(用于恢复对象的类,可能在某些其他系统中)的serialVersionUID两者完全相同.如果接收器系统加载的类具有一些其他serialVersionUID而不是序列化过程中使用的类,那么我们得到一个InvalidClassException.
注意 - 强烈建议您显式声明并初始化long类型的静态最终字段,并在要使其成为Serializable的所有类中命名为"serialVersionUID",而不是依赖于此字段值的默认计算.这种计算非常敏感,并且可能因编译器实现而异,因此您可能会因为在序列化过程的发送方和接收方端使用不同的编译器实现而在相同的类中获得InvalidClassException.
在大多数情况下,您将仅对此字段使用"私有"访问说明符,因为声明通常仅适用于声明它的类,我们实际上不需要在子类中继承此字段或从外部访问它.所以,几乎没有任何理由我们不应该保持它"私密".
当您尝试反序列化使用同一类的不兼容(通常较早)版本序列化的对象时,会出现该异常.
如果未serialVersionUID在类实现中明确指定a Serializable,则将根据类的(非transient)字段生成值.这样做是为了确保不会恢复部分对象(最好是失败而不是盲目地继续使用可能已损坏的对象).
在Web应用程序系统中,序列化的常见用途是用于会话:如果您将值放入会话中,则最终可能会将其序列化(用于群集支持或仅用于获取持久会话).
因此要么保持所有类在版本之间兼容,要么确保不恢复它们不会破坏您的应用程序(即不以这种方式存储重要信息).