Eclipse是一個流行的針對Java編程的集成開發環境(IDE)。它還可以用作編寫其他語言(比如C++和Ruby)的環境，合並各種種類工具的框架，以及創建桌面或服務器應用程序的富客戶端平台。如今，Eclipse開源社區擁有數十個項目，其范圍從商務智能到社會網絡等各個方面。Eclipse同時也是管理這些項目的非贏利性組織的名稱。(而且，盡管我相當肯定它並非地板蠟，還是存在Eclipse汽車、足球隊和口香糖。)
Eclipse version 3.2在Eclipse Callisto 發行歷史上具有裡程碑的意義:於2006年6月30日同時發布了10個Eclipse項目。本文將集中探討Eclipse 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 VM，並把工作區保存在文件系統中。然而，文件和文件夾名稱都是一些無法讀取的UUID。
與VAJ提供的編譯器相比，VAME的增量式編譯器快了近10倍。該模型是基於狀態構建的(與目前的Eclipse相反，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更為強大的功能之一即是它內置的增量式Java編譯器，這個編譯器與javac完全兼容。盡管可以讓Eclipse使用Ant和javac，甚至可以讓問題標志顯示在IDE中(此為3.2版本中的新功能)，但是Eclipse編譯器可以提供更好的診斷技術和更快的周轉周期。
JDT編譯器原本是為VAME而編寫的，後針對Eclipse進行了修改。這個編譯器構建在開發人員稱之為“編譯的3大規則”(模仿了阿西莫夫的機器人3大定律)之上:
·正確性:編譯器不能傷害源程序。
·高效性:編譯器必須快速，除非速度與規則1發生沖突。
·友好性:編譯器必須幫助用戶糾正編程錯誤，只要這類幫助不與規則1和規則2沖突。
·正確性:設計Java編譯器時，不僅必須遵循相應的規范，而且必須領會該規范的“精神”，僅僅考慮正確性是不行的。因此，JDT開發人員多年來辛勤工作，以便與其他編譯器的功能保持一致，其中包括Sun的編譯器。在Eclipse 3.2中，僅針對正確性的檢查就超過了15,000次單元測試(相比之下，VAJ中根本沒有進行單元測試)。
·高效性:數千個項目和數百萬行代碼往往是很平常的事情。這意味著要解決很多問題，例如內存使用必須是可預測的並加以分級。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檢查。
·對方法參數的偶然賦值。
·通過讓之前的大小寫狀態失效的方式，切換大小寫輸入。
·使用非一般(原始)類型。
·未使用的標簽。
·不必要的-NLS
在默認情況下，大多數這些功能都處於關閉狀態。當然，還可以使用注釋把它們設置為關閉狀態。
從3.2版本開始，如果想在Eclipse外部使用Eclipse編譯器，您可以單獨下載該版本。它的命令行參數與javac兼容，並且下載文件大小僅有1MB左右。既然Eclipse編譯器是開源的，所以許多其它項目(例如Apache Tomcat)就可以把它綁定到它們自己的軟件中。
編輯
任何開發環境的最基本特征首先體現在編輯器上。您會在這方面花上大部分的時間;因此，編輯器必須是舒適、不唐突且功能強大的。自從Emacs以來，每個編輯器都至少包含一些常見源程序語言的基礎知識，以便能夠提供語法高亮顯示功能。JDT使用它的Java模型來提供語法高亮顯示功能;例如，它十分清楚類與實例變量之間的區別，因此能以不同的顏色來標志它們。它甚至能夠根據源碼注釋來指出您調用的一個方法是否是過時的(或不推薦使用)，並且針對這一方法調用繪制一條直線以強調這部分代碼值得注意。
在Java編輯器中，更有用的命令之一是Ctrl-Space (內容輔助)。不記得一個對象的方法有哪些或如何拼寫一個類名嗎?只要按下Ctrl-Space， Eclipse將在任何指定點提供一個有效的可能性列表。Eclipse 3.2繼續改進這項功能。例如，輸入長標識符，例如“LongJavaName”時，現在您可以輸入“LJN”並且按下Ctrl-Space， Eclipse就會知道您的意思。這稱作“CamelCase完成”功能。進行類型查找時，它也能發揮作用(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中，因此您可以創建或常用引用而不必記住這些長長的名稱。
您是否提出過這樣的問題:“如果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)，進一步加強了這一功能。下面列出這個向導可以選擇實現的一些功能:
·刪除不用的導出功能。
·刪除不用的私有方法和構造器。
·添加缺少的和注釋。
·添加缺少的-NLS
·把所有for循環轉換為增強的-for循環。
·把控制語句主體轉換為塊。
·刪除不必要的強制轉換。
·為Serializable和Externalizable類添加連續版本ID。
·Clean Up向導可以在Java文件、軟件包或整個項目上運行。
圖 4. Clean Up向導讓您可以在整個項目范圍內應用一致的標准。
結束語
如今，相對於任何其他語言和平台來說，可供Java程序員選擇使用的工具相當之多。我也搞不清楚這其中的原因——也許是用戶的巨大能量和積極性所致，或者是沒有單一的壟斷供應商(例如Microsoft)將其意願強加於平台並將其工具直接與平台綁定的結果。無論原因是什麼，Eclipse都能夠與許多備選方案(包括NetBeans、IDEA、JDeveloper和JBuilder)相媲美。隨著3.2版本的發行，Eclipse在Java IDE方面有了一次大的飛躍，這將會使所有的Java程序員受益，不管您最終選擇的是哪一種工具。
