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是不一樣的。在以後用的時候還得多加註意。