用定製類裝入器促進編程
有人曾經說過，歷史總是在不斷地重複自身，首先是悲劇，然後是鬧劇。 最近，我第一次對此有了親身體會。我不得不向客戶交付一個可以運行的 Java 應用程序，但是我已經交付了許多次，它總是充滿了複雜性。在蒐集應用程序的所有 JAR 文件、為 DOS 和 Unix（以及 Cygwin）編寫啟動腳本、確保客戶端環境變量都指向正確位置的時候，總是有許多容易出錯的地方。如果每件事都能做好，那麼應用程序能夠按它預期的方式運行。但是在出現麻煩時（而這又是常見的情況），結果就是大量時間耗費在客戶端支持上。
最近與一個被大量 ClassNotFound異常弄得暈頭轉向的客戶交談之後，我決定自己再也不能忍受下去了。所以，我轉而尋找一個方法，可以把我的應用程序打包到單一 JAR 文件中，給我的客戶提供一個簡單的機制（比如 java -jar）來運行程序。
努力的結果就是 One-JAR，一個非常簡單的軟件打包解決方案，它利用 Java 的定製類裝入器，動態地從單一檔案文件中裝入應用程序所有的類， 同時保留支持 JAR 文件的結構。在本文中，我將介紹我開發 One-JAR 的過程，然後告訴您如何利用它在一個自包含的文件中交付您自己的可以運行的應用程序。
One-JAR 概述
在介紹 One-JAR 的細節之前，請讓我首先討論一下我構建它的目的。我確定一個 One-JAR 檔案文件應該是：
- 可以用 java -jar 機制執行。
- 能夠包含應用程序需要的 所有文件 —— 也就是說， 包括原始形式（未展開）的類和資源。
- 擁有簡單的內部結構，僅僅用 jar工具就可以被裝配起來。
- 對原來的應用程序不可見 —— 也就是說，無需修改原來的應用程序，就可以把它打包在 One-JAR 檔案文件內部。
問題和解決方案
在開發 One-JAR 的過程中，我解決的最大問題，就是如何裝入包含在另外一個 JAR 文件中的 JAR 文件。 Java 類裝入器 sun.misc.Launcher$AppClassLoader（在 java -jar開始的時候出現）只知道如何做兩件事：
- 裝入在 JAR 文件的根出現的類和資源。
- 裝入 META-INF/MANIFEST.MF 中的 Class-Path屬性指向的代碼基中的類和資源。
而且，它還故意忽略針對 CLASSPATH的全部環境變量設置，還忽略您提供的命令行參數 -cp。所以它不知道如何從一個包含在其他 JAR 文件中的 JAR 文件裝入類或資源。
顯然，我需要克服這個問題，才能實現 One-JAR 的目標。
解決方案 1：展開支持 JAR 文件
我為了創建單一可執行 JAR 文件所做的第一個嘗試，顯然就是在可交付的 JAR 文件內展開支持 JAR 文件，我們把可交付的文件稱為 main.jar。假設有一個應用程序的類叫做 com.main.Main，而且它依賴兩個類 —— com.a.A ( 在 a.jar 中 ) 和 com.b.B（在 b.jar 中），那麼 One-JAR 文件看起來應該像這樣：
main.jar | com/main/Main.class | com/a/A.class | com/b/B.class
這樣，最初來源於 a.jar 文件的 A.class丟失了， B.class也是如此。雖然這看起來只是個小問題，但卻會真正帶來問題，我很快就會解釋為什麼。
One-JAR 和 FJEP
最近發佈的一個叫做 FJEP (FatJar Eclipse Plugin) 的工具支持在 Eclipse 內部直接構建扁平 JAR 文件。 One-JAR 已經與 FatJar 集成在一起，以支持在不展開 JAR 文件的情況下嵌入 JAR 文件。請參閱 參考資料瞭解有關詳細內容。
把 JAR 文件展開到文件系統以創建一個扁平結構，這可能非常耗時。還需要使用 Ant 這樣的構建工具來展開和重新歸檔支持類。
除了這個小麻煩之外，我很快又遇到了兩個與展開支持 JAR 文件有關的嚴重問題：
- 如果 a.jar 和 b.jar 包含的資源的路徑名相同 ( 比如說，都是log4j.properties)，那麼您該選哪個？
- 如果 b.jar 的許可明確要求您在重新發布它的時候不能修改它，那您怎麼辦？您無法在不破壞許可條款的前提下像這樣展開它。
我覺得這些限制為另外一種方法提供了線索。
解決方案 2: MANIFEST Class-Path
我決定研究 java -jar 裝入器中的另外一種機制：裝入的類是在檔案文件中一個叫做 META-INF/MANIFEST.MF 的特殊文件中指定的。通過指定稱為 Class-Path的屬性，我希望能夠向啟動時的類裝入器添加其他檔案文件。下面就是這樣的一個 One-JAR 文件看起來的樣子：
main.jar | META-INF/MANIFEST.MF | + Class-Path: lib/a.jar lib/b.jar | com/main/Main.class | lib/a.jar | lib/b.jar
說明與線索
URLClassloader是sun.misc.Launcher$AppClassLoader的基類，它支持一個相當神秘的 URL 語法，讓您能夠引用 JAR 文件內部的資源。這個語法用起來像這樣： jar:file:/fullpath/main.jar!/a.resource。
從理論上講，要獲得一個在 JAR 文件 內部的 JAR 文件中的項，您必須使用像 jar:file:/fullpath/main.jar!/lib/a.jar!/a.resource這樣的方式，但是很不幸，這麼做沒有用。JAR 文件協議處理器在找 JAR 文件時，只認識最後一個 “!/” 分隔符。
但是，這個語法確實為我最終的 One-JAR 解決方案提供了線索……
這能工作麼？ 當我把 main.jar 移動到另外一個地方，並試著運行它時，好像是可以了。 為了裝配 main.jar ，我創建了一個名為 lib 的子目錄，並把 a.jar 和 b.jar 放在裡面。不幸的是，應用程序的類裝入器只從文件系統提取支持 JAR 文件，而不能從嵌入的 JAR 文件中裝入類。
為了克服這一問題，我試著用神秘的 jar:!/語法的幾種變體來使用Class-Path（請參閱 “ 說明和線索”），但是沒有一次成功。我 能做的，就只有分別交付 a.jar 和 b.jar ，並把它們與 main.jar 一起放在文件系統中了；但是這正是我想避免的那類事情。
進入 JarClassLoader
此時，我感到備受挫折。我如何才能讓應用程序從它自己的 JAR 文件中的 lib目錄裝入它自己的類呢？我決定應當創建定製類裝入器來承擔這個重任。編寫定製類裝入器不是一件容易的事情。但是實際上這個工作並沒有那麼複雜，類裝入器對它所控制的應用程序有非常深刻的影響，所以在發生故障的時候，很難診斷和解釋故障。雖然對於類裝入的完整處理超出了本文的範圍（請參閱 參考資料），我還是要介紹一些基本概念，好保證您能從後面的討論中得到最大收穫。
裝入類
當 JVM 遇到一個對象的類未知的時候，就會調用類裝入器。類裝入器的工作是找到類的字節碼（基於類的名稱），然後把這些字節傳遞給 JVM，JVM 再把這些字節碼鏈接到系統的其餘部分，使得正在運行的代碼可以使用新裝入的類。JDK 中關鍵的類是 java.lang.Classloader以及 loadClass方法，摘要如下：
public abstract class ClassLoader {
...
protected synchronized Class loadClass(String name, boolean resolve)
throws ClassNotFoundException {...}
}
ClassLoader 類的主要入口點是 loadClass()方法。您會注意到，ClassLoader是一個抽象類，但是它沒有聲明任何抽象方法，這樣，關於 loadClass()方法是不是要關注的方法，一點線索也沒留下。實際上，它 不是要關注的主方法：回到過去的好時光，看看 JDK 1.1 的類裝入器，可以看到 loadClass()是您可以有效擴展類裝入器的惟一地方，但是從 JDK 1.2 起，最好讓類裝入器單獨做它所做的工作，即以下工作：
- 檢查類是否已經裝入。
- 檢查上級類裝入器能否裝入類。
- 調用 findClass(String name)方法，讓派生的類裝入器裝入類。
ClassLoader.findClass()的實現是拋出一個新的 ClassNotFoundException異常，並且是我們實現定製類裝入器時要考慮的第一個方法。
JAR 文件何時不是 JAR 文件？
為了能夠裝入在 JAR 文件 內部的 JAR 文件中的類（這是關鍵問題，您可以回想起來），我首先必須能夠打開並讀取頂層的 JAR 文件（上面的 main.jar 文件）。現在，因為我使用的是 java -jar機制，所以 ,java.class.path系統屬性中的第一個（也是惟一一個）元素是 One-JAR 文件的完整路徑名！用下面的代碼您可以得到它：
jarName = System.getProperty("java.class.path");
我接下來的一步是遍歷應用程序的所有 JAR 文件項，並把它們裝入內存，如清單 1 所示：
清單 1. 遍歷查找嵌入的 JAR 文件
JarFile jarFile = new JarFile(jarName);
Enumeration enum = jarFile.entries();
while (enum.hasMoreElements()) {
JarEntry entry = (JarEntry)enum.nextElement();
if (entry.isDirectory()) continue;
String jar = entry.getName();
if (jar.startsWith(LIB_PREFIX) || jar.startsWith(MAIN_PREFIX)) {
// Load it!
InputStream is = jarFile.getInputStream(entry);
if (is == null)
throw new IOException("Unable to load resource /" + jar + " using " + this);
loadByteCode(is, jar);
...
注意， LIB_PREFIX生成字符串 lib/， MAIN_PREFIX生成字符串 main/。我想把任何以 lib/或 main/開始的東西的字節碼裝入內存，供類裝入器使用，並在循環中忽略任何其他 JAR 文件項。
main 目錄
前面我已經談到過 lib/ 子目錄的角色，那麼 main/ 目錄是幹什麼的呢？ 簡要來說，類裝入器的代理模式要求我把主要類 com.main.Main放在它自己的 JAR 文件中， 這樣它才能找到庫類（它依賴的庫類）。新的 JAR 文件看起來像這樣：
one-jar.jar | META-INF/MANIFEST.MF | main/main.jar | lib/a.jar | lib/b.jar
在上面的清單 1 中， loadByteCode() 方法接受來自 JAR 文件項的流和一個項名稱，把項的字節裝入內存，並根據項代表的是 類還是 資源，給它分配最多兩個名稱。演示這個技術的最好方法是通過示例。假設 a.jar 包含一個類 A.class和一個資源 A.resource。One-JAR 類裝入器構造以下 Map結構，名為JarClassLoader.byteCode，它對於類只有一對關鍵字 / 值組合，而對於資源則有兩個關鍵字。
圖 1. One-JAR 在內存中的結構
如果您多看圖 1 一會，您可以看到類項是按照類名稱設置關鍵字的，而資源關鍵字的設置則根據一對名稱：全局名稱和局部名稱。用來解析資源名稱衝突的機制是：如果兩個庫 JAR 文件都用相同的全局名稱定義一個資源，那麼則根據調用程序的堆棧幀來採用局部名稱。更多細節請參閱 參考資料。
找到類
回憶一下，我在概述類裝入的時候，最後介紹的是 findClass()方法。方法 findClass() 以類的名稱作為 String參數，而且必須找到並定義該名稱所代表的字節碼。由於 loadByteCode很好地構建了類名和字節碼之間的 Map，所以實現這個方法現在非常簡單：只要根據類名查找字節碼，然後調用defineClass()，如清單 2 所示：
清單 2. findClass() 摘要
protected Class findClass(String name) throws ClassNotFoundException {
ByteCode bytecode = (ByteCode)JarClassLoader.byteCode.get(name);
if (bytecode != null) {
...
byte bytes[] = bytecode.bytes;
return defineClass(name, bytes, pd);
}
throw new ClassNotFoundException(name);
}
裝入資源
在 One-JAR 開發期間， findClass是我把自己的想法付諸實施的第一件事。 但是，當我開始部署更復雜的應用程序時，我發現除了要裝入類之外，還必須要處理資源的裝入問題。這一次，事情有點棘手。為了查找資源，需要在 ClassLoader中找到一個合適的方法去覆蓋，我選了我最熟悉的一個，如清單 3 所示：
清單 3. getResourceAsStream() 方法
public InputStream getResourceAsStream(String name) {
URL url = getResource(name);
try {
return url != null ? url.openStream() : null;
} catch (IOException e) {
return null;
}
}
這個時候應當響起警鐘：我就是無法理解為什麼用 URL 來定位資源。所以我不用這個實現，而是插入我自己的實現，如清單 4 所示：
清單 4. One-JAR 中的 getResourceAsStream() 實現
public InputStream getResourceAsStream(String resource) {
byte bytes[] = null;
ByteCode bytecode = (ByteCode)byteCode.get(resource);
if (bytecode != null) {
bytes = bytecode.bytes;
}
...
if (bytes != null) {
return new ByteArrayInputStream(bytes);
}
...
return null;
}
最後一個障礙
我對 getResourceAsStream()方法的新實現看起來解決了問題，但是直到我試著用 One-JAR 來處理一個用 URL url = object.getClass().getClassLoader().getResource()模式裝入資源的應用程序時，才發現實際情況與想像的不一樣。為什麼？因為 ClassLoader的默認實現返回的 URL 是 null，這個結果破壞了調用程序的代碼。
這時，事情變得真的是說不清了。我必須弄清應當用什麼 URL 來引用 lib/ 目錄中的 JAR 文件內部的資源。是不是應該像 jar:file:main.jar!lib/a.jar!com.a.A.resource這樣才好？
我試盡所有我能想到的組合，但是沒有任何一個起作用。 jar:語法就是不支持嵌套 JAR 文件，這使得我的整個 One-JAR 方法好像面臨著死路一條。雖然大多數應用程序好像都不使用ClassLoader.getResource方法，但是確實有些使用了這個方法，所以我實在不願意有需要排除的情況，讓我說“如果您的應用程序使用 ClassLoader.getResource()，您就不能用 One-JAR。”
最後的解決方案……
當我試圖弄清楚 jar:語法的時候，我意外地瞭解到了 Java 運行時環境把 URL 前綴映射到處理器的機制。這成為我修復 findResource問題所需要的線索：我只要發明自己的協議前綴，稱為 onejar:。 這樣，我就能把新的前綴映射到協議處理器，處理器就會返回資源的字節流，如清單 5 所示。注意，清單 5 表示的是兩個文件中的代碼，這兩個文件是 JarClassLoader 和一個叫做com/simontuffs/onejar/Handler.java的新文件。
清單 5. findResource 和 onejar: 協議
com/simontuffs/onejar/JarClassLoader.java
protected URL findResource(String $resource) {
try {
// resolve($resource) returns the name of a resource in the
// byteCode Map if it is known to this classloader.
String resource = resolve($resource);
if (resource != null) {
// We know how to handle it.
return new URL(Handler.PROTOCOL + ":" + resource);
}
return null;
} catch (MalformedURLException mux) {
WARNING("unable to locate " + $resource + " due to " + mux);
}
return null;
}
com/simontuffs/onejar/Handler.java
package com.simontuffs.onejar;
...
public class Handler extends URLStreamHandler {
/**
* This protocol name must match the name of the package in which this class
* lives.
*/
public static String PROTOCOL = "onejar";
protected int len = PROTOCOL.length()+1;
protected URLConnection openConnection(URL u) throws IOException {
final String resource = u.toString().substring(len);
return new URLConnection(u) {
public void connect() {
}
public InputStream getInputStream() {
// Use the Boot classloader to get the resource. There
// is only one per one-jar.
JarClassLoader cl = Boot.getClassLoader();
return cl.getByteStream(resource);
}
};
}
}
啟動 JarClassLoader
到現在，您可能只剩下一個問題了：我是怎樣把 JarClassLoader插入啟動順序，讓它首先開始從 One-JAR 文件裝入類的？具體的細節超出了本文的範圍；但是，基本上說，我沒有用主類 com.main.Main作為META-INF/MANIFEST.MF/Main-Class屬性，而是創建了一個新的啟動主類com.simontuffs.onejar.Boot，它被指定作為 Main-Class屬性。新類要做以下工作：
- 創建新的JarClassLoader。
- 用新的裝入器從 main/main.jar 裝入 com.main.Main（基於 main.jar 中的 META-INF/MANIFEST.MF Main-Class項）。
- 裝入類，用反射調用 main()，從而調用 com.main.Main.main(String[])（或者諸如main.jar/MANIFEST.MF文件中的 Main-Class的名稱）。在 One-JAR 命令行上傳遞的參數，被不加修改地傳遞到應用程序的主方法。
結束語
如果前面這些讓您頭痛，不要擔心：使用 One-JAR 要比理解它的工作方式容易得多。隨著 FatJar Eclipse 插件（請參閱 參考資料中的 FJEP）的推出， Eclipse 的用戶現在只要在嚮導中選中一個複選框，就可以創建 One-JAR 應用程序。依賴的庫被放進 lib/ 目錄，主程序和類被放進 main/main.jar，並自動寫好 META-INF/MANIFEST.MF 文件。如果您使用 JarPlug（還是請參閱 參考資料），您可以查看您構建的 JAR 文件的內部結構，並從 IDE 中啟動它。
總之，One-JAR 是一個簡單而強大的解決方案，解決了應用程序打包交付的問題。但是，它沒有解決所有的應用程序場景。例如，如果您的應用程序使用老式的 JDK 1.1 的類裝入器，不把裝入委託給上一層，那麼類裝入器就無法在嵌套 JAR 文件中找到類。您可以構建和部署一個“包裝”類裝入器來修改頑固的類裝入器，從而克服這個問題，不過這可能需要與 Javassist 或者字節碼工程庫（Byte Code Engineering Library，BCEL）這樣的工具一起使用字節碼操縱技術。
對於嵌入式應用程序和 Web 服務器使用的特定類型的類裝入器，您還可能遇到問題。特別是對於那些不把裝入工作先委託給上一級的類裝入器，以及那些在文件系統中查找代碼基的裝入器，您可能會碰到問題。不過，One-JAR 中包含了一個機制，可以在文件系統中展開 JAR 文件項，這應當有幫助。這個機制由 META-INF/MANIFEST.MF 文件中的 One-JAR-Expand屬性控制。另外，您可以試著用字節碼操縱技術動態地修改類裝入器，這樣可以不破壞支持 JAR 文件的完整性。如果您採用這種方法，那麼每種個別情況可能都需要一個定製的包裝類裝入器。
