图3显示了控制台输出。我们可以看到对应着version.fx(1)的代码被执行了，因为类加载器在classpath首先看到此版本的代码。
　　　
　　图3. 在类路径中samepath测试排在最前面的version 1
　　
　　再次运行，类路径做如下微小改动。
　　
　　set classpath=.;%current_root%/v2;%current_root%/v1
　　%java_home%/bin/java test
　　
　　控制台的输出变为图4。对应着version.fx(2)的代码被加载，因为类加载器在classpath中首先找到它的路径。
　　　
　　图4. 在类路径中samepath测试排在最前面的version 2
　　
　　根据以上例子可以很明显地看出，类加载器加载在类路径中被首先找到的元素。如果我们在v1和v2中删除了version.version，做一个非version.version形式的.jar文件，如myextension.jar，把它放到对应java.ext.dirs的路径下，再次执行后看到version.version不再被appclassloader加载，而是被扩展类加载器加载。如图5所示。
　　　
　　图5. appclassloader及extclassloader
　　
　　继续这个例子，文件夹differentversions包含了一个rmi执行引擎，客户端可以提供给执行引擎任何实现了common.taskintf接口的任务。子文件夹client1 和 client2包含了类client.taskimpl有个细微不同的两个版本。两个类的区别在以下几行：
　　
　　static{
　　log("client.taskimpl.class.getclassloader
　　(v1) : " + taskimpl.class.getclassloader());
　　}
　　public void execute(){
　　log("this = " + this + ";
　　execute(1)");
　　}
　　
　　在client1和client2里分别有getclassloader(v1) 与 execute(1)和getclassloader(v2) 与 execute(2)的的log语句。并且，在开始执行引擎rmi服务器的代码中，我们随意地将client2的任务实现放在类路径的前面。
　　
　　classpath=%current_root%/common;%current_root%/server;
　　%current_root%/client2;%current_root%/client1
　　%java_home%/bin/java server.server
　　
　　如图6，7，8的屏幕截图，在客户端vm，各自的client.taskimpl类被加载、实例化，并发送到服务端的vm来执行。从服务端的控制台，可以明显看到client.taskimpl代码只被服务端的vm执行一次，这个单一的代码版本在服务端多次生成了许多实例，并执行任务。
　　　
　　图6. 执行引擎服务器控制台
　　
　　图6显示了服务端的控制台，加载并执行两个不同的客户端的请求，如图７，８所示。需要注意的是，代码只被加载了一次（从静态初始化块的日志中也可以明显看出），但对于客户端的调用这个方法被执行了两次。
　　　
　　图７. 执行引擎客户端 1控制台
　　
　　图７中，客户端vm加载了含有client.taskimpl.class.getclassloader(v1)的日志内容的类taskimpl的代码，并提供给服务端的执行引擎。图8的客户端vm加载了另一个taskimpl的代码，并发送给服务端。
　　　
　　图8. 执行引擎客户端 2控制台
　　
　　在客户端的vm中，类client.taskimpl被分别加载，初始化，并发送到服务端执行。图6还揭示了client.taskimpl的代码只在服务端的vm中加载了一次，但这“唯一的一次”却在服务端创造了许多实例并执行。或许客户端1该不高兴了因为并不是它的client.taskimpl(v1)的方法调用被服务端执行了，而是其他的一些代码。如何解决这一问题？答案就是实现定制的类加载器。
　　
　　定制类加载器
　　
　　要较好地控制类的加载，就要实现定制的类加载器。所有自定义的类加载器都应继承自java.lang.classloader。而且在构造方法中，我们也应该设置父类加载器。然后重写findclass()方法。differentversionspush文件夹包含了一个叫做filesystemclassloader的自订制的类加载器。其结构如图9所示。
　　　
　　图9. 定制类加载器关系
　　
　　以下是在common.filesystemclassloader实现的主方法：
　　
　　public byte[] findclassbytes(string classname){
　　try{
　　string pathname = currentroot +
　　
　　file.separatorchar + classname.
　　replace('.', file.separatorchar)
　　+ ".class";
　　fileinputstream infile = new
　　fileinputstream(pathname);
　　byte[] classbytes = new
　　byte[infile.available()];
　　infile.read(classbytes);
　　return classbytes;
　　}
　　catch (java.io.ioexception ioex){
　　return null;
　　}
　　}
　　public class findclass(string name)throws
　　classnotfoundexception{
　　byte[] classbytes = findclassbytes(name);
　　if (classbytes==null){
　　throw new classnotfoundexception();
　　}
　　else{
　　return defineclass(name, classbytes,
　　0, classbytes.length);
　　
　　}
　　}
　　public class findclass(string name, byte[]
　　classbytes)throws classnotfoundexception{
　　if (classbytes==null){
　　throw new classnotfoundexception(
　　"(classbytes==null)");
　　}
　　else{
　　return defineclass(name, classbytes,
　　0, classbytes.length);
　　}
　　}
　　public void execute(string codename,
　　byte[] code){
　　class klass = null;
　　try{
　　klass = findclass(codename, code);
　　taskintf task = (taskintf)
　　klass.newinstance();
　　task.execute();　　　　}
　　catch(exception exception){
　　exception.printstacktrace();
　　}
　　}
　　
　　这个类供客户端把client.taskimpl(v1)转换成字节数组，之后此字节数组被发送到rmi服务端。在服务端，一个同样的类用来把字节数组的内容转换回代码。客户端代码如下：
　　
　　public class client{
　　public static void main (string[] args){
　　try{
　　byte[] code = getclassdefinition
　　("client.taskimpl");
　　serverintf.execute("client.taskimpl",
　　code);
　　}
　　catch(remoteexception remoteexception){
　　remoteexception.printstacktrace();
　　}
　　}
　　private static byte[] getclassdefinition
　　(string codename){
　　string userdir = system.getproperties().
　　getproperty("bytepath");
　　filesystemclassloader fscl1 = null;
　　try{
　　fscl1 = new filesystemclassloader
　　(userdir);
　　}
　　catch(filenotfoundexception
　　filenotfoundexception){
　　filenotfoundexception.printstacktrace();
　　}
　　return fscl1.findclassbytes(codename);
　　}}
　　
　　在执行引擎中，从客户端收到的代码被送到定制的类加载器中。定制的类加载器把其从字节数组定义成类，实例化并执行。需要指出的是，对每一个客户请求，我们用类filesystemclassloader的不同实例来定义客户端提交的client.taskimpl。而且，client.taskimpl并不在服务端的类路径中。这也就意味着当我们在filesystemclassloader调用findclass()方法时，findclass()调用内在的defineclass()方法。类client.taskimpl被特定的类加载器实例所定义。因此，当filesystemclassloader的一个新的实例被使用，类又被重新定义为字节数组。因此，对每个客户端请求类client.taskimpl被多次定义，我们就可以在相同执行引擎jvm中执行不同的client.taskimpl的代码。
　　
　　public void execute(string codename, byte[] code)throws remoteexception{
　　filesystemclassloader filesystemclassloader = null;
　　try{
　　filesystemclassloader = new filesystemclassloader();
　　filesystemclassloader.execute(codename, code);
　　}
　　catch(exception exception){
　　throw new remoteexception(exception.getmessage());
　　}
　　}
　　
　　示例在differentversionspush文件夹下。服务端和客户端的控制台界面分别如图10，11，12所示：
　　　
　　图10. 定制类加载器执行引擎
　　
　　图10显示的是定制的类加载器控制台。我们可以看到client.taskimpl的代码被多次加载。实际上针对每一个客户端，类都被加载并初始化。
　　　
　　图11. 定制类加载器，客户端1
　　
　　图11中，含有client.taskimpl.class.getclassloader(v1)的日志记录的类taskimpl的代码被客户端的vm加载，然后送到服务端。图12 另一个客户端把包含有client.taskimpl.class.getclassloader(v1)的类代码加载并送往服务端。
　　
　　图12. 定制类加载器，客户端1
　　
　　这段代码演示了我们如