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