體驗Java 1.5中面向(AOP)編程_JSP編程

對於一個能夠訪問原始碼的經驗豐富的Java開發人員來說，任何程式都可以被看作是博物館裡透明的模型。類似線程轉儲（dump）、方法調用跟蹤、斷點、切面（profiling）統計表等工具可以讓我們瞭解程式目前正在執行什麼操作、剛才做了什麼操作、未來將做什麼操作。但是在產品環境中情況就沒有那麼明顯了，這些工具一般是不能夠使用的，或最多隻能由受過訓練的開發人員使用。支援小組和終端使用者也需要知道在某個時刻應用程式正在執行什麼操作。

　　為了填補這個空缺，我們已經發明了一些簡單的替代品，例如記錄檔（典型情況下用於伺服器處理）和狀態條（用於GUI應用程式）。但是，由於這些工具只能捕捉和報告可用資訊的一個很小的子集，並且通常必須把這些資訊用容易理解的方式表現出來，所以程式員趨向於把它們明確地編寫到應用程式中。而這些代碼會纏繞著應用程式的商務邏輯，當開發人員試圖調試或瞭解核心功能的時候，他們必須"圍繞這些代碼工作"，而且還要記得功能發生改變後更新這些代碼。我們希望實現的真正功能是把狀態報表集中在某個位置，把單個狀態訊息作為中繼資料（metadata）來管理。

　　在本文中我將考慮使用嵌入GUI應用程式中的狀態條組件的情形。我將介紹多種實現這種狀態報表的不同方法，從傳統的寫入程式碼習慣開始。隨後我會介紹Java 1.5的大量新特性，包括註解（annotation）和運行時位元組碼重構（instrumentation）。

　　狀態管理器（StatusManager）

　　我的主要目標是建立一個可以嵌入GUI應用程式的JStatusBar Swing組件。圖1顯示了一個簡單的Jframe中狀態條的樣式。
　　 　　 圖1.我們動態產生的狀態條
　　由於我不希望直接在商務邏輯中引用任何GUI組件，我將建立一個StatusManager（狀態管理器）來充當狀態更新的進入點。實際的通知會被委託給StatusState對象，因此以後可以擴充它以支援多個並發的線程。圖2顯示了這種安排。
　　
圖2. StatusManager和JstatusBar

　　現在我必須編寫代碼調用StatusManager的方法來報告應用程式的進程。典型情況下，這些方法調用都分散地貫穿於try-finally代碼塊中，通常每個方法一個調用。 　　

　　public void connectToDB (String url) {
　　　StatusManager.push("Connecting to database");
　　　try {
　　　　...
　　　} finally {
　　　　StatusManager.pop();
　　　}
　　}

　　這些代碼實現了我們所需要功能，但是在程式碼程式庫中數十次、甚至於數百次地複製這些代碼之後，它看起來就有些混亂了。此外，如果我們希望用一些其它的方式訪問這些訊息該怎麼辦呢？在本文的後面部分中，我將定義一個方便使用的例外處理常式，它共用了相同的訊息。問題是我把狀態訊息隱藏在方法的實現之中了，而沒有把訊息放在訊息所屬的介面中。

　　面向屬性編程

　　我真正想實現的操作是把對StatusManager的引用都放到代碼外面的某個地方，並簡單地用我們的訊息標記這個方法。接著我可以使用代碼產生（code-generation）或運行時反省（introspection）來執行真正的工作。XDoclet項目把這種方法歸納為面向屬性編程（Attribute-Oriented Programming），它還提供了一個架構組件，可以把自訂的類似Javadoc的標記轉換到原始碼之中。

　　但是，JSR-175包含了這樣的內容，Java 1.5為了包含真實代碼中的這些屬性提供了一種結構化程度更高的格式。這些屬性被稱為"註解（annotations）"，我們可以使用它們為類、方法、欄位或變數定義提供中繼資料。它們必須被顯式聲明，並提供一組可以包含任意常量值（包括原語、字串、枚舉和類）的名稱-值對（name-value pair）。

　　註解（Annotations）

　　為了處理狀態訊息，我希望定義一個包含字串值的新註解。註解的定義非常類似介面的定義，但是它用@interface關鍵字代替了interface，並且只支援方法（儘管它們的功能更像欄位）： 　　

　　public @interface Status {
　　　String value();
　　}

　　與介面類似，我把@interface放入一個叫做Status.java的檔案中，並把它匯入到任何需要引用它的檔案中。

　　對我們的欄位來說，value可能是個奇怪的名稱。類似message的名稱可能更適合；但是，value對於Java來說具有特殊的意義。它允許我們使用@Status("...")代替@Status(value="...")來定義註解，這明顯更加簡捷。

　　我現在可以使用下面的代碼定義自己的方法：

　　@Status("Connecting to database")
　　public void connectToDB (String url) {
　　...
　　}

　　請注意，我們在編譯這段代碼的時候必須使用-source 1.5選項。如果你使用Ant而不是直接使用javac命令列建立應用程式，那麼你需要使用Ant 1.6.1以上版本。

　　作為類、方法、欄位和變數的補充，註解也可以用於為其它的註解提供中繼資料。特別地，Java引入了少量註解，你可以使用這些註解來定製你自己的註解的工作方式。我們用下面的代碼重新定義自己的註解：

　　@Target(ElementType.METHOD)
　　@Retention(RetentionPolicy.SOURCE)
　　public @interface Status {
　　String value();
　　}

　　@Target註解定義了@Status註解可以引用什麼內容。理想情況下，我希望標記大塊的代碼，但是它的選項只有方法、欄位、類、本地變數、參數和其它註解。我只對代碼感興趣，因此我選擇了METHOD（方法）。

　　@Retention註解允許我們指定Java什麼時候可以自主地拋棄訊息。它可能是SOURCE（在編譯時間拋棄）、CLASS（在類載入時拋棄）或RUNTIME（不拋棄）。我們先選擇SOURCE，但是在本文後部我們會更新它。

    重構原始碼

　　現在我的訊息都被編碼放入中繼資料中了，我必須編寫一些代碼來通知狀態監聽程式。假設在某個時候，我繼續把connectToDB方法儲存原始碼控制項中，但是卻沒有對StatusManager的任何引用。但是，在編譯這個類之前，我希望加入一些必要的調用。也就是說，我希望自動地插入try-finally語句和push/pop調用。

　　XDoclet架構組件是一種Java原始碼產生引擎，它使用了類似上述的註解，但是把它們儲存在Java原始碼的注釋（comment）中。XDoclet產生整個Java類、設定檔或其它建立的部分的時候非常完美，但是它不支援對已有Java類的修改，而這限制了重構的有效性。作為代替，我可以流量分析工具（例如JavaCC或ANTLR，它提供了分析Java原始碼的文法基礎），但是這需要花費大量精力。

　　看起來沒有什麼可以用於Java代碼的原始碼重構的很好的工具。這類工具可能有市場，但是你在本文的後面部分可以看到，位元組碼重構可能是一種更強大的技術。 重構位元組碼

　　不是重構原始碼然後編譯它，而是編譯原始的原始碼，然後重構它所產生的位元組碼。這樣的操作可能比原始碼重構更容易，也可能更加複雜，而這依賴於需要的準確轉換。位元組碼重構的主要優點是代碼可以在運行時被修改，不需要使用編譯器。

　　儘管Java的位元組碼格式相對簡單，我還是希望使用一個Java類庫來執行位元組碼的分析和產生（這可以把我們與未來Java類檔案格式的改變隔離開來）。我選擇了使用Jakarta的Byte Code Engineering Library（位元組碼引擎類庫，BCEL），但是我還可以選用CGLIB、ASM或SERP。

　　由於我將使用多種不同的方式重構位元組碼，我將從聲明重構的通用介面開始。它類似於執行基於註解重構的簡單架構組件。這個架構組件基於註解，將支援類和方法的轉換，因此該介面有類似下面的定義：　　

　　public interface Instrumentor
　　{
　　　public void instrumentClass (ClassGen classGen,Annotation a);
　　　public void instrumentMethod (ClassGen classGen,MethodGen methodGen,Annotation a);
　　}

　　ClassGen和MethodGen都是BCEL類，它們使用了Builder模式（pattern）。也就是說，它們為改變其它不可變的（immutable）對象、以及可變的和不可變的表現（representation）之間的轉換提供了方法。

　　現在我需要為介面編寫實現，它必須用恰當的StatusManager調用更換@Status註解。前面提到，我希望把這些調用包含在try-finally代碼塊中。請注意，要達到這個目標，我們所使用的註解必須用@Retention(RetentionPolicy.CLASS)進行標記，它指示Java編譯器在編譯過程中不要拋棄註解。由於在前面我把@Status聲明為@Retention(RetentionPolicy.SOURCE)的，我必須更新它。

　　在這種情況下，重構位元組碼明顯比重構原始碼更複雜。其原因在於try-finally是一種僅僅存在於原始碼中的概念。Java編譯器把try-finally代碼塊轉換為一系列的try-catch代碼塊，並在每一個返回之前插入對finally代碼塊的調用。因此，為了把try-finally代碼塊添加到已有的位元組碼中，我也必須執行類似的事務。

　　下面是表現一個普通方法調用的位元組碼，它被StatusManager更新環繞著：　　

　　0: ldc #2; //字串訊息
　　2: invokestatic #3; //方法StatusManager.push:(LString;)V
　　5: invokestatic #4; //方法 doSomething:()V
　　8: invokestatic #5; //方法 StatusManager.pop:()V
　　11: return

　　下面是相同的方法調用，但是位於try-finally代碼塊中，因此，如果它產生了異常會調用StatusManager.pop()：　　

　　0: ldc #2; //字串訊息
　　2: invokestatic #3; //方法 StatusManager.push:(LString;)V
　　5: invokestatic #4; //方法 doSomething:()V
　　8: invokestatic #5; //方法 StatusManager.pop:()V
　　11: goto 20
　　14: astore_0
　　15: invokestatic #5; //方法 StatusManager.pop:()V
　　18: aload_0
　　19: athrow
　　20: return　　

　　Exception table:
　　from to target type
　　5 8 14 any

　　14 15 14 any

　　你可以發現，為了實現一個try-finally，我必須複製一些指令，並添加了幾個跳轉和異常表記錄。幸運的是，BCEL的InstructionList類使這種工作相當簡單。

　　在運行時重構位元組碼

　　現在我擁有了一個基於註解修改類的介面和該介面的具體實現了，下一步是編寫調用它的實際架構組件。實際上我將編寫少量的架構組件，先從運行時重構所有類的架構組件開始。由於這種操作會在build過程中發生，我決定為它定義一個Ant事務。build.xml檔案中的重構目標的聲明應該如下：　　

　　＜instrument class="com.pkg.OurInstrumentor"＞
　　＜fileset dir="$(classes.dir)"＞
　　＜include name="**/*.class"/＞
　　＜/fileset＞
　　＜/instrument＞

　　為了實現這種事務，我必須定義一個實現org.apache.tools.ant.Task介面的類。我們的事務的屬性和子項目（sub-elements）都是通過set和add方法調用傳遞進來的。我們調用執行（execute）方法來實現事務所要執行的工作--在樣本中，就是重構＜fileset＞中指定的類檔案。 

　　public class InstrumentTask extends Task {
　　　...
　　　public void setClass (String className) { ... }
　　　public void addFileSet (FileSet fileSet) { ... }　　

　　　public void execute () throws BuildException {
　　　　Instrumentor inst = getInstrumentor();
　　try {
　　　　　DirectoryScanner ds =fileSet.getDirectoryScanner(project);
　　　　　// Java 1.5 的"for" 文法
　　　　　for (String file : ds.getIncludedFiles()) {
　　　　　　instrumentFile(inst, file);
　　　　　}
　　　　} catch (Exception ex) {
　　　　　throw new BuildException(ex);
　　　　}
　　　}
　　　...
　　}

　　用於該項操作的BCEL 5.1版本有一個問題--它不支援分析註解。我可以載入正在重構的類並使用反射（reflection）查看註解。但是，如果這樣，我就不得不使用RetentionPolicy.RUNTIME來代替RetentionPolicy.CLASS。我還必須在這些類中執行一些靜態初始化，而這些操作可能載入本地類庫或引入其它的依賴關係。幸運的是，BCEL提供了一種外掛程式（plugin）機制，它允許用戶端分析位元組碼屬性。我編寫了自己的AttributeReader的實現（implementation），在出現註解的時候，它知道如何分析插入位元組碼中的RuntimeVisibleAnnotations和RuntimeInvisibleAnnotations屬性。BCEL未來的版本應該會包含這種功能而不是作為外掛程式提供。

　　編譯時間刻的位元組碼重構方法顯示在範例程式碼的code/02_compiletime目錄中。

　　但是這種方法有很多缺陷。首先，我必須給建立過程增加額外的步驟。我不能基於命令列設定或其它編譯時間沒有提供的資訊來決定開啟或關閉重構作業。如果重構的或沒有重構的代碼需要同時在產品環境中運行，那麼就必須建立兩個單獨的.jars檔案，而且還必須決定使用哪一個。

    在類載入時重構位元組碼

　　更好的方法可能是延遲位元組碼重構作業，直到位元組碼被載入的時候才進行重構。使用這種方法的時候，重構的位元組碼不用儲存起來。我們的應用程式啟動時刻的效能可能會受到影響，但是你卻可以基於自己的系統屬性或運行時配置資料來控制進行什麼操作。

　　Java 1.5之前，我們使用定製的類載入程式可能實現這種類檔案維護操作。但是Java 1.5中新增加的java.lang.instrument程式包提供了少數附加的工具。特別地，它定義了ClassFileTransformer的概念，在標準的載入過程中我們可以使用它來重構一個類。

　　為了在適當的時候（在載入任何類之前）註冊ClassFileTransformer，我需要定義一個premain方法。Java在載入主類（main class）之前將調用這個方法，並且它傳遞進來對Instrumentation對象的引用。我還必須給命令列增加-javaagent參數選項，告訴Java我們的premain方法的資訊。這個參數選項把我們的agent class（代理類，它包含了premain方法）的全名和任一字元串作為參數。在例子中我們把Instrumentor類的全名作為參數（它必須在同一行之中）：

　　-javaagent:boxpeeking.instrument.InstrumentorAdaptor=
　　boxpeeking.status.instrument.StatusInstrumentor

　　現在我已經安排了一個回調（callback），它在載入任何含有註解的類之前都會發生，並且我擁有Instrumentation對象的引用，可以註冊我們的ClassFileTransformer了：

　　public static void premain (String className,
　　Instrumentation i)
　　throws ClassNotFoundException,
　　InstantiationException,
　　IllegalAccessException
　　{
　　　Class instClass = Class.forName(className);
　　　Instrumentor inst = (Instrumentor)instClass.newInstance();
　　　i.addTransformer(new InstrumentorAdaptor(inst));
　　}

　　我們在此處註冊的適配器將充當上面給出的Instrumentor介面和Java的ClassFileTransformer介面之間的橋樑。 　　

　　public class InstrumentorAdaptor
　　implements ClassFileTransformer
　　{
　　　public byte[] transform (ClassLoader cl,String className,Class classBeingRedefined,
　　ProtectionDomain protectionDomain,byte[] classfileBuffer)
　　　{
　　　　try {
　　　　　ClassParser cp =new ClassParser(new ByteArrayInputStream(classfileBuffer),className + ".java");
　　　　　JavaClass jc = cp.parse();
　　　ClassGen cg = new ClassGen(jc);
　　　for (Annotation an : getAnnotations(jc.getAttributes())) {
　　　　　　instrumentor.instrumentClass(cg, an);
　　　　　}
　　　for (org.apache.bcel.classfile.Method m : cg.getMethods()) {
　　　　　　for (Annotation an : getAnnotations(m.getAttributes())) {
　　　　　　　ConstantPoolGen cpg =cg.getConstantPool();
　　　　　　　MethodGen mg =new MethodGen(m, className, cpg);
　　　　　　　instrumentor.instrumentMethod(cg, mg, an);
　　　　　　　mg.setMaxStack();
　　　　　　　mg.setMaxLocals();
　　　　　　　cg.replaceMethod(m, mg.getMethod());
　　　　　　}
　　　　　}
　　　　　JavaClass jcNew = cg.getJavaClass();
　　　　　return jcNew.getBytes();
　　　　} catch (Exception ex) {
　　　　　throw new RuntimeException("instrumenting " + className, ex);
　　　　}
　　　}
　　　...
　　}

　　這種在啟動時重構位元組碼的方法位於在樣本的/code/03_startup目錄中。

　　異常的處理

　　文章前面提到，我希望編寫附加的代碼使用不同目的的@Status註解。我們來考慮一下一些額外的需求：我們的應用程式必須捕捉所有的未處理異常並把它們顯示給使用者。但是，我們不是提供Java堆疊追蹤，而是顯示擁有@Status註解的方法，而且還不應該顯示任何代碼（類或方法的名稱或行號等等）。

　　例如，考慮下面的堆疊追蹤資訊：

　　java.lang.RuntimeException: Could not load data for symbol IBM
　　at boxpeeking.code.YourCode.loadData(Unknown Source)
　　at boxpeeking.code.YourCode.go(Unknown Source)
　　at boxpeeking.yourcode.ui.Main+2.run(Unknown Source)
　　at java.lang.Thread.run(Thread.java:566)
　　Caused by: java.lang.RuntimeException: Timed out
　　at boxpeeking.code.YourCode.connectToDB(Unknown Source)

　　... 更多資訊

　　這將導致圖1中所示的GUI彈出框，上面的例子假設你的YourCode.loadData()、YourCode.go()和YourCode.connectToDB()都含有@Status註解。請注意，異常的次序是相反的，因此使用者最先得到的是最詳細的資訊。　　

　　 圖3.顯示在錯誤對話方塊中的堆疊追蹤資訊

　　為了實現這些功能，我必須對已有的代碼進行稍微的修改。首先，為了確保在運行時@Status註解是可以看到的，我就必須再次更新@Retention，把它設定為@Retention(RetentionPolicy.RUNTIME)。請記住，@Retention控制著JVM什麼時候拋棄註解資訊。這樣的設定意味著註解不僅可以被編譯器插入位元組碼中，還能夠使用新的Method.getAnnotation(Class)方法通過反射來進行訪問。

　　現在我需要安排接收代碼中沒有明確處理的任何異常的通知了。在Java 1.4中，處理任何特定線程上未處理異常的最好方法是使用ThreadGroup子類並給該類型的ThreadGroup添加自己的新線程。但是Java 1.5提供了額外的功能。我可以定義UncaughtExceptionHandler介面的一個執行個體，並為任何特定的線程（或所有線程）註冊它。

　　請注意，在例子中為特定異常註冊可能更好，但是在Java 1.5.0beta1（#4986764）中有一個bug，它使這樣操作無法進行。但是為所有線程設定一個處理常式是可以工作的，因此我就這樣操作了。

　　現在我們擁有了一種截取未處理異常的方法了，並且這些異常必須被報告給使用者。在GUI應用程式中，典型情況下這樣的操作是通過彈出一個包含整個堆疊追蹤資訊或簡單訊息的強制回應對話方塊來實現的。在例子中，我希望在產生異常的時候顯示一個訊息，但是我希望提供堆棧的@Status描述而不是類和方法的名稱。為了實現這個目的，我簡單地在Thread的StackTraceElement數組中查詢，找到與每個架構相關的java.lang.reflect.Method對象，並查詢它的堆棧註解列表。不幸的是，它只提供了方法的名稱，沒有提供方法的特徵量（signature），因此這種技術不支援名稱相同的（但@Status註解不同的）重載方法。

　　實現這種方法的範例程式碼可以在peekinginside-pt2.tar.gz檔案的/code/04_exceptions目錄中找到。 

    取樣（Sampling）

　　我現在有辦法把StackTraceElement數群組轉換為@Status註解堆棧。這種操作比表明看到的更加有用。Java 1.5中的另一個新特性--線程反省（introspection）--使我們能夠從當前正在啟動並執行線程中得到準確的StackTraceElement數組。有了這兩部分資訊之後，我們就可以構造JstatusBar的另一種實現。StatusManager將不會在發生方法調用的時候接收通知，而是簡單地啟動一個附加的線程，讓它負責在正常的間隔期間抓取堆疊追蹤資訊和每個步驟的狀態。只要這個間隔期間足夠短，使用者就不會感覺到更新的延遲。

　　下面使"sampler"線程背後的代碼，它跟蹤另一個線程的經過：

　　class StatusSampler implements Runnable
　　{
　　　private Thread watchThread;　　

　　　public StatusSampler (Thread watchThread)
　　　{
　　　　this.watchThread = watchThread;
　　　}　　

　　　public void run ()
　　　{
　　　　while (watchThread.isAlive()) {
　　　　　// 從線程中得到堆疊追蹤資訊
　　　　　StackTraceElement[] stackTrace =watchThread.getStackTrace();
　　　　　// 從堆疊追蹤資訊中提取狀態訊息
　　　　　List＜Status＞ statusList =StatusFinder.getStatus(stackTrace);
　　　　　Collections.reverse(statusList);
　　　　　// 用狀態訊息建立某種狀態
　　　　　StatusState state = new StatusState();
　　　　　for (Status s : statusList) {
　　　　　　String message = s.value();
　　　　　　state.push(message);
　　　　　}

　　　// 更新當前的狀態

　　　　　StatusManager.setState(watchThread,state);

　　　　　//休眠到下一個周期

　　　　　try {
　　　　　　Thread　.sleep(SAMPLING_DELAY);
　　　　　} catch (InterruptedException ex) {}
　　　　}
　　//狀態複位
　　　　StatusManager.setState(watchThread,new StatusState());
　　　}
　　}

　　與增加方法調用、手動或通過重構相比，取樣對程式的侵害性（invasive）更小。我根本不需要改變建立過程或命令列參數，或修改啟動過程。它也允許我通過調整SAMPLING_DELAY來控制佔用的開銷。不幸的是，當方法調用開始或結束的時候，這種方法沒有明確的回調。除了狀態更新的延遲之外，沒有原因要求這段代碼在那個時候接收回調。但是，未來我能夠增加一些額外的代碼來跟蹤每個方法的準確的運行時。通過檢查StackTraceElement是可以精確地實現這樣的操作的。

　　通過線程取樣實現JStatusBar的代碼可以在peekinginside-pt2.tar.gz檔案的/code/05_sampling目錄中找到。

　　在執行過程中重構位元組碼

　　通過把取樣的方法與重構組合在一起，我能夠形成一種最終的實現，它提供了各種方法的最佳特性。預設情況下可以使用取樣，但是應用程式的花費時間最多的方法可以被個別地進行重構。這種實現根本不會安裝ClassTransformer，但是作為代替，它會一次一個地重構方法以響應取樣過程中收集到的資料。

　　為了實現這種功能，我將建立一個新類InstrumentationManager，它可以用於重構和不重構獨立的方法。它可以使用新的Instrumentation.redefineClasses方法來修改閒置類，同時代碼則可以不間斷執行。前面部分中增加的StatusSampler線程現在有了額外的職責，它把任何自己"發現"的@Status方法添加到集合中。它將周期性地找出最壞的冒犯者並把它們提供給InstrumentationManager以供重構。這允許應用程式更加精確地跟蹤每個方法的啟動和終止時刻。

　　前面提到的取樣方法的一個問題是它不能區分長時間啟動並執行方法與在迴圈中多次調用的方法。由於重構會給每次方法調用增加一定的開銷，我們有必要忽略頻繁調用的方法。幸運的是，我們可以使用重構解決這個問題。除了簡單地更新StatusManager之外，我們將維護每個重構的方法被調用的次數。如果這個數值超過了某個極限（意味著維護這個方法的資訊的開銷太大了），取樣線程將會永遠地取消對該方法的重構。

　　理想情況下，我將把每個方法的調用數量儲存在重構過程中添加到類的新欄位中。不幸的是，Java 1.5中增加的類轉換機制不允許這樣操作；它不能增加或刪除任何欄位。作為代替，我將把這些資訊儲存在新的CallCounter類的Method對象的靜態映射中。

　　這種混合的方法可以在範例程式碼的/code/06_dynamic目錄中找到。

　　概括

　　圖4提供了一個矩形，它顯示了我給出的例子相關的特性和代價。 　　

　　 圖4.重構方法的分析

　　你可以發現，動態（Dynamic）方法是各種方案的良好組合。與使用重構的所有樣本類似，它提供了方法開始或終止時刻的明確的回調，因此你的應用程式可以準確地跟蹤運行時並立即為使用者提供反饋資訊。但是，它還能夠取消某種方法的重構（它被過於頻繁地調用），因此它不會受到其它的重構方案遇到的效能問題的影響。它沒有包含編譯時間步驟，並且它沒有增加類載入過程中的額外的工作。

　　未來的趨勢

　　我們可以給這個項目增加大量的附件特性，使它更加適用。其中最有用的特性可能是動態狀態資訊。我們可以使用新的java.util.Formatter類把類似printf的模式替換（pattern substitution）用於@Status訊息中。例如，我們的connectToDB(String url)方法中的@Status("Connecting to %s")註解可以把URL作為訊息的一部分報告給使用者。

　　在原始碼重構的協助下，這可能顯得微不足道，因為我將使用的Formatter.format方法使用了可變參數（Java 1.5中增加的"魔術"功能）。重構過的版本類似下面的情形：

　　public void connectToDB (String url) {
　　　Formatter f = new Formatter();
　　　String message = f.format("Connecting to %s", url);　　

　　　StatusManager.push(message);
　　　try {
　　　　...
　　　} finally {
　　　　StatusManager.pop();
　　　}
　　}

　　不幸的是，這種"魔術"功能是完全在編譯器中實現的。在位元組碼中，Formatter.format把Object[]作為參數，編譯器明確地添加代碼來封裝每個原始的類型並裝配該數組。如果BCEL沒有加緊彌補，而我又需要使用位元組碼重構，我將不得不重新實現這種邏輯。

　　由於它只能用於重構（這種情況下方法參數是可用的）而不能用於取樣，你可能希望在啟動的時候重構這些方法，或最少使動態實現偏向於任何方法的重構，還可以在訊息中使用替代模式。

　　你還可以跟蹤每個重構的方法調用的啟動次數，因此你還可以更加精確地報告每個方法的運行次數。你甚至於可以儲存這些次數的曆史統計資料，並使用它們形成一個真正的進度條（代替我使用的不確定的版本）。這種能力將賦予你在運行時重構某種方法的一個很好的理由，因為跟蹤任何獨立的方法的開銷都是很能很明顯的。

　　你可以給進度條增加"調試"模式，它不管方法調用是否包含@Status註解，報告取樣過程中出現的所有方法調用。這對於任何希望調試死結或效能問題的開發人員來說都是無價之寶。實際上，Java 1.5還為死結（deadlock）檢測提供了一個可程式化的API，在應用程式鎖住的時候，我們可以使用該API把進程條變成紅色。

　　本文中建立的基於註解的重構架構組件可能很有市場。一個允許位元組碼在編譯時間（通過Ant事務）、啟

　　動時（使用ClassTransformer）和執行過程中（使用Instrumentation）進行重構的工具對於少量其它新項目來說毫無疑問地非常有價值。

　　總結

　　在這幾個例子中你可以看到，中繼資料編程（meta-programming）可能是一種非常強大的技術。報告長時間啟動並執行操作的進程僅僅是這種技術的應用之一，而我們的JStatusBar僅僅是溝通這些資訊的一種媒介。我們可以看到，Java 1.5中提供的很多新特性為中繼資料編程提供了增強支援。特別地，把註解和運行時重構組合在一起為面向屬性的編程提供了真正動態形式。我們可以進一步使用這些技術，使它的功能超越已有的架構組件（例如XDoclet提供的架構組件的功能）。