摘要 通过构建一个能够把Java类装载隔离到一个指定的jar文件中的类装载组件容器框架，你可以确保运行时刻会装载你期望的组件版本。
Java的类装载框架强有力且具有灵活性。它允许应用程序存取类库而不必链接到静态的"include"文件。代之的是，它能够从指定位置装载包含库类和资源的档案文件，例如由CLASSPATH环境变量所定义的目录和网络位置。由系统来动态地解析对类和资源的运行时刻参考，从而简化了更新和版本发行。然而，每一个库都有其自己的依赖性集合-并且由开发者和发布人员来保证他们的应用程序适当地参考正确的版本。遗憾的是，默认的类装载系统和特定依赖性的结合可能并且确实会导致错误、系统崩溃甚至于更糟糕的情况发生。
本文中，我将向你建议一个实现类装载的容器框架，从而解决这些问题。
一、Java Classpath
Java根据环境属性/变量CLASSPATH来指定运行时刻用来查找类和其它资源的路径。你可以通过设置CLASSPATH环境变量或使用Java命令行选项--classpath来定义CLASSPATH属性。
典型地，一个Java运行时刻以下面顺序查找和加载类：
1. 在bootstrap类列表中的类-这些是体现Java平台的类，例如在rt.jar中的类。
2. 出现在扩展类列表中的类-这些类使用扩展机制框架来扩展Java平台，使用位于运行时刻环境的/lib/ext目录下的档案文件(.jar，.zip，等等。)。
3. 用户类-这些类不使用-classpath命令行选项或CLASSPATH环境变量标识的扩展机制架构。
二、档案与Classpath
一个档案.jar或.zip文件可以包括一个manifest文件-它们包含能够用于提供档案信息，设置档案属性，等等的入口。这个manifest文件还可以通过包括一个名为Class-Path的入口（它包含一个档案和目录列表）来扩展classpath。JDK 1.3中引入了Class-Path manifest入口用于指定可选的据需要可以加载的jar文件和目录。下面是一个Class-Path入口的例子：
Class-Path: mystuff/utils.jar
mystuff/logging.jar mylib/
Java提供了一种可扩展模型用于指定装载类的位置和文件列表。然而，由此也引发了一些问题，例如，一个不同版本的库可能存在于classpath中-这超出一个执行类所期望的结果。
三、Classpath版本冲突
在Java中，一个类的运行时刻标识是由通过其完全限定名字来定义的（在类名之前的包名，有时被作为FQN），所有这些都添加到装载类的相关装载器的ID。这样以来，由多个类加载器加载的一个类的每一个实例都将被当作是Java运行时刻的一个单独的实体。这意味着，运行时刻能够在任何时间装载同一个类的多个版本。这是一种非常有力和相当灵活的特征；然而，如果一位开发人员不认真地使用的话，某些副作用可能会令他疑惑不解。
可以设想，你在开发一个企业应用程序-它使用类似语义从多种源存取数据，例如一个文件系统和一个数据库。许多这种类型的系统都暴露一个数据存取层-通过抽象类似数据源的数据存取对象（DAO）。现在，设想你装载一个新版本的一个数据库DAO，使用一种略微不同的API来满足一个DAO客户端的新特征的要求-但是你仍然需要旧式的DAO以便适合于其它还没有为这种新的API准备好的客户端。在典型的运行时刻环境下，这种新的DAO将简单地替换旧的版本并且所有的新实例都将从新版本中创建。然而，如果在不停止运行时刻环境的前提下发生更新，那么任何已经存在的旧DAO的实例将与该新DAO的任何实例一起驻留于内存中-当创建这些新实例时。这已经足已令人疑惑了。更为糟糕的是，一位DAO客户期望创建一个旧版本的DAO的实例，但是实际上得到一个具有已改变的API的新版本的实例。正如你所见，这可能会带来一些有趣的挑战。
为了确保稳定性和安全性，调用代码必须能够指明它想使用的类的正确版本。为此，你可以创建一个类加载器，组件容器模型并且使用一些简单的类加载技术。