新版《星球大戰》的精髓就是反對
克隆
幸運的是
我們要談的不是像電影中那樣致命的
克隆
但是這種
克隆
帶來的傷害依然存在
我們要談的是圍繞Apache Group
s Xalan和Xerces的一系列問題
克隆
在我們的觀點中
克隆
是指包和類
問題是XML和Java好像在一個連續改變的狀態中
在說明書中建立的XML新特點
必須在某處執行
通常
新特征和舊版本中的存在沖突
盡管它不是很大的問題
然而
當你認識到這些矛盾執行被封裝和配置在同一
克隆
文件名時
你還是將能意識到問題的存在
克隆
文件xalan
jar
xerces
jar
crimson
jar給出了開發者和管理者要解決的問題
但文件名不能顯示他們屬於哪個版本的任何信息
更多問題
問題是不僅存在這些文件的沖突執行
而且JDK配置的版本也存在沖突
JDK
有一個指定目錄（lib/ext）
該目錄自動存放著classpath中的一些jar文件
該目錄被用於緩解到基本java包的注冊擴張
因為該注冊擴張被設計成JDK（或JRE）的一部分
感覺上是直接到java虛擬機
與而不是自動加入classpath
用JAVA解析XML已經變得那麼平常
以至於很多JDK中配置了Xalan 和Xerces jar文件
更重要的事
他們被配置在lib/ext目錄下
雖然這是一個好主意
但他卻更容易帶來問題
在IBM的JDK
的lib/ext目錄下有一個舊的Xerces版本
該版本不支持JAXP
因此它與許多Xalan當前版本不兼容
Sun存在同樣的問題
他的JDK
版本包含支持Crimson的JAXP
但不幸的是
JDK中配置的crimson
jar用了一個舊版的JAXP
同樣也與許多Xalan當前版本不兼容
解決途徑
這還剛剛是問題表面
當你開始考慮用政治或商業模塊建立應用程序時
問題更為嚴重
假如你需要用java聯合兩個應用程序
一個應用程序你是用了IBM舊版的xerces
jar
另一個你用的是Sun 舊版的crimson
jar
而你的代碼需要用最新版的Xerces 和Xalan
理想的解決方法是所有的供應商升級他們的版本
重新配置他們的應用軟件和模塊
然而這是不可能的
另一種選擇是檢查清楚每個應用程序使用的是那個jar文件的class
如果條件允許
你能安排classpath中的jar文件
是他們按指定的次序裝載
你可能也會考慮在不同的java虛擬機上安裝你的應用程序
這樣對每個應用程序你能容易的操作不同的classpath
讓你對每個應用程序使用需要的jar文件
以分別操作
From:http://tw.wingwit.com/Article/program/Java/Javascript/201311/25313.html
