兼容性問題
兼容性歷來是複雜而麻煩的問題。
不要兼容性:
首先來看看如果我們的目的是不要兼容性,應該注意哪些。不要兼容性的場合很多,比如war3每當版本升級就不能夠讀取以前的replays。
兼容也就是版本控制,java通過一個名爲UID(stream unique identifier)來控制,這個UID是隱式的,它通過類名,方法名等諸多因素經過計算而得,理論上是一一映射的關係,也就是唯一的。如果UID不一 樣的話,就無法實現反序列化了,並且將會得到InvalidClassException。
當我們要人爲的產生一個新的版本(實現並沒有改動),而拋棄以前的版本的話,可以通過顯式的聲名UID來實現:
private static final long serialVersionUID=1l;
你可以編造一個版本號,但注意不要重複。這樣在反序列化的時候老版本將得到InvalidClassException,我們可以在老版本的地方捕捉這個異常,並提示用戶升級的新的版本。
當改動不大時,保持兼容性(向下兼容性的一個特例):
有時候你的類增加了一些無關緊要的非私有方法,而邏輯字段並不改變的時候,你當然希望老版本和新版本保持兼容性,方法同樣是通過顯式的聲名UID來實現。下面我們驗證一下。
老版本:
import java.io.*;
public class Serial implements Serializable {
int company_id;
String company_addr;
public Serial1(int company_id, String company_addr) {
this.company_id = company_id;
this.company_addr = company_addr;
}
public String toString() {
return "DATA: "+company_id+" "+
company_addr;
}
}
新版本
import java.io.*;
public class Serial implements Serializable {
int company_id;
String company_addr;
public Serial1(int company_id, String company_addr) {
this.company_id = company_id;
this.company_addr = company_addr;
}
public String toString() {
return "DATA: "+company_id+" "+ company_addr;
}
public void todo(){}//無關緊要的方法
}
首先將老版本序列化,然後用新版本讀出,發生錯誤:
java.io.InvalidClassException: Serial.Serial1; local class incompatible: stream classdesc serialVersionUID = 762508508425139227, local class serialVersionUID = 1187169935661445676
接下來我們加入顯式的聲名UID:
private static final long serialVersionUID=762508508425139227l;
再次運行,順利地產生新對象
DATA: 1001 com1
如何保持向上兼容性:
向上兼容性是指老的版本能夠讀取新的版本序列化的數據流。常常出現在我們的服務器的數據更新了,仍然希望老的客戶端能夠支持反序列化新的數據流,直到其更新到新的版本。可以說,這是半自動的事情。
跟一般的講,因爲在java中serialVersionUID是唯一控制着能否反序列化成功的標誌,只要這個值不一樣,就無法反序列化成功。但只要這個 值相同,無論如何都將反序列化,在這個過程中,對於向上兼容性,新數據流中的多餘的內容將會被忽略;對於向下兼容性而言,舊的數據流中所包含的所有內容都 將會被恢復,新版本的類中沒有涉及到的部分將保持默認值。利用這一特性,可以說,只要我們認爲的保持serialVersionUID不變,向上兼容性是 自動實現的。
當然,一但我們將新版本中的老的內容拿掉,情況就不同了,即使UID保持不變,會引發異常。正是因爲這一點,我們要牢記一個類一旦實現了序列化又要保持向上下兼容性,就不可以隨隨便便的修改了!!!
測試也證明了這一點,有興趣的讀者可以自己試一試。
如何保持向下兼容性:
一如上文所指出的,你會想當然的認爲只要保持serialVersionUID不變,向下兼容性是自動實現的。但實際上,向下兼容要複雜一些。這是因爲,我們必須要對那些沒有初始化的字段負責。要保證它們能被使用。
所以必須要利用
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException{
in.defaultReadObject();//先反序列化對象
if(ver=5552){//以前的版本5552
…初始化其他字段
}else if(ver=5550){//以前的版本5550
…初始化其他字段
}else{//太老的版本不支持
throw new InvalidClassException();
}
}
細心的讀者會注意到要保證in.defaultReadObject();能夠順利執行,就必須要求serialVersionUID保持一致,所以這裏 的ver不能夠利用serialVersionUID了。這裏的ver是一個我們預先安插好的final long ver=xxxx;並且它不能夠被transient修飾。所以保持向下的兼容性至少有三點要求:
1.serialVersionUID保持一致
2.預先安插好我們自己的版本識別標誌的final long ver=xxxx;
3.保證初始化所有的域
討論一下兼容性策略:
到這裏我們可以看到要保持向下的兼容性很麻煩。而且隨着版本數目的增加。維護會變得困難而繁瑣。討論什麼樣的程序應該使用怎麼樣的兼容性序列化策略已經超 出本文的範疇,但是對於一個遊戲的存盤功能,和對於一個字處理軟件的文檔的兼容性的要求肯定不同。對於rpg遊戲的存盤功能,一般要求能夠保持向下兼容, 這裏如果使用java序列化的方法,則可根據以上分析的三點進行準備。對於這樣的情況使用對象序列化方法還是可以應付的。對於一個字處理軟件的文檔的兼容 性要求頗高,一般情況下的策略都是要求良好的向下兼容性,和儘可能的向上兼容性。則一般不會使用對象序列化技術,一個精心設計的文檔結構,更能解決問題。
ps:serialVersionUID做爲序列化的版本控制是一個非常有用的兼容手段,通常情況下,我們應該手工設置該值,當然,ide eclipse有提示你設置其值。serialVersionUID可以任意設置,根據不同的兼容性做相應改動。