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