Jar clone的版本冲突

核心提示：新版《星球大战》的精髓就是反对“克隆”，幸运的是，Jar clone的版本冲突，我们要谈的不是像电影中那样致命的“克隆”，但是这种“克隆”带来的伤害依然存在，这样对每个应用程序你能轻易的操作不同的classpath，让你对每个应用程序使用需要的jar文件，我们要谈的是围绕Apache Group's Xalan

　　新版《星球大战》的精髓就是反对“克隆”。幸运的是，我们要谈的不是像电影中那样致命的“克隆”，但是这种“克隆”带来的伤害依然存在。我们要谈的是围绕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文件，以分别操作。