一段時間以來，我一直對以客戶端為中心的基於 Web 的使用者介面感興趣。這些第四代框架的特點是其基於元件、事件驅動的程式設計模型，並專注於完全駐留在客戶端的表示邏輯。以這種方式針對 Web 瀏覽器通常需要使用 JavaScript 或 Flash，這本身就帶來了一些獨特的挑戰。

如果我們能夠用 Java 程式設計並自動生成 JavaScript 或 Flash 執行時模組，就可以解決其中許多挑戰。目前實現這一目標的兩個知名產品分別是 Google Web Toolkit (GWT) 和 Open Laszlo。兩者均在 OSI 批准的許可證下提供，並擁有活躍的社群，以及各自獨特的複雜性。一個考慮因素是它們在多大程度上實現了提供一個透明的基於 Java 的開發環境以用於 Web 瀏覽器部署的目標。這個考慮因素有幾個方面，包括 IDE 支援、除錯整合、反射能力、執行時小部件繫結等等。所有這些……

最近我一直在和一個客戶合作，處理 WAS 6.1 的一些工作。由於我們有很多 Spring 使用者在 WAS 上，我需要測試應用程式，所以我決定是時候在我的一個工作筆記型電腦上執行一個 WAS 副本了。我之所以說“一個”，是因為我目前在我的 Mac（使用 OSX）和我的 ThinkPad（使用 Ubuntu）上工作——最近我只使用 ThinkPad，因為我可以在沒有 Parallels 等虛擬機器工具的情況下執行 Oracle XE 和 WAS。我仍然更喜歡 Mac，但老實說，日常使用中並沒有太大區別——我只是懷念一些更有用的 Mac 工具，比如 Spotlight、Quicksilver、TextMate 和 NewsFire。

言歸正傳，回到主題——在 Ubuntu 上安裝 WAS 6.1。我使用的是 Ubuntu Edgy，我第一次嘗試安裝完全失敗了，我就是搞不明白為什麼。幸運的是，快速的 Google 搜尋找到了 這篇 文章。我完全不知道/bin/sh連結到 dash 而不是 bash——到底是什麼讓他們這樣做的。我不太喜歡建議的解決方案：執行安裝程式，讓它失敗，然後更改已安裝目錄中的所有指令碼。相反，我只是重新連結了/bin/sh使用一個快速的sudo unlink /bin/sh然後是sudo ln -s /bin/bash /bin/sh。之後，安裝程式執行得像夢一樣，我在大約 15 分鐘內完成了 WAS 的安裝並執行起來。

即使在我的 ThinkPad 上同時執行 Oracle XE，WAS 也執行得相當快。WAS 最好的地方之一是它提供的工具（管理控制檯、命令列工具）非常健壯。管理控制檯的效能非常出色——許多其他伺服器的控制檯都非常慢。

在我上一篇文章中，我介紹了一種建立策略類的方法，該方法充分利用了應用程式中存在的任何泛型元資料。在那篇文章的末尾，我展示了這段程式碼片段

EntitlementCalculator calculator = new DividendEntitlementCalculator();
calculator.calculateEntitlement(new MergerCorporateActionEvent());

您會記得DividendEntitlementCalculator被定義為

public class DividendEntitlementCalculator implements EntitlementCalculator<DividendCorporateActionEvent> {

    public void calculateEntitlement(DividendCorporateActionEvent event) {

    }
}

因此，將MergerCorporateActionEvent的例項傳遞給calculateEntitlement方法是不正確的。DividendEntitlementCalculator然而，正如我在上一篇文章中提到的，該程式碼將編譯。為什麼？嗯，EntitlementCalculator.calculateEntitlement()被定義為接受任何擴充套件CorporateActionEvent的型別，因此它應該編譯。那麼在這種情況下，執行時會發生什麼，Java 如何強制執行型別安全？嗯，正如您可能想象的，執行此程式碼會得到一個ClassCastException，提示您無法強制轉換MergerCorporateActionEvent轉換為DividendCoporateActionEvent。透過這種方式，Java 可以為您的應用程式強制執行型別安全——MergerCorporateActionEvent不可能“爬入”期望DividendCorporateActionEvent的方法中。

這裡真正的問題是：“那個ClassCastException是從哪裡來的？”答案很簡單——Java 編譯器透過引入一個橋接方法，添加了建立和丟擲它的程式碼。橋接方法是編譯器將生成並新增到您的類中的合成方法，以確保在面對泛型型別時的型別安全。

在上面所示的例子中EntitlementCalculator.calculateEntitlement可以呼叫任何與CorporateActionEvent型別相容的物件。然而，DividendEntitlementCalculator只接受與DividendCorporateActionEvent型別相容的物件，但是，由於您可以透過DividendEntitlementCalculator呼叫EntitlementCalculator介面，它也必須接受CorporateActionEvent。那麼這在編譯後的類檔案中意味著什麼呢？我們有使用者提供的方法

public void calculateEntitlement(DividendCorporateActionEvent event) {
    System.out.println(event);
}

這會轉化為以下位元組碼

public void calculateEntitlement(bigbank.DividendCorporateActionEvent);
  Code:
   Stack=2, Locals=2, Args_size=2
   0:   getstatic       #2; //Field java…

前幾天我與一些客戶在一起，他們問我關於單元測試和模擬物件的問題。我決定將我們討論的一些內容寫成一篇關於為單元測試建立依賴項（協作者）的教程。我們討論了兩種選擇，存根和模擬物件，並給出了一些簡單的例子來說明兩者的用法、優點和缺點。

在單元測試中，通常會模擬或存根被測試類的協作者，以便測試獨立於協作者的實現。這也是一項非常有用的能力，能夠……

上個月，Rod Johnson 在三次澳大利亞 Spring 使用者組會議上發表了一場題為“Spring 2.0 有什麼新奇酷炫的”的演講。Rod 在這些會議上提到我將提供他的簡報，所以就在這裡。

還有一些其他近期演講，人們也一直在給我發郵件詢問。不分先後，這是最新的內容

• 如果您正在尋找 Rod 的另一個會話，“使用 AOP 簡化企業應用程式”，您可以直接從悉尼 Java 使用者組網站下載。
• 我在兩次 Enterprise Java Australia 會議上做的 Real Object Oriented (ROO) 演示將不會發布。這些幻燈片已被我在 The Spring Experience 上做的更近期、更詳細的演示所取代。
• 我的“快速跳入真實面向物件 (ROO) 應用程式”會話將很快在本部落格上釋出。我目前正在製作一個配套影片。
• Acegi Security 1.0.3 新的 ACL 功能的報道，在我的“超越唾手可得的成果：領域訪問控制列表”會話中也將很快在此處釋出。與此同時，Acegi Security SVN 現在包含示例應用程式（SEC-415）。

幾周前，我寫了一篇關於 Spring 名稱的由來的部落格。我們還收到許多關於 Interface21 名稱由來的問題。

對於讀過我的書或考慮過 Spring 設計的人來說，interface 部分 hardly 令人驚訝。它既利用了介面的 OO 概念（我一直深愛），也利用了系統介面的概念。例如，為現有綠屏系統新增一個 Web 介面——這正是我第一次想到公司名稱時正在做的事情。

到目前為止，一切順利。真正的問題出在數字上。

和 Spring 這個名字一樣，有些理論比真正的解釋更有趣。所以我們從我聽到的關於 21 的理論開始……

上週我在一個客戶現場，人群中有一個問題：“為什麼 getConfigLocations() 不再是抽象的了？”在客戶面前工作一段時間後，你很少會說不出話來，但我當時就是。老實說，我第一個想法是客戶不可能對。但是瞧，在 AbstractSingleSpringContextTests 的修訂版 1.3 中，它清楚地表明 getConfigLocations() 不再是抽象的。我沒有針對 2.0.1 建立任何新的整合測試，所以我甚至沒有看到這個改變。

對此感到驚訝，我給 Juergen 發了一封電子郵件，內容是……

這些場地照片是昨天拍攝的（靠近這樣的地方是 Interface21 在佛羅里達州設有辦公室的福利之一）。

 

雄偉的威斯汀外交官酒店

配備無邊泳池

下方有一條緩慢流淌的河流

位於美麗的海濱地帶

我們將把其中幾張照片融入主會議橫幅，懸掛在 Diplomat 高聳的天花板上。一切都已準備就緒，將是一場精彩的盛會。下週在 Spring Experience 見！

在 The Spring Experience 大會臨近之際，我一直很忙，但我注意到 Rod 在部落格方面非常活躍。所以今天在機場和飛機上的一些空閒時間裡，我決定寫一點部落格。

我們 Spring 社群面臨的最大平衡挑戰之一是確保我們保持向後相容性，同時仍能創新。這種創新的一部分是利用 Java 後續版本（如 Java 5）中的新特性和構造。自從 1.2.x 分支以來，我們已經看到了一些這方面的內容，例如 @Transactional 註解和我們基於 @ManagedResource 註解的 JMX 自動檢測。最終，這些都是很棒的功能，並且大大簡化了開發（至少是我的開發），但它們實際上只是將元資料移到程式碼中。我們還沒有看到的是……