EL (Byte Code Engineering Library:字节码工程库),它提供了运行时创建类的捷径。BCEL已经被成功地使用在以下方面:编译器,优化器,混淆器,代码产生器及其他分析工具。一旦字节码被检索,此方法就会调用defineClass()方法,此行为对不同的类加载实例是有差异的。因此,如果两个类加载实例从同一个来源定义一个类,所定义的结果是不同的。
JAVA语言规范(Java language specification)详细解释了JAVA执行引擎中的类或接口的加载(loading),链接(linking)或初始化(initialization)过程。
图一显示了一个主类称为MyMainClass的应用
程序。依照之前的阐述,MyMainClass.class会被AppClassLoader加载。 MyMainClass创建了两个类加载器的实例:CustomClassLoader1 和 CustomClassLoader2,他们可以从某数据源(比如
网络)获取名为Target的字节码。这表示类Target的类定义不在应用程序类路径或扩展类路径。在这种情况下,如果MyMainClass想要用自定义的类加载器加载Target类,CustomClassLoader1和CustomClassLoader2会分别独立地加载并定义Target.class类。这在java中有重要的意义。如果Target类有一些静态的初始化代码,并且假设我们只希望这些代码在JVM中只执行一次,而这些代码在我们目前的步骤中会执行两次??分别被不同的CustomClassLoaders加载并执行。如果类Target被两个CustomClassLoaders加载并创建两个实例Target1和Target2,如图一显示,它们不是类型兼容的。换句话说,在JVM中无法执行以下代码:
Target target3 = (Target) target2;
以上代码会抛出一个ClassCastException。这是因为JVM把他们视为分别不同的类,因为他们被不同的类加载器所定义。这种情况当我们不是使用两个不同的类加载器CustomClassLoader1 和 CustomClassLoader2,而是使用同一个类加载器CustomClassLoader的不同实例时,也会出现同样的错误。这些会在本文后边用具体代码说明。
图1. 在同一个JVM中多个类加载器加载同一个目标类
为什么我们需要我们自己的类加载器
原因之一为开发者写自己的类加载器来控制JVM中的类加载行为,java中的类靠其包名和类名来标识,对于实现了java.io.Serializable接口的类,serialVersionUID扮演了一个标识类版本的重要角色。这个唯一标识是一个类名、接口名、成员方法及属性等组成的一个64位的哈希字段,而且也没有其他快捷的方式来标识一个类的版本。严格说来,如果以上的都匹配,那么则属于同一个类。
但是让我们思考如下情况:我们需要开发一个通用的执行引擎。可以执行实现某一特定接口的任何任务。当任务被提交到这个引擎,首先需要加载这个任务的代码。假设不同的客户对此引擎提交了不同的任务,凑巧,这些所有的任务都有一个相同的类名和包名。现在面临的
问题就是这个引擎是否可以针对不同的用户所提交的信息而做出不同的反应。这一情况在下文的参考一节有可供下载的代码样例,samepath 和 differentversions,这两个目录分别
演示了这一概念。 图2 显示了文件目录结构,有三个子目录samepath, differentversions, 和 differentversionspush,里边是例子:
图2. 文件夹结构组织示例
在samepath 中,类version.Version保存在v1和v2两个子目录里,两个类具有同样的类名和包名,唯一不同的是下边这行:
public void fx(){ log("this =
" + this + "; Version.fx(1)."); }
V1中,日志记录中有Version.fx(1),而在v2中则是Version.fx(2)。把这个两个存在细微不同的类放在一个classpath下,然后运行Test类:
set CLASSPATH=.;%CURRENT_ROOT%\v1;%CURRENT_ROOT%\v2%JAVA_HOME%\bin\java Test
图3显示了控制台输出。我们可以看到对应着Version.fx(1