Equinox在創建Bundle的ClassLoader時，首先獲取bundle的classpath，然后執行createBCLPrevileged方法，此方法最后轉交由BaseData來創建ClassLoader。
BaseDate創建ClassLoader的關鍵代碼片段為：
| ClassLoadingHook[] hooks = adaptor.getHookRegistry().getClassLoadingHooks(); ClassLoader parent = adaptor.getBundleClassLoaderParent(); BaseClassLoader cl = null; for (int i = 0; i < hooks.length && cl == null; i++) cl = hooks[i].createClassLoader(parent, delegate, domain, this, bundleclasspath); if (cl == null) cl = new DefaultClassLoader(parent, delegate, domain, this, bundleclasspath); return cl; |
在Equinox中，默認的情況下adaptor.getBundleClassLoaderParent返回的為bootstrap classloader，可通過修改啟動的osgi.parentClassLoader 來改變這個parent classloader，
osgi.parentClassLoader 的可選值有四個，分別是：
● boot：默認
● app：SystemClassLoader
● ext：SystemClassLoader的parent
● fwk：啟動Equinox的ClassLoader
ClassLoadingHook在createClassLoader的時候都沒有做動作，因此最后ClassLoader都是通過創建DefaultClassLoader對象來構建的，其中parent參數為null，delegate參數為BundleLoader實例，bundleclasspath參數為bundle的classpath。
經過以上步驟后，完成了ClassLoader的創建，可以開始加載class了，根據上面上述，Bundle的Class就由DefaultClassLoader來完成了。
查看DefaultClassLoader的loadClass代碼，發現真正的加載class的過程是轉為調用了delegate 的findClass來完成的，delegate參數對應的為BundleLoader實例，轉為跟蹤BundleLoader的findClass方法。
BundleLoader的findClass方法的代碼片段：
| if (checkParent && parentCL != null && name.startsWith(JAVA_PACKAGE)) return parentCL.loadClass(name); |
從以上這個代碼片段，可以看到，Equinox將java.開頭的類轉交給了parent classloader去加載，這也意味著沒必要在系統中提供對外export java.開頭的package。
如果不是java.開頭的類，則交由findClassInternal方法來完成加載。
findClassInternal方法遵循的為OSGi規范中定義的Class的加載順序，不過仍然稍有改動：
1）判斷是否交由parent classloader去完成加載
在啟動Equinox時，Equinox會讀取org.osgi.framework.bootdelegation屬性，該屬性對應配置的為需要從parent classloader中加載的package，如值配置的為*，說明所有的都從parent classloader中加載 ，如值配置的為具體的package，那么則放入bootDelegation集合；如配置的為帶通配符的package，那么則放入bootDelegationStems集合。
判斷時Equinox首先判斷是否所有的都從parent classloader中加載，如是則從parent classloader中加載；
如需要加載的類的package位于bootDelegation或bootDelegationStems集合中，那么同樣從parent classloader中加載。
如不從parent classloader中加載，則進入下面的步驟。
2）嘗試調用Equinox提供的ClassLoaderDelegateHook的擴展來加載
Equinox對外提供了ClassLoaderDelegateHook的接口擴展，可編寫ClassLoaderDelegateHook的實現，注冊到Framework中，那么當有Class需要加載等動作時都會得到通知。
在默認情況下，Equinox中沒有ClassLoaderDelegateHook的實現，因此繼續下面的步驟。
3）判斷是否在import-package中，如在則交由相應的PackageSource去加載
根據Bundle配置的import-package，判斷目前需要加載的類是否在import-package中，如在則交由對應的PackageSource進行加載，PackageSource在加載時即直接交由對應的Bundle的classloader去加載，如加載的類的package在import-package中，但加載后仍然沒有找到Class，則直接拋出ClassNotFoundException，如加載到，則直接返回。
如所需要加載的類的package不在import-package中，則繼續下面的步驟。
4）嘗試從require-bundle中加載
嘗試使用require-bundle來加載，如加載到，則直接返回，如加載不到，則繼續下面的步驟。
5）嘗試從當前Bundle中加載
直到經過以上步驟的嘗試，才嘗試由當前Bundle中加載，當前Bundle加載的方法即從Bundle-Classpath或當前Bundle的Fragment中查找相應名稱的class文件，并讀取該文件進行加載，如class文件已加載，則進行緩存，再次加載時則不需要查找和解析class文件。
如從當前Bundle中仍然未找到所需的類，則繼續下面的步驟。
6）嘗試從DynamicImport-Package中加載
判斷需要找的類的package是否在DynamicImport-Package中，如果在，則交由相應的PackageSource進行加載，如PackageSource中加載不到，則拋出ClassNotFoundException；如不在DynamicImport-Package中，則繼續下面的步驟。
7）再次嘗試調用Equinox提供的ClassLoaderDelegateHook的擴展來加載
這步和第2）步相同，因此在默認情況下繼續下面的步驟。
8）嘗試使用eclipse的buddy機制來加載
Buddy機制是Eclipse的擴展，并不符合OSGi規范，因此在此不做深入分析。
9）判斷一定的條件，如符合則從parent classloader中加載
判斷的條件為：parent classloader不為null、不從parent classloader中加載、Equinox的向后兼容屬性（osgi.compatibility.bootdelegation）為true以及jvm的bug class，如滿足以上條件，則嘗試從parent classloader中加載。
如經過以上所有步驟后，仍然未找到需要加載的class，則拋出ClassNotFoundException。
從上面的代碼分析中，在Equinox中可以通過osgi.parentClassLoader、org.osgi.framework.bootdelegation來控制從Bundle ClassLoader外來加載Class，這對于集成Equinox其他容器而言，非常有用，另外，還可以通過實現ClassLoaderDelegateHook來改變Class的加載。
