ClassLoader的几个概念、类和对象的解释 （ZT)

返回0表示编译成功，字符串数组as则是我们用javac命令编译时的参数，以空格划分。例如：
　　javac -classpath c:"foo"bar.jar;. -d c:" c:"Some.java
　　则字符串数组as为{"-classpath","c:""foo""bar.jar;.","-d","c:""","c:""Some.java"}，如果带有PrintWriter参数，则会把编译信息出到这个指定的printWriter中。默认的输出是System.err。
　　
　　其中 Main是由JVM使用Launcher初始化的system classloader载入的，根据全盘负责原则，编译器在解析这个java源文件时所发现的它所依赖和引用的所有Class也将由system classloader载入，如果system classloader不能载入某个Class时，编译器将抛出一个“cannot resolve symbol”错误。
　　
　　所以首先编译就通不过，也就是编译器无法编译一个引用了不在CLASSPATH中的未知Class的java源文件，而由于拼写错误或者没有把所需类库放到CLASSPATH中，大家一定经常看到这个“cannot resolve symbol”这个编译错误吧！
　　
　　其次，就是我们把这个Class放到编译路径中，成功的进行了编译，然后在运行的时候不把它放入到CLASSPATH中而利用我们自己的 classloader来动态载入这个Class，这时候也会出现“java.lang.NoClassDefFoundError”的违例，为什么呢？
　　
　　我们再来分析一下，首先调用这个造型语句的可执行的Class一定是由JVM使用Launcher初始化的system classloader载入的，根据全盘负责原则，当我们进行造型的时候，JVM也会使用system classloader来尝试载入这个Class来对实例进行造型，自然在system classloader寻找不到这个Class时就会抛出“java.lang.NoClassDefFoundError”的违例。
　　
　　OK，现在让我们来总结一下，java文件的编译和Class的载入执行，都是使用Launcher初始化的system classloader作为类载入器的，我们无法动态的改变system classloader，更无法让JVM使用我们自己的classloader来替换system classloader，根据全盘负责原则，就限制了编译和运行时，我们无法直接显式的使用一个system classloader寻找不到的Class，即我们只能使用Java核心类库，扩展类库和CLASSPATH中的类库中的Class。
　　
　　还不死心！再尝试一下这种情况，我们把这个Class也放入到CLASSPATH中，让system classloader能够识别和载入。然后我们通过自己的classloader来从指定的class文件中载入这个Class（不能够委托 parent载入，因为这样会被system classloader从CLASSPATH中将其载入），然后实例化一个Object，并造型成这个Class，这样JVM也识别这个Class（因为 system classloader能够定位和载入这个Class从CLASSPATH中），载入的也不是CLASSPATH中的这个Class，而是从 CLASSPATH外动态载入的，这样总行了吧！十分不幸的是，这时会出现“java.lang.ClassCastException”违例。
　　
　　为什么呢？我们也来分析一下，不错，我们虽然从CLASSPATH外使用我们自己的classloader动态载入了这个Class，但将它的实例造型的时候是JVM会使用system classloader来再次载入这个Class，并尝试将使用我们的自己的classloader载入的Class的一个实例造型为system classloader载入的这个Class（另外的一个）。大家发现什么问题了吗？也就是我们尝试将从一个classloader载入的Class的一个实例造型为另外一个classloader载入的Class，虽然这两个Class的名字一样，甚至是从同一个class文件中载入。但不幸的是JVM 却认为这个两个Class是不同的，即JVM认为不同的classloader载入的相同的名字的Class（即使是从同一个class文件中载入的）是不同的！这样做的原因我想大概也是主要出于安全性考虑，这样就保证所有的核心Java类都是system classloader载入的，我们无法用自己的classloader载入的相同名字的Class的实例来替换它们的实例。
　　
　　看到这里，聪明的读者一定想到了该如何动态载入我们的Class，实例化，造型并调用了吧！
　　
　　那就是利用面向对象的基本特性之一的多形性。我们把我们动态载入的Class的实例造型成它的一个system classloader所能识别的父类就行了！这是为什么呢？我们还是要再来分析一次。当我们用我们自己的classloader来动态载入这我们只要把这个Class的时候，发现它有一个父类Class，在载入它之前JVM先会载入这个父类Class，这个父类Class是system classloader所能识别的，根据委托机制，它将由system classloader载入，然后我们的classloader再载入这个Class，创建一个实例，造型为这个父类Class，注意了，造型成这个父类 Class的时候（也就是上溯）是面向对象的java语言所允许的并且JVM也支持的，JVM就使用system classloader再次载入这个父类Class，然后将此实例造型为这个父类Class。大家可以从这个过程发现这个父类Class都是由 system classloader载入的，也就是同一个class loader载入的同一个Class，所以造型的时候不会出现任何异常。而根据多形性，调用这个父类的方法时，真正执行的是这个Class（非父类 Class）的覆盖了父类方法的方法。这些方法中也可以引用system classloader不能识别的Class，因为根据全盘负责原则，只要载入这个Class的classloader即我们自己定义的 classloader能够定位和载入这些Class就行了。
　　
　　这样我们就可以事先定义好一组接口或者基类并放入CLASSPATH中，然后在执行的时候动态的载入实现或者继承了这些接口或基类的子类。还不明白吗？让我们来想一想Servlet吧，web application server能够载入任何继承了Servlet的Class并正确的执行它们，不管它实际的Class是什么，就是都把它们实例化成为一个Servlet Class，然后执行Servlet的init，doPost，doGet和destroy等方法的,而不管这个Servlet是从web- inf/lib和web-inf/classes下由system classloader的子classloader(即定制的classloader)动态载入。说了这么多希望大家都明白了。在applet,ejb等容器中,都是采用了这种机制.
　　
　　对于以上各种情况，希望大家实际编写一些example来实验一下。
　　
　　最后我再说点别的，classloader虽然称为类加载器，但并不意味着只能用来加载Class，我们还可以利用它也获得图片，音频文件等资源的URL，当然，这些资源必须在CLASSPATH中的jar类库中或目录下。我们来看API的doc中关于ClassLoader的两个寻找资源和Class的方法描述吧：
　　public URL getResource(String name)
　　用指定的名字来查找资源，一个资源是一些能够被class代码访问的在某种程度上依赖于代码位置的数据（图片，音频，文本等等）。
　　 一个资源的名字是以'/'号分隔确定资源的路径名的。
　　 这个方法将先请求parent classloader搜索资源，如果没有parent，则会在内置在虚拟机中的classloader（即bootstrap classloader）的路径中搜索。如果失败，这个方法将调用findResource(String)来寻找资源。
　　public static URL getSystemResource(String name)
　　 从用来载入类的搜索路径中查找一个指定名字的资源。这个方法使用system class loader来定位资源。即相当于ClassLoader.getSystemClassLoader().getResource(name)。
　　
　　例如：
　　 System.out.println(ClassLoader.getSystemResource("java/lang/String.class"));
　　的结果为：
　　 jar:file:/C:/j2sdk1.4.1_01/jre/lib/rt.jar!/java/lang/String.class
　　表明String.class文件在rt.jar的java/lang目录中。
　　因此我们可以将图片等资源随同Class一同打包到jar类库中（当然，也可单独打包这些资源）并添加它们到class loader的搜索路径中，我们就可以无需关心这些资源的具体位置，让class loader来帮我们寻找了！
　　
　　以上是转自bea论坛的一篇文章，作者不清楚，估计是bea内部的大牛。是值得俺们顶礼膜拜的神一般的存在 XD
　　
　　
　　最后 附上自己的几点理解
　　
　　bootstrap classloader ------- 对应jvm中某c++写的dll类
　　Extenson ClassLoader ---------对应内部类ExtClassLoader
　　System ClassLoader ---------对应内部类AppClassLoader
　　Custom ClassLoader ----------对应任何URLClassLoader的子类（你也可以继承SecureClassLoader或者更加nb一点 直接继承ClassLoader，这样的话你也是神一般的存在了 XD）
　　
　　
　　以上四种classloder按照从上到下的顺序，依次为下一个的parent
　　
　　这个第一概念
　　
　　第二个概念是几个有关的classloader的类
　　
　　 抽象类 ClassLoader
　　 |
　　 SecureClassLoader
　　 |
　　 URLClassloader
　　 | |
　　 sun的ExtClassLoader sun的AppClassLoader
　　以上的类之间是继承关系，与第一个概念说的parent是两回事情，需要小心。
　　
　　第三个概念是Thread的ContextClassLoader
　　其实从Context的名称就可以看出来，这只是一个用以存储任何classloader引用的临时存储空间，与classloader的层次没有任何关系。
　　
　　
　　第四 就是如何实现自己的classloader了，本来是要翻译另外一篇文章Find a way out of the ClassLoader maze
　　不过今天时间都花在《小夫妻天天恶战》这篇神文上了 XD 强烈推荐任何和俺一样期望彪悍人生的朋友都去看看
　　
　　翻译明天补上，浪费时间是可耻的 XD
　　
　　匿鸟，晚上还有朋友推荐的 《lie with me》（与我同眠）要看。XD