引言

Eclipse是流行的Java集成開發環境(IDE)。同時它還可以作為其它語言的開發環境（例如C++和Ruby）并且作為開發桌面或服務器應用程序的富客戶端開發平臺。如今，Eclipse開源社區擁有幾十個開源項目，其范圍從商務智能到社會網絡等各個方面。Eclipse是非贏利性基金會的名字，由它全面負責這些工程。

Eclipse的每個版本在Eclipse的發行歷史上都具有里程碑意義：在2006年6月30日同時發行了共十個Eclipse工程。本文將集中探討Eclipse 3.2版本的IDE，特別是它的Java開發工具(JDT)。

JDT構成

JDT的歷史可以追蹤到在1996年用Smalltalk編寫的Visual Age for Java(VAJ)。在VAJ中，一切都被編譯并且全部被調入內存。這種設計不能進行比例縮放，難于擴展，從而使其很難進行再創造。

在1999年，該IDE團隊開始開發Visual Age Micro Edition(VAME)。這個工具開始完全用Java編寫，并使用標準Widget工具箱(SWT)來實現其用戶接口。當時的VAME的主要設計市場針對的是嵌入式空間中的開發與應用。為此，它使用了標準Java虛擬機，并且讓工作區位于文件系統中。然而，文件和文件夾名字都是一些不能讀的UUID。

與VAJ提供的編譯器相比，VAME的增長式編譯器快了將近十倍。這種模型是基于狀態構建的（與當前的Eclipse形成對照，它是基于源碼的）。VAME有它自己的倉庫系統Rapier，并且可以使用插件方式來對之進行擴展。

VAME一開始并沒有吸引社區開發者的注意力，但是其中的確包含很多好主意-開發者以后使用之來開發了他們的下一代工程-Eclipse。在2001年，Eclipse 1.0發行。當時，它被描述為"一種通用的IDE，并不特別針對于什么內容"。從一開始，Eclipse和JDT都被構建為一種針對其它開發工具使用的開發平臺。工作區存儲在磁盤上并且對其它工作區開放。Eclipse 1.0中使用的不是一種專利式數據倉庫，而是集成了CVS。

與其先行者相比，Eclipse還有另一個重要區別：它是開源的，而且其用戶社區大量存在并且是自維持性的。Eclipse 3.2大多數的新的和改進特征直接來源于Eclipse用戶。自從3.1版本以來，共有超過30，000個請求被修改并得到增強。去粗存精，下面讓我們來重點分析幾個對于大多數Java開發者特別重要的特征。

Eclipse編譯器

JDT的強有力的特征之一是它的內植的完全兼容于javac的增長式Java編譯器。盡管你能使Eclipse使用Ant和javac，甚至能夠使問題標記顯示于IDE中（這是3.2版本中的新特征），但是，Eclipse編譯器本身就提供了更好的診斷技術。

該JDT編譯器最初的開發目的是針對VAME，以后針對Eclipse作了修改。這個編譯器基于開發者稱之的"編譯三規則"，并在模式上遵循了Asimov的機器人學規則：

1. 正確性-一個編譯器不能損害一個源程序。

2. 高效性-除了與規則1相沖突的地方之外，一個編譯器必須是快速的。

3. 友好性-一個編譯器必須幫助用戶糾正編程錯誤，只要這樣的幫助不與規則1和規則2相沖突。

正確性：當設計一個Java編譯器時，你不僅必須遵循相應的規范，而且還要領悟該規范的精神,只考慮正確性是不行的。因此，JDT開發者一直在努力奮斗以與其它編譯器基本保持一致（包括Sun的編譯器）。在Eclipse 3.2(相比之下，在VAJ中根本沒有進行單元測試)中僅針對正確性的檢查就超過15，000多次的單元測試。

高效性：成千的工程和成百萬行的代碼往往是很經常的事情。這意味著，大量的問題，例如內存消耗必須能夠被預測和加以分級，需要解決。Eclipse 3.2使用回歸式優化策略對此作了進一步提煉。例如，開發者可以重寫一個流程圖以便使用位操作，結果它從以前百分之20的時間消耗降低到了百分之4。

友好性：報告錯誤是一種藝術，只用行號是不夠的，二級錯誤被最小化。例如，如果你在一個文件中丟失了一個分號，它不會影響所有另外它所依賴的文件。改進的靜態分析功能有助于發現錯誤模式。另外，Eclipse還能夠對Javadoc進行正確性檢查。

在3.2版本中，Eclipse編譯器是Java-SE-6.0兼容的。Eclipse支持Java 6分類和StackMapTable屬性（甚至在Java 6發行之前）。而且，該編譯器提供了大量的新的診斷功能-有助于你發現存在于代碼中的問題。與3.2版本的編譯器（提供了45種診斷功能）相比，VAJ則僅提供了3種診斷功能。最新的一些診斷功能包括針對如下內容的檢測：

· 使用顯然是null的變量。

· 不必要的null檢查。

· 到方法參數的偶然賦值。

· 切換大小寫。

· 使用非泛型（原始）類型。

· 未使用的標簽。

· 不必要的$NON-NLS$標簽。

在默認情況下，大多數的這些功能都處于off狀態。當然，你還可以使用@SuppressWarnings注解來把它們設置為off狀態。

從3.2版本開始，如果你想在Eclipse外部使用Eclipse編譯器，你可以單獨下載這樣的版本。它的命令行兼容于javac，并且下載尺寸僅有1MB左右。既然Eclipse編譯器是開源的，所以大量的其它工程，例如Apache Tomcat，就可以綁定到其它的軟件當中。

編輯器

任何開發環境的最基本的特征首先體現在編輯器上。一般地，你會把大多數時間花在其中；因此，編輯器必須是舒適、不唐突、強有力的，而且能夠提供語法高亮顯示。JDT使用它的Java模型來提供語法高亮顯示功能；例如，它十分清楚類與實例變量之間的區別，因此它能以不同的顏色來標志它們。它甚至能夠窺探源碼注釋來指出是否你調用的一個方法是過時的（或不推薦使用），并且針對這一方法調用繪制一條線以強調這一部分代碼值得注意。

在Java編輯器中的一個有用的命令之一是Ctrl＋Space(內容助理)。不記得一個對象的方法有哪些或如何拼寫一個類名嗎？只要按下Ctrl＋Space，那么Eclipse將在任何給定點提供一個有效的可能性列表。Eclipse 3.2繼續改進這個特征。例如，當你輸入長標識符，例如"LongJavaName"，時，現在你可以輸入"LJN"并且按下Ctrl＋Space，那么Eclipse就會知道你的意思。這稱作"CamelCase completion"。當進行類型查找時，它也能工作（Ctrl＋Shift＋T）。

你是否厭煩了輸入詞語，例如"StringBuffer buffer = new StringBuffer();"？現在，不必再重復了。在版本3.2中，你可以輸入："SB，"Ctrl＋Space，Space，Ctrl＋Space，" = new"，Ctrl＋Space，"();"來代替。在此，我們使用了16次擊鍵來代替了47次擊鍵。想在一個變量名前加入一個不同的前綴嗎？沒有問題-只要在第二個Ctrl＋Space之前輸入它即可。例如，在3.2版本中，"Element root"+Ctrl＋Space完全等價于"Element rootElement"(見圖1)。

圖1.在3.2版本中內容助理(Ctrl＋Space)繼續得到改進，現在它支持CamelCase并且保存已經輸入的字符。

下面一項特征更節省時間。在3.2版本中，Ctrl＋Space將根據你的使用模式動態地重排它的建議。因此，例如，如果你總是把ArrayList實例賦值給List變量，那么ArrayList建議將排在第一位，以便你可以更快地選擇它。現在，代碼完成功能甚至能夠工作于Javadocs中，因此你可以創建@links或常用引用而不必記住這些長名。

你是否提出過這樣的問題："如果IDE足夠聰明-能夠找出在這一行中存在問題，那么它為什么不能改正它？"如今，Eclipse加入了一種特征，稱為"Quick Fix"，它可以實現這一功能，甚至更多。只要把你的光標放到有問題的一行代碼上并且按下Ctrl＋1鍵，那么Eclipse將提供有關于修改它的建議。

Eclipse的每一個新的發行版本都加入一些新的修改；例如在版本3.2中，如果你得到關于使用原始類型的一個警告，那么你只要把光標放到那一行上，然后按下Ctrl＋1，并且選擇一種"修整"，例如"Add type parameters"即可。還有，在3.2版本中，Quick Fix能夠維護同一個文件甚至在多個文件中的許多問題，而不必單獨處理每一個問題。

我想強調的另一個特征是"重命名類型"。如果你象我一樣，那么你會經常把你的變量和方法類似于你的類型命名。例如，如果你有一種Bar類型，那么你可能有一個變量fBar和一個方法createBar(見圖2)。問題是，如果你想把Bar重命名為另一個名，那么你還要修改其它大量的地方。但是，在3.2版本中，把具有相似名字的變量和方法統一地改變為你想要的新名字是極其簡單的事情。這種神奇的重命名功能是3.2版本提供的我最喜歡的特征之一。

圖2.當你在Eclipse 3.2中重命名一類型時，它提供具有類似命名的重命名變量和方法

運行

在一些IDE中，你一般要設置一個工程為"主工程"，并且使用一個全局的Run命令來運行這個程序。相比之下，Eclipse卻不是以這種方式工作。在Eclipse中，你擁有一串啟動配置，它們包含有關于運行、調試或測試代碼的所有的詳細資料，例如命令行參數、類路徑、JRE版本，等等。在Eclipse 3.2中，通過使用過濾和執行環境，管理啟動配置更為容易。

過濾讓你根據你感興趣的內容進一步裁減配置列表。執行環境讓你使用一種通用命名，例如"J2SE-1.4"，來描述一個Java運行時刻的能力。Eclipse能夠選擇滿足或超出你指定要求環境的JRE版本。

你是否曾發現自己在開發期間不斷地運行多個測試集？在3.2版本下，你可以在同一時刻運行多個測試集，并且你可以"回溯"和查看以前運行的歷史。Eclipse 3.2還支持最新版本的JUnit（4.0版本）。

團隊開發

你是否曾發現自己盯著一行代碼發愣：誰加入的這些代碼？為什么？Eclipse 3.2能顯示基于顏色的注解以便確定在當前文件中各部分內容的作者-這是通過讀取CVS歷史(見圖3)實現的。把鼠標停在一個更改塊上將顯示開發者的姓名、相應的日期和注釋信息。它還會高亮在文件的其它部分中作過相同修動的代碼。

圖3.CVS Quick Diff注解顯示基于顏色的注解(在當前文件中各個部分的作者)，在某一部分上停留鼠標將顯示該修改版本的細節。

我確信你也有這種體會：你調用其他人編寫的代碼，并且一切都能順利工作，直到它們以一種新的版本出現。然后，你開始遇到一些過時的"警告"，更有甚者，出現一些編譯錯誤，直到你修改你的程序來適應其改變。好了，現在的Eclipse 3.2引入了一種非常酷的特征，稱為"重構腳本"，極大地簡化了這一過程。

當然，重構簡單地意味著改變源碼而不改變其行為。例如，也許存在拼錯的字段，或者一個方法需要一個新的參數。Eclipse一直為自動化類似的修改提供良好的支持。而且，現在它還為消費者也提供了幫助。

你實現的每個重構操作都記入歷史。Eclipse 3.2讓你把這一歷史寫入到一個腳本文件中，以后再使用之。你可以把這些腳本保存到CVS中或把它包括到一個JAR文件中，這樣以來該JAR的用戶就能夠在他們得到一個新版本時"恢復"同樣的改變。這與應用補丁是不同的。補丁只能針對導致它們的具體的源文件操作，而重構腳本卻能夠針對任意的使用重構API的源碼文件操作。

維護一種不斷增長的API是一項相當困難的工作，現在Eclipse使得這一工作容易多了。當你重命名一個方法時，Eclipse 3.2能夠保持舊的方法不動，把它標記為"過時的"，然后對之進行重定向以便調用一個新方法，并制作一個重構腳本以自動地轉換所有調用者-當它們導入你的新的JAR文件時。

代碼清潔器

一直以來，Eclipse具有一種相當強的代碼格式化功能以幫助整個團隊的代碼格式化標準。在版本3.2中提供了一個新的"Clean Up"向導(見圖4)進一步加強了這一功能。下面列出這個向導的一些選擇實現功能：

· 刪除不用的導入功能。

· 刪除不用的private方法和構建函數。

· 添加缺乏的@Override和@Deprecated注解。

· 添加缺乏的$NON-NLS$標簽，或刪除不必要的那些標簽。

· 把所有循環轉換成增強式的for循環。

· 把控制語句體轉換成塊。

· 刪除不必要的強制轉換。

· 把串行序列版本ID添加到Serializable和Externalizable類。

"Clean Up"向導能夠在一個Java文件、一個包甚至整個工程上運行。

圖4."Clean Up"向導讓你在整個工程范圍內應用一致的標準。

結論

如今，比較于任何其它語言和平臺來說，有相當范圍的工具可以供Java程序員選擇利用。我也搞不清楚這其中的原因-也許這是用戶的巨大能量和積極性所致，或者是缺乏單個主流供應商的結果。無論什么原因，Eclipse都能夠與許多選擇對象-包括NetBeans，IDEA，JDeveloper和JBuilder-進行媲美。隨著3.2版本的發行，Eclipse對Java IDE的許多方面都是一次大的躍進，這將會使所有的Java程序員受益，不管你最終選擇哪一種工具。