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