Jar clone的版本沖突

2019-11-18 13:26:13

字體：大中小

來源：轉載

供稿：網友

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

上一篇：垃圾自動收集系統指導 (2)

下一篇：使用Javadoc標記你需要的信息