這兩東東本質上是有差別的，JAXB稱爲OX binding工具，XStream應該算序列化工具，但OX binding工具也會marshall和unmarshall，所以包含了序列化這一部分。序列化工具不一定需要提供binding的功能。既然都玩序列化，那就簡單地比較一下它們兩在序列化方面的強弱吧。
JAXB：Toplink JAXB 10133，應該是JAXB 1.1標準 （取消了schema的validation功能）
XStream：1.3.1
數據長度：
|
類型 |
長度 |
內容 |
|
XStraem |
351 |
<com.oocl.frm.ws.sample.Employee> <name>Liufei</name> <age>40</age> <address> <street>Zhaojiabang</street> <country>China</country> <city>Shanghai</city> <doorNum>789</doorNum> <empName>Afka liu</empName> </address> <salary>20000.0</salary> <isActive>false</isActive> <sexy>F</sexy> </com.oocl.frm.ws.sample.Employee> |
|
Toplink JAXB |
589(已經去掉了white space) |
<?xml version="1.0" encoding="UTF-8"?> <ns0:employee xsi:schemaLocation="http://www.oocl.com/frm/ws/jaxb" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns0="http://www.oocl.com/frm/ws/jaxb" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ns0:name>Liufei</ns0:name><ns0:age>40</ns0:age><ns0:salary>20000.0</ns0:salary><ns0:sexy>F</ns0:sexy><ns0:isActive>false</ns0:isActive><ns0:address><ns0:street>Zhaojiabang</ns0:street><ns0:country>China</ns0:country><ns0:city>Shanghai</ns0:city><ns0:doorNum>789</ns0:doorNum><ns0:empName>Afka liu</ns0:empName></ns0:address></ns0:employee> |
時間：序列化和反序列化1000000次。
|
類型 |
序列化（ms） |
反序列化（ms） |
|
XStraem |
90148 |
135878 |
|
Toplink JAXB |
34872 |
56557 |
結果對比：數據量XStream佔優勢，時間性能上Toplink Jaxb佔明顯優勢
總結（只從序列化功能角度看）
JAXB: 優點
- J2EE標準
- 運行時間比XStream少
缺點
- 用起來不方便：需要把手動的把business object轉換成schema object，當然也可以直接將schema object作爲business object，或者採用反射的方法。
- 有一定的侷限性：需要schema或者annotation
- 數據量稍大
XStream優點：
- 用起來方便
- 不需要schema，拿過來就轉
- 數據量稍小
缺點：
- 非標準
- 時間性能差
|
|
|
評論
更小的數據量、更少的時間：
<com.oocl.frm.ws.sample.Employee name="LiuFei" age="40" salary="20000.0" isActive="false" sex="F" >
<address street="Zhaojiabang" country="china" city="Shanghai" doornum=789 empName="Afka liu" />
</com.oocl.frm.ws.sample.Employee> 回覆 更多評論
可以用alias省掉一些信息，我們是用在遠程通信上的，如果去掉了類的路徑，就無法還原了。採用alias我想會帶來複雜性的。這樣是我們所需的最少信息量了。請問有什麼好的辦法可以不要某些white space，相當於jaxb的 this.marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT,
Boolean.FALSE);
回覆 更多評論
我不太明白，在遠程通信上，使用xml作爲中間傳輸內容，就是爲了做系統（甚至是異構系統）之間的解耦。
如果xml內容上，還捆綁了類信息，那麼既要求兩個系統爲同語言系統，又將兩個系統都捆綁到具體的一個model上。未必是一件好事。
回覆 更多評論
呵呵，類似RPC吧：JAX-RPC, REST-RPC。序列化後還是要還原成Object的。 回覆 更多評論
如果需要捆綁Object，類似RPC調用，那爲什麼不選擇hessian等二進制序列化方式的組件。
畢竟二進制序列化／反序列化效率比xml轉化高多了。
當然hessian不同版本在協議上的不兼容，是一件很頭疼的事情 ：（ 回覆 更多評論
是個很好的提議。但在可讀性和公司policy方面還需要考慮。而且我們只是需要序列化的機制，並不是需要特殊的服務協議。我們可以通過HTTP，RMI, JMS，FTP或者其他各種方式完成同步，異步的服務調用。 回覆 更多評論
首先，xstream是爲了序列化成xml文檔，並沒要求服務端也需要xstream來解析文檔啊，所以不存在異構系統讀取該類的情況，異構系統完全可以把xml文檔看做是一份數據來用。而且xstream是可以更改內容標籤的名稱的。
然後是2進制序列化的問題，其實不是說2進制序列化不好，而是因爲很多應用環境只開發http協議，所以纔有xml文檔做webservice的接口。 回覆 更多評論