首先一句话:serialVersionUID 用来表明类的不同版本间的兼容性 (这句话是100%转载)
Java在处理远程调用时,是通过判断serialVersionUID是否相同来决定本地与远程调用方所使用的类(class)是否相同的。一个很有意思的地方:哪怕双方使用的类不是完全相同,但只要serialVersionUID相同,本地的jvm就会认定本地的class与远方的class是相同的,然后尝试将远方传来的class进行反序列化。
说一个实际的例子就好明白了:
我们提供EJB的Remote Interface给第三方(A方)进行远程调用,interface如下:
public TransferObject invoke(TransferObject transferObject) throws RemoteException;
对应的Data Transfer Object是TransferObject
public class SendSmsDTO implements Serializable {
private static final long serialVersionUID = 3948131477708156541L;
private String id;
private String address;
......
}
此时我们提供给第三方的TransferObject 只有两字段(id和address)。
过了一段时间,我们要给另一个第三方(B方)提供同样的interface,但是因为需求有少许不同,我们需要在TransferObject对象里加一个新的字段-"name"。
public class SendSmsDTO implements Serializable {
private static final long serialVersionUID = 3948131477708156541L;
private String id;
private String address;
private String name;
......
}
之后,我们为之前的第三方(A方)进行系统升级,由于对方(A方)并无B方的需求,所以也就不需要用到新的TransferObject里“name”字段,但是我们的TransferObject已经改动了,按理说A方是需要拿到我们提供的新interface(新TransferObject)去重现编译他们的代码才可以的。
但是,实际上是不用的!因为我们一直没有改变TransferObject的serialVersionUID 值,所以只要我们和A方使用的Interface方法签名是相同的(同样的invoke()方法),那么哪怕我们两边用到不同的TransferObject,两边的Jvm都不会报错。
而且十分有趣,当A方调用invoke()方法时,A方输入参数的TransferObject里没有“name”字段,所有我们服务端一方,收到A方请求时,“name”字段永远为空。而当我们服务端return TransferObject回给A方时,哪怕我们在TransferObject里输入了“name”值,在A方得到return时,A方的TranferObject里没有“name”字段,A方就永远也看不到我们在return TransferObject里设置的“name”值。
啰啰嗦嗦讲了一大堆,希望有人能明白我在说啥。:-)
附:
如果一个class没有设置serialVersionUID,JVM在使用该JDK提供了查看JVM默认生成serialVersionUID
serialver -classpath test.jar com.test.TransferObject.