Harmony Class Loader

  SUN的vm在启动时会由Luncher初始化一个extension class loader和一个application class loader，并设置当前线程上下文class loader为application class loader。Extension class loader 和 application class loader均为Luncher的内部类，分别为ExtClassLoader和AppClassLoader，ExtClassLoader的parent class loader为null，在双亲委托模式中默认其parent为BootStrapClassLoader，AppClassLoader的parent为ExtClassLoader，AppClassLoader和ExtClassLoader均继承自URLClassLoader。 

  ExtClassLoader的搜索路径通过java.ext.dirs属性指定。AppClassLoader的搜索路径通过java.class.path属性指定。ExtClassLoader在初始化的时候将java.ext.dirs指定目录下的所有Jar文件转换为URL，并初始化URLClassLoader。AppClassLoader中的URL均指向某个目录。

  而harmony并没有ExtClassLoader和AppClassLoader，他的system class loader为ClassLoader的内部类SystemClassLoader。SystemClassLoader主管java.ext.dirs和java.class.path指定的目录或jar包中的资源和类的加载。也是继承自URLClassLoader。

  URLClassLoader的工作方式。 URLClassLoader有三个重要的列表，originalUrls，handlerList，searchList。 初始化originalUrls为他的子类的搜索路径Url，handlerList为长度与originalUrls相同的空列表，searchList中存放处理过的originalUrls，searchList中把直接指向非目录的File Url转换为Jar Url，指向目录的File Url则还是File Url。findClass的过程，URLClassLoader会从handler List中依次取出handler并调用handler的findClass方法，直到某个handler返回Class，若所有handler均没有返回Class，则抛出ClassNotFound异常。handlerList会根据searchList中的Url protocol类型生成不同的handler，File类型生成URLFileHandler，Jar类型生成URLJarHandler，默认为URLHandler。

 URLFileHandler查找Class的方式为，把类在包中的路径转换为文件的路径，相对于某个特定的URL作为根目录，查看是否存在相应的Class文件。

 URLJarHandler的处理方式比较复杂。在初始化URLJarHandler的时候，以一个Jar包的URL为参数，通过此URL打开一个JarFile，URLJarHandler会预先查找该jar包是否拥有一个INDEX-LIST文件，该INDEX-LIST文件存放的是包与Jar文件的映射或者类与Jar文件的映射（虽然说会提高类查找速度，但是不见得一定会提高查找速度）。读取到的映射都会存入一个名为pre_map的Map对象。如果不存在INDEX-LIST文件，则会查找manifest中的Class-path属性，该属性指明了此jar包引用到的第三方包或者类路径，第三方包与类路径都会添加到searchList。URLJarHandler在findClass的过程中，首先会查看JarFile是否拥有该entry，如果没有，则取pre_map中查找是否有该class映射的包URL，若存在，则生成一个subHandler。在这个处理过程中，可能会发生无穷循环。当A.jar中的INDEX-LIST指向B.jar，而B.jar中的INDEX-LIST指向A.jar，且A和B中包含有相同的package C，当用户需要寻找一个package C中的D类，而A和B中都不包含D类的时候，会发生无穷循环的查找。

  Harmony中BootstrapClassLoader完全由native代码实现。URLClassLoader和BootstrapClassLoader的类查找都采用轮询的机制，可以考虑采用一个总的package和jar包的映射文件，用map查找来代替轮询。