OSGi和普通java工程中各个classloader的区别

OSGI框架下

this.getClass().getClassLoader() =  org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@186c6b2

Thread.currentThread().getContextClassLoader() = org.eclipse.core.runtime.internal.adaptor.ContextFinder@16b13c7

ClassLoader.getSystemClassLoader() = sun.misc.Launcher$AppClassLoader@19821f

在普通java程序中
this.getClass().getClassLoader() =  sun.misc.Launcher$AppClassLoader@19821f

Thread.currentThread().getContextClassLoader() = sun.misc.Launcher$AppClassLoader@19821f

ClassLoader.getSystemClassLoader() = sun.misc.Launcher$AppClassLoader@19821f

由此我们可以看出，在OSGi框架下，如果动态加载不在本bundle bin目录下的类的话，只有使用ClassLoader.getSystemClassLoader()。

而且经过试验发现在OSGi框架下，使用其他两个class loader加载非bin目录（本bundle默认类输出路径），即使给出绝对路径，系统也会出现找不到该类的异常。

而且要注意，在OSGi下，编译的时候this.getClass().getClassLoader() 和Thread.currentThread().getContextClassLoader() 可以像普通java工程一样赋值给一个urlclassloader，但是在运行的时候会出现不能强制类型转换的异常。这点分析可知，osgi框架下的this.getClass().getClassLoader() 和Thread.currentThread().getContextClassLoader() 与一般java下的这两个loader是不一样的。在以后用的时候还得多加注意。