Java 圖形界面暗戰：SWT 與 Swing 背後的商業恩怨與技術抉擇

前言：一場關於 GUI 的商業大戲

本文源自 2000 年代初期 Java 社群討論，記錄了 IBM 內部視角下 SWT 與 Swing 的恩怨情仇。雖然時光流轉，但文中揭示的技術路線之爭、企業政治博弈、人才流動對技術棧的深遠影響，至今仍具參考價值。譯者聲明：翻譯旨在還原歷史脈絡，不代表立場傾向。

起因：AWT 的缺陷與 Sun 的應對

Java 早期僅有 AWT，將元件映射至原生系統控件。雖具可攜性，但漏洞百出，穩定性差。Sun 開發者常將缺陷歸咎於作業系統差異（如焦點順序、快捷鍵行為不一），實則掩蓋過早釋出代碼的事實。

關鍵人物：Amy Fowler 的登場

Amy 來自 Smalltalk 陣營（ObjectShare/ParcPlace Digitalk），主導「輕量級元件」架構——即後來的 Swing。她說服 Sun 高層接管 GUI 開發，並招募舊部下組建團隊。Swing 本意應為繪圖框架，輔助地圖、繪圖類應用，按鈕等標準控件仍交由 AWT。但 Amy 團隊堅持全套輕量級重寫，在管理層技術判斷力不足與政治手段下強行推行，造就今日 Swing 龐大、缺陷叢生、效能低落的局面。

Smalltalk 陣營的前車之鑑

90 年代初 Smalltalk 三巨頭（IBM、ParcPlace、Digitalk）中，IBM 採原生控件，ParcPlace 採仿真控件（Swing 前身）。兩派合併時因架構之爭導致專案失敗，公司股價從 60 美元跌破 1 美元，最終被除牌。Sun 卻重蹈覆轍，引入同樣失敗的架構與人員。

IBM 的反擊：SWT 誕生記

IBM 內部深惡 Swing。VisualAge 系列工具原以 Smalltalk 原生控件開發，遷移 Java 時被迫使用 Swing，客戶對醜陋界面極度不滿。OTI（Object Technology International）團隊將 Smalltalk 原生控件移植至 Java，成功應用於 VisualAge Micro Edition。過程中發現 Swing 讀取 Windows 事件佇列有嚴重缺陷（記憶體洩漏），不得不自行實作事件輪詢迴路。多次要求 Sun 修復無果（Amy 拒絕聽取），IBM 決定 SWT 與 AWT/Swing 完全解耦，甚至自定 Point、Rectangle 等核心類。

Eclipse 與商業博弈

SWT 整合入 Eclipse，目標直指 Visual Studio。開源策略吸引 TogetherSoft、Rational 等廠商入駐。Sun 視 Eclipse 為 NetBeans 威脅，向 IBM 高層施壓，拒絕 Eclipse 獲得 Java 認證（理由：含原生代碼），甚至威脅法律行動禁止稱「Java IDE」。IBM 妥協：Eclipse GUI 設計器支援 Swing/AWT 拖放，但禁用 SWT 控件。

技術本質的隱喻

「Swing 就像 Java 決定不透過作業系統實現原生 IO，而是透過磁頭馬達 API 自己讀磁碟扇區。它拿著底層 paint(Graphics) 方法，自行繪製所有視窗元件。」

這句話精準捕捉 Swing 設計的核心爭議：犧牲原生整合與效能，換取跨平台一致性——但代價是龐大、緩慢、難以除錯。

結語

SWT 證明了「原生控件 + 跨平台抽象層」的可行性。歷史告訴我們：技術選型不僅關乎架構優劣，更受制於組織政治、人才流向與商業利益。理解這段歷史，有助於在今日技術決策中避免重蹈覆轍。