Eclipse是一(yī)個流行的針對Java編程的集成開(kāi)發環境(IDE)。它還可以用作編寫其他語言(比如C++和Ruby)的環境，合并各種種類工(gōng)具的框架，以及創建桌面或服務器應用程序的富客戶端平台。如今，Eclipse開(kāi)源社區擁有數十個項目，其範圍從商(shāng)務智能到社會網絡等各個方面。Eclipse同時也是管理這些項目的非赢利性組織的名稱。(而且，盡管我(wǒ)(wǒ)相當肯定它并非地闆蠟，還是存在Eclipse汽車(chē)、足球隊和口香糖。)
Eclipse version 3.2在Eclipse Callisto 發行曆史上具有裏程碑的意義:于2006年6月30日同時發布了10個Eclipse項目。本文将集中(zhōng)探讨Eclipse IDE，特别是其Java 開(kāi)發工(gōng)具 (JDT)。
JDT構成
JDT的曆史可以追溯到1996年左右使用Smalltalk編寫的Visual Age for Java(VAJ)。在VAJ中(zhōng)，一(yī)切内容都會在輸入時進行編譯，并在内存中(zhōng)完全解析。這種設計的可伸縮性不是很好，難于擴展，重建文件也有一(yī)定的困難。
1999年，該IDE團隊開(kāi)始開(kāi)發Visual Age Micro Edition(VAME)。這個工(gōng)具完全以Java編寫，并使用标準Widget 工(gōng)具箱(SWT)來實現其用戶接口。當時的VAME将目标定爲嵌入式空間中(zhōng)的開(kāi)發與應用。爲此，它使用了标準的Java VM，并把工(gōng)作區保存在文件系統中(zhōng)。然而，文件和文件夾名稱都是一(yī)些無法讀取的UUID。
與VAJ提供的編譯器相比，VAME的增量式編譯器快了近10倍。該模型是基于狀态構建的(與目前的Eclipse相反，Eclipse是基于源代碼的)。VAME有自己的存儲庫系統Rapier，并且可以使用插件對其進行擴展。
VAME實際上并沒有在社區中(zhōng)流行開(kāi)來，但是它包含了大(dà)量優秀的思路，開(kāi)發人員(yuán)在接下(xià)來的Eclipse項目中(zhōng)延用了這些思路。2001年，Eclipse 1.0發布。它被描述爲“一(yī)種通用的IDE，并不特别針對于什麽内容”。一(yī)開(kāi)始，Eclipse和JDT都被構建爲其他開(kāi)發工(gōng)具使用的平台。工(gōng)作區保存在磁盤上，并對其他工(gōng)作區開(kāi)放(fàng)。Eclipse 1.0集成了CVS，而沒有使用專用的存儲庫。
Eclipse與其先行者之間有一(yī)個重要的區别:它是開(kāi)源的。其用戶社區以爆炸式的速度增長，并可獨立維持。Eclipse 3.2的大(dà)部分(fēn)新的和改進功能都源自eclipse用戶提出的增強要求。自從3.1版本以來，已經有超過30,000個修複和增強的要求得到了解決。由于要把全部這些要求都過一(yī)遍需要很長時間，下(xià)面我(wǒ)(wǒ)們就重點講述其中(zhōng)一(yī)些對于大(dà)多數Java開(kāi)發人員(yuán)特别重要的要求。
Eclipse編譯器
JDT更爲強大(dà)的功能之一(yī)即是它内置的增量式Java編譯器，這個編譯器與javac完全兼容。盡管可以讓Eclipse使用Ant和javac，甚至可以讓問題标志(zhì)顯示在IDE中(zhōng)(此爲3.2版本中(zhōng)的新功能)，但是Eclipse編譯器可以提供更好的診斷技術和更快的周轉周期。
JDT編譯器原本是爲VAME而編寫的，後針對Eclipse進行了修改。這個編譯器構建在開(kāi)發人員(yuán)稱之爲“編譯的3大(dà)規則”(模仿了阿西莫夫的機器人3大(dà)定律)之上:
·正确性:編譯器不能傷害源程序。
·高效性:編譯器必須快速，除非速度與規則1發生(shēng)沖突。
·友好性:編譯器必須幫助用戶糾正編程錯誤，隻要這類幫助不與規則1和規則2沖突。
·正确性:設計Java編譯器時，不僅必須遵循相應的規範，而且必須領會該規範的“精神”，僅僅考慮正确性是不行的。因此，JDT開(kāi)發人員(yuán)多年來辛勤工(gōng)作，以便與其他編譯器的功能保持一(yī)緻，其中(zhōng)包括Sun的編譯器。在Eclipse 3.2中(zhōng)，僅針對正确性的檢查就超過了15,000次單元測試(相比之下(xià)，VAJ中(zhōng)根本沒有進行單元測試)。
·高效性:數千個項目和數百萬行代碼往往是很平常的事情。這意味着要解決很多問題，例如内存使用必須是可預測的并加以分(fēn)級。Eclipse 3.2繼續對此進行積極的優化。例如，開(kāi)發人員(yuán)可以重寫一(yī)個流程圖以使用位操作，結果位操作的時間消耗從20%降到了4%。
·友好性:報告錯誤是一(yī)門藝術。僅僅使用行号還不夠。二級錯誤被最小(xiǎo)化。例如，如果一(yī)個文件内漏掉了一(yī)個分(fēn)号，它不會影響到與它相關的其他文件。改進後的靜态分(fēn)析功能有助于發現錯誤模式。另外(wài)，Eclipse還可以對Javadoc進行正确性檢查。
就3.2版本來說，Eclipse編譯器是與Java SE 6.0兼容的。沒錯，Eclipse支持Java 6類和StackMapTable屬性(甚至在Java 6發布之前)。另外(wài)，該編譯器還提供大(dà)量新的診斷功能，有助于在運行代碼之前發現其中(zhōng)的錯誤。與3.2版本的編譯器(提供了45種診斷功能)相比，VAJ僅提供了3類診斷功能。最新的一(yī)些診斷功能包括對以下(xià)内容的檢測:
·使用顯然是null的變量。
·不必要的null檢查。
·對方法參數的偶然賦值。
·通過讓之前的大(dà)小(xiǎo)寫狀态失效的方式，切換大(dà)小(xiǎo)寫輸入。
·使用非一(yī)般(原始)類型。
·未使用的标簽。
·不必要的-NLS
在默認情況下(xià)，大(dà)多數這些功能都處于關閉狀态。當然，還可以使用注釋把它們設置爲關閉狀态。
從3.2版本開(kāi)始，如果想在Eclipse外(wài)部使用Eclipse編譯器，您可以單獨下(xià)載該版本。它的命令行參數與javac兼容，并且下(xià)載文件大(dà)小(xiǎo)僅有1MB左右。既然Eclipse編譯器是開(kāi)源的，所以許多其它項目(例如Apache Tomcat)就可以把它綁定到它們自己的軟件中(zhōng)。
編輯
任何開(kāi)發環境的最基本特征首先體(tǐ)現在編輯器上。您會在這方面花上大(dà)部分(fēn)的時間;因此，編輯器必須是舒适、不唐突且功能強大(dà)的。自從Emacs以來，每個編輯器都至少包含一(yī)些常見源程序語言的基礎知(zhī)識，以便能夠提供語法高亮顯示功能。JDT使用它的Java模型來提供語法高亮顯示功能;例如，它十分(fēn)清楚類與實例變量之間的區别，因此能以不同的顔色來标志(zhì)它們。它甚至能夠根據源碼注釋來指出您調用的一(yī)個方法是否是過時的(或不推薦使用)，并且針對這一(yī)方法調用繪制一(yī)條直線以強調這部分(fēn)代碼值得注意。
在Java編輯器中(zhōng)，更有用的命令之一(yī)是Ctrl-Space (内容輔助)。不記得一(yī)個對象的方法有哪些或如何拼寫一(yī)個類名嗎(ma)?隻要按下(xià)Ctrl-Space， Eclipse将在任何指定點提供一(yī)個有效的可能性列表。Eclipse 3.2繼續改進這項功能。例如，輸入長标識符，例如“LongJavaName”時，現在您可以輸入“LJN”并且按下(xià)Ctrl-Space， Eclipse就會知(zhī)道您的意思。這稱作“CamelCase完成”功能。進行類型查找時，它也能發揮作用(Ctrl-Shift-T)。
您是否厭(yàn)煩了輸入像"StringBuffer buffer = new StringBuffer();"?這樣的慣用語。現在，不必再進行這類重複了。在3.2版本中(zhōng)，可以輸入:"SB," Ctrl-Space, Space, Ctrl-Space, " = new ", Ctrl-Space, "();"來代替。在此，我(wǒ)(wǒ)們使用了16次擊鍵來代替了47次擊鍵。想在一(yī)個變量名前加上不同的前綴嗎(ma)?沒問題——隻要在第二個Ctrl-Space之前輸入它即可。例如，在3.2版本中(zhōng)，"Element root" + Ctrl-Space完全等價于"Element rootElement" (見圖1)。
圖 1.在3.2版本中(zhōng)内容輔助(Ctrl+Space)繼續得到改進，現在它支持CamelCase并可保存已經輸入的字符。
下(xià)面這項功能更加節省時間。在3.2版本中(zhōng)，Ctrl-Space将根據使用模式動态地重排它的建議。因此，例如，如果您總是把ArrayList實例賦值給List變量，那麽ArrayList建議将排在第一(yī)位，以便您可以更快地選擇它。現在，代碼完成功能甚至能夠工(gōng)作于Javadocs中(zhōng)，因此您可以創建或常用引用而不必記住這些長長的名稱。
您是否提出過這樣的問題:“如果IDE足夠聰明——能夠找出在這一(yī)行中(zhōng)存在問題，那麽它爲什麽不能改正這個問題呢?"如今，Eclipse加入了一(yī)項叫做"Quick Fix"的功能，可以做到這一(yī)點，甚至有過之而無不及。隻要把光标放(fàng)到有問題的代碼行上并按下(xià)Ctrl-1鍵，那麽Eclipse将提供有關于修複這個問題的建議。
Eclipse的每一(yī)個新的發行版本都會加入一(yī)些新的快速修複;例如在版本3.2中(zhōng)，如果看到關于使用原始類型的一(yī)條警告，隻要把光标放(fàng)到那一(yī)行上，然後按下(xià)Ctrl+1，并且選擇一(yī)種修複，例如"Add type parameters"即可。還有，在3.2版本中(zhōng)，Quick Fix能夠維護同一(yī)個文件甚至在多個文件中(zhōng)的許多常見問題，而不必單獨處理每一(yī)個問題。
我(wǒ)(wǒ)想提到的另一(yī)項功能是“重命名類型”。如果您像我(wǒ)(wǒ)一(yī)樣，經常以類似于類型的方式對變量和方法命名。例如，如果類型爲Bar，那麽很可能有一(yī)個變量fBar和一(yī)個方法createBar (見圖2)。問題是，如果想把Bar重命名爲另一(yī)個名稱，那麽還要修改大(dà)量其他的地方。但是，在3.2版本中(zhōng)，把具有相似名稱的變量和方法統一(yī)地改變爲其他新名稱是極其簡單的事情。在3.2版本提供的功能中(zhōng)，我(wǒ)(wǒ)最喜歡的就是這種神奇的重命名功能。
圖 2.當在Eclipse 3.2中(zhōng)重命名一(yī)個類型時，同時可以重命名具有類似名稱的變量和方法。
運行
在一(yī)些IDE中(zhōng)，一(yī)般要設置一(yī)個項目爲“主項目”，并且使用一(yī)個全局的Run命令來運行這個程序。相比之下(xià)，Eclipse的工(gōng)作方式有所不同。在Eclipse中(zhōng)，有一(yī)個啓動配置列表，它包含了有關運行、調試或測試代碼的所有詳細信息，例如命令行參數、類路徑、JRE版本，等等。在Eclipse 3.2中(zhōng)，通過使用過濾和執行環境，管理啓動配置變得更爲容易。
過濾讓您可以根據感興趣的内容進一(yī)步裁減配置列表。執行環境爲您提供使用一(yī)種通用名稱，比如"J2SE-1.4"，來描述一(yī)個Java運行時刻的能力。Eclipse能夠選擇滿足或超出指定環境要求的JRE版本。
您是否曾發現自己在開(kāi)發期間曾運行過多個測試集?在3.2版本中(zhōng)，可以在同一(yī)時刻運行多個測試集，并且可以“回溯”和查看以前的運行曆史。Eclipse 3.2還支持最新版本的JUnit(4.0版本)。
團隊工(gōng)作
您是否曾發現自己曾盯着一(yī)行代碼發愣:是誰加入了這些代碼?爲什麽?Eclipse 3.2能顯示基于顔色的注釋，以便确定當前文件中(zhōng)各部分(fēn)内容的作者——這是通過讀取CVS曆史(見圖3)而實現的。把鼠标停在一(yī)個修改塊上将顯示開(kāi)發者的姓名、相應的日期和注釋信息。它還會高亮顯示在文件其他部分(fēn)中(zhōng)作過相同改動的代碼。
圖 3. CVS Quick Diff注釋顯示基于顔色的注釋(當前文件中(zhōng)各部分(fēn)内容的作者)，在某一(yī)部分(fēn)上停留鼠标将顯示該修改版本的細節。
我(wǒ)(wǒ)相信您曾有過這種體(tǐ)會:您調用其他人編寫的代碼時一(yī)切都能順利工(gōng)作，直到它們以一(yī)種新的版本出現爲止。然後，您開(kāi)始看到一(yī)些有關過時的“警告”，更有甚者，竟然出現一(yī)些編譯錯誤，直到您修改程序以适應這些修改爲止。好了，現在的Eclipse 3.2引入了一(yī)項非常酷的功能，稱爲“重構腳本”，可以極大(dà)地簡化這一(yī)過程。
當然，重構僅僅意味着改變源碼，而不改變其行爲。例如，也許存在拼錯的字段，或者一(yī)個方法需要一(yī)個新的參數。Eclipse一(yī)直爲實現類似修改的自動化提供良好的支持。而且，現在它還爲使用者提供幫助。
您所做的每項重構操作都會記入曆史。Eclipse 3.2讓您可以把這些曆史寫入到外(wài)部的腳本文件中(zhōng)，以便日後可以回放(fàng)。可以把這些腳本保存到CVS中(zhōng)或把它包含到一(yī)個JAR文件中(zhōng)，這樣該JAR文件的用戶就能夠在他們得到一(yī)個新版本時“回放(fàng)”同樣的修改動作。這與應用補丁是不同的。補丁隻能面向它們所針對的特定源文件操作而使用，而重構腳本卻能夠針對使用重構API的任意源碼文件進行操作。
維護一(yī)個不斷發展的API以便讓他人使用，這是一(yī)項相當困難的工(gōng)作，現在Eclipse使得這一(yī)工(gōng)作變得容易多了。重命名一(yī)個方法時，Eclipse 3.2能夠保持舊(jiù)的方法不變，把它标記爲“過時的”，然後對之進行重定向以便調用新的方法，并制作一(yī)個重構腳本，以便在調用者導入新的JAR文件時自動地轉換所有這些調用者。
代碼清潔器
一(yī)直以來，Eclipse都具有一(yī)種相當強大(dà)的代碼格式化功能，以幫助您在整個團隊中(zhōng)應用代碼格式化标準。3.2版本提供了一(yī)個新的“Clean Up”向導(見圖4)，進一(yī)步加強了這一(yī)功能。下(xià)面列出這個向導可以選擇實現的一(yī)些功能:
·删除不用的導出功能。
·删除不用的私有方法和構造器。
·添加缺少的和注釋。
·添加缺少的-NLS昵蛏境槐匾謀昵?/li>
·把所有for循環轉換爲增強的-for循環。
·把控制語句主體(tǐ)轉換爲塊。
·删除不必要的強制轉換。
·爲Serializable和Externalizable類添加連續版本ID。
·Clean Up向導可以在Java文件、軟件包或整個項目上運行。
圖 4. Clean Up向導讓您可以在整個項目範圍内應用一(yī)緻的标準。
結束語
如今，相對于任何其他語言和平台來說，可供Java程序員(yuán)選擇使用的工(gōng)具相當之多。我(wǒ)(wǒ)也搞不清楚這其中(zhōng)的原因——也許是用戶的巨大(dà)能量和積極性所緻，或者是沒有單一(yī)的壟斷供應商(shāng)(例如Microsoft)将其意願強加于平台并将其工(gōng)具直接與平台綁定的結果。無論原因是什麽，Eclipse都能夠與許多備選方案(包括NetBeans、IDEA、JDeveloper和JBuilder)相媲美。随着3.2版本的發行，Eclipse在Java IDE方面有了一(yī)次大(dà)的飛躍，這将會使所有的Java程序員(yuán)受益，不管您最終選擇的是哪一(yī)種工(gōng)具。
Eclipse version 3.2在Eclipse Callisto 發行曆史上具有裏程碑的意義:于2006年6月30日同時發布了10個Eclipse項目。本文将集中(zhōng)探讨Eclipse IDE，特别是其Java 開(kāi)發工(gōng)具 (JDT)。
JDT構成
JDT的曆史可以追溯到1996年左右使用Smalltalk編寫的Visual Age for Java(VAJ)。在VAJ中(zhōng)，一(yī)切内容都會在輸入時進行編譯，并在内存中(zhōng)完全解析。這種設計的可伸縮性不是很好，難于擴展，重建文件也有一(yī)定的困難。
1999年，該IDE團隊開(kāi)始開(kāi)發Visual Age Micro Edition(VAME)。這個工(gōng)具完全以Java編寫，并使用标準Widget 工(gōng)具箱(SWT)來實現其用戶接口。當時的VAME将目标定爲嵌入式空間中(zhōng)的開(kāi)發與應用。爲此，它使用了标準的Java VM，并把工(gōng)作區保存在文件系統中(zhōng)。然而，文件和文件夾名稱都是一(yī)些無法讀取的UUID。
與VAJ提供的編譯器相比，VAME的增量式編譯器快了近10倍。該模型是基于狀态構建的(與目前的Eclipse相反，Eclipse是基于源代碼的)。VAME有自己的存儲庫系統Rapier，并且可以使用插件對其進行擴展。
VAME實際上并沒有在社區中(zhōng)流行開(kāi)來，但是它包含了大(dà)量優秀的思路，開(kāi)發人員(yuán)在接下(xià)來的Eclipse項目中(zhōng)延用了這些思路。2001年，Eclipse 1.0發布。它被描述爲“一(yī)種通用的IDE，并不特别針對于什麽内容”。一(yī)開(kāi)始，Eclipse和JDT都被構建爲其他開(kāi)發工(gōng)具使用的平台。工(gōng)作區保存在磁盤上，并對其他工(gōng)作區開(kāi)放(fàng)。Eclipse 1.0集成了CVS，而沒有使用專用的存儲庫。
Eclipse與其先行者之間有一(yī)個重要的區别:它是開(kāi)源的。其用戶社區以爆炸式的速度增長，并可獨立維持。Eclipse 3.2的大(dà)部分(fēn)新的和改進功能都源自eclipse用戶提出的增強要求。自從3.1版本以來，已經有超過30,000個修複和增強的要求得到了解決。由于要把全部這些要求都過一(yī)遍需要很長時間，下(xià)面我(wǒ)(wǒ)們就重點講述其中(zhōng)一(yī)些對于大(dà)多數Java開(kāi)發人員(yuán)特别重要的要求。
Eclipse編譯器
JDT更爲強大(dà)的功能之一(yī)即是它内置的增量式Java編譯器，這個編譯器與javac完全兼容。盡管可以讓Eclipse使用Ant和javac，甚至可以讓問題标志(zhì)顯示在IDE中(zhōng)(此爲3.2版本中(zhōng)的新功能)，但是Eclipse編譯器可以提供更好的診斷技術和更快的周轉周期。
JDT編譯器原本是爲VAME而編寫的，後針對Eclipse進行了修改。這個編譯器構建在開(kāi)發人員(yuán)稱之爲“編譯的3大(dà)規則”(模仿了阿西莫夫的機器人3大(dà)定律)之上:
·正确性:編譯器不能傷害源程序。
·高效性:編譯器必須快速，除非速度與規則1發生(shēng)沖突。
·友好性:編譯器必須幫助用戶糾正編程錯誤，隻要這類幫助不與規則1和規則2沖突。
·正确性:設計Java編譯器時，不僅必須遵循相應的規範，而且必須領會該規範的“精神”，僅僅考慮正确性是不行的。因此，JDT開(kāi)發人員(yuán)多年來辛勤工(gōng)作，以便與其他編譯器的功能保持一(yī)緻，其中(zhōng)包括Sun的編譯器。在Eclipse 3.2中(zhōng)，僅針對正确性的檢查就超過了15,000次單元測試(相比之下(xià)，VAJ中(zhōng)根本沒有進行單元測試)。
·高效性:數千個項目和數百萬行代碼往往是很平常的事情。這意味着要解決很多問題，例如内存使用必須是可預測的并加以分(fēn)級。Eclipse 3.2繼續對此進行積極的優化。例如，開(kāi)發人員(yuán)可以重寫一(yī)個流程圖以使用位操作，結果位操作的時間消耗從20%降到了4%。
·友好性:報告錯誤是一(yī)門藝術。僅僅使用行号還不夠。二級錯誤被最小(xiǎo)化。例如，如果一(yī)個文件内漏掉了一(yī)個分(fēn)号，它不會影響到與它相關的其他文件。改進後的靜态分(fēn)析功能有助于發現錯誤模式。另外(wài)，Eclipse還可以對Javadoc進行正确性檢查。
就3.2版本來說，Eclipse編譯器是與Java SE 6.0兼容的。沒錯，Eclipse支持Java 6類和StackMapTable屬性(甚至在Java 6發布之前)。另外(wài)，該編譯器還提供大(dà)量新的診斷功能，有助于在運行代碼之前發現其中(zhōng)的錯誤。與3.2版本的編譯器(提供了45種診斷功能)相比，VAJ僅提供了3類診斷功能。最新的一(yī)些診斷功能包括對以下(xià)内容的檢測:
·使用顯然是null的變量。
·不必要的null檢查。
·對方法參數的偶然賦值。
·通過讓之前的大(dà)小(xiǎo)寫狀态失效的方式，切換大(dà)小(xiǎo)寫輸入。
·使用非一(yī)般(原始)類型。
·未使用的标簽。
·不必要的-NLS
在默認情況下(xià)，大(dà)多數這些功能都處于關閉狀态。當然，還可以使用注釋把它們設置爲關閉狀态。
從3.2版本開(kāi)始，如果想在Eclipse外(wài)部使用Eclipse編譯器，您可以單獨下(xià)載該版本。它的命令行參數與javac兼容，并且下(xià)載文件大(dà)小(xiǎo)僅有1MB左右。既然Eclipse編譯器是開(kāi)源的，所以許多其它項目(例如Apache Tomcat)就可以把它綁定到它們自己的軟件中(zhōng)。
編輯
任何開(kāi)發環境的最基本特征首先體(tǐ)現在編輯器上。您會在這方面花上大(dà)部分(fēn)的時間;因此，編輯器必須是舒适、不唐突且功能強大(dà)的。自從Emacs以來，每個編輯器都至少包含一(yī)些常見源程序語言的基礎知(zhī)識，以便能夠提供語法高亮顯示功能。JDT使用它的Java模型來提供語法高亮顯示功能;例如，它十分(fēn)清楚類與實例變量之間的區别，因此能以不同的顔色來标志(zhì)它們。它甚至能夠根據源碼注釋來指出您調用的一(yī)個方法是否是過時的(或不推薦使用)，并且針對這一(yī)方法調用繪制一(yī)條直線以強調這部分(fēn)代碼值得注意。
在Java編輯器中(zhōng)，更有用的命令之一(yī)是Ctrl-Space (内容輔助)。不記得一(yī)個對象的方法有哪些或如何拼寫一(yī)個類名嗎(ma)?隻要按下(xià)Ctrl-Space， Eclipse将在任何指定點提供一(yī)個有效的可能性列表。Eclipse 3.2繼續改進這項功能。例如，輸入長标識符，例如“LongJavaName”時，現在您可以輸入“LJN”并且按下(xià)Ctrl-Space， Eclipse就會知(zhī)道您的意思。這稱作“CamelCase完成”功能。進行類型查找時，它也能發揮作用(Ctrl-Shift-T)。
您是否厭(yàn)煩了輸入像"StringBuffer buffer = new StringBuffer();"?這樣的慣用語。現在，不必再進行這類重複了。在3.2版本中(zhōng)，可以輸入:"SB," Ctrl-Space, Space, Ctrl-Space, " = new ", Ctrl-Space, "();"來代替。在此，我(wǒ)(wǒ)們使用了16次擊鍵來代替了47次擊鍵。想在一(yī)個變量名前加上不同的前綴嗎(ma)?沒問題——隻要在第二個Ctrl-Space之前輸入它即可。例如，在3.2版本中(zhōng)，"Element root" + Ctrl-Space完全等價于"Element rootElement" (見圖1)。
圖 1.在3.2版本中(zhōng)内容輔助(Ctrl+Space)繼續得到改進，現在它支持CamelCase并可保存已經輸入的字符。
下(xià)面這項功能更加節省時間。在3.2版本中(zhōng)，Ctrl-Space将根據使用模式動态地重排它的建議。因此，例如，如果您總是把ArrayList實例賦值給List變量，那麽ArrayList建議将排在第一(yī)位，以便您可以更快地選擇它。現在，代碼完成功能甚至能夠工(gōng)作于Javadocs中(zhōng)，因此您可以創建或常用引用而不必記住這些長長的名稱。
您是否提出過這樣的問題:“如果IDE足夠聰明——能夠找出在這一(yī)行中(zhōng)存在問題，那麽它爲什麽不能改正這個問題呢?"如今，Eclipse加入了一(yī)項叫做"Quick Fix"的功能，可以做到這一(yī)點，甚至有過之而無不及。隻要把光标放(fàng)到有問題的代碼行上并按下(xià)Ctrl-1鍵，那麽Eclipse将提供有關于修複這個問題的建議。
Eclipse的每一(yī)個新的發行版本都會加入一(yī)些新的快速修複;例如在版本3.2中(zhōng)，如果看到關于使用原始類型的一(yī)條警告，隻要把光标放(fàng)到那一(yī)行上，然後按下(xià)Ctrl+1，并且選擇一(yī)種修複，例如"Add type parameters"即可。還有，在3.2版本中(zhōng)，Quick Fix能夠維護同一(yī)個文件甚至在多個文件中(zhōng)的許多常見問題，而不必單獨處理每一(yī)個問題。
我(wǒ)(wǒ)想提到的另一(yī)項功能是“重命名類型”。如果您像我(wǒ)(wǒ)一(yī)樣，經常以類似于類型的方式對變量和方法命名。例如，如果類型爲Bar，那麽很可能有一(yī)個變量fBar和一(yī)個方法createBar (見圖2)。問題是，如果想把Bar重命名爲另一(yī)個名稱，那麽還要修改大(dà)量其他的地方。但是，在3.2版本中(zhōng)，把具有相似名稱的變量和方法統一(yī)地改變爲其他新名稱是極其簡單的事情。在3.2版本提供的功能中(zhōng)，我(wǒ)(wǒ)最喜歡的就是這種神奇的重命名功能。
圖 2.當在Eclipse 3.2中(zhōng)重命名一(yī)個類型時，同時可以重命名具有類似名稱的變量和方法。
運行
在一(yī)些IDE中(zhōng)，一(yī)般要設置一(yī)個項目爲“主項目”，并且使用一(yī)個全局的Run命令來運行這個程序。相比之下(xià)，Eclipse的工(gōng)作方式有所不同。在Eclipse中(zhōng)，有一(yī)個啓動配置列表，它包含了有關運行、調試或測試代碼的所有詳細信息，例如命令行參數、類路徑、JRE版本，等等。在Eclipse 3.2中(zhōng)，通過使用過濾和執行環境，管理啓動配置變得更爲容易。
過濾讓您可以根據感興趣的内容進一(yī)步裁減配置列表。執行環境爲您提供使用一(yī)種通用名稱，比如"J2SE-1.4"，來描述一(yī)個Java運行時刻的能力。Eclipse能夠選擇滿足或超出指定環境要求的JRE版本。
您是否曾發現自己在開(kāi)發期間曾運行過多個測試集?在3.2版本中(zhōng)，可以在同一(yī)時刻運行多個測試集，并且可以“回溯”和查看以前的運行曆史。Eclipse 3.2還支持最新版本的JUnit(4.0版本)。
團隊工(gōng)作
您是否曾發現自己曾盯着一(yī)行代碼發愣:是誰加入了這些代碼?爲什麽?Eclipse 3.2能顯示基于顔色的注釋，以便确定當前文件中(zhōng)各部分(fēn)内容的作者——這是通過讀取CVS曆史(見圖3)而實現的。把鼠标停在一(yī)個修改塊上将顯示開(kāi)發者的姓名、相應的日期和注釋信息。它還會高亮顯示在文件其他部分(fēn)中(zhōng)作過相同改動的代碼。
圖 3. CVS Quick Diff注釋顯示基于顔色的注釋(當前文件中(zhōng)各部分(fēn)内容的作者)，在某一(yī)部分(fēn)上停留鼠标将顯示該修改版本的細節。
我(wǒ)(wǒ)相信您曾有過這種體(tǐ)會:您調用其他人編寫的代碼時一(yī)切都能順利工(gōng)作，直到它們以一(yī)種新的版本出現爲止。然後，您開(kāi)始看到一(yī)些有關過時的“警告”，更有甚者，竟然出現一(yī)些編譯錯誤，直到您修改程序以适應這些修改爲止。好了，現在的Eclipse 3.2引入了一(yī)項非常酷的功能，稱爲“重構腳本”，可以極大(dà)地簡化這一(yī)過程。
當然，重構僅僅意味着改變源碼，而不改變其行爲。例如，也許存在拼錯的字段，或者一(yī)個方法需要一(yī)個新的參數。Eclipse一(yī)直爲實現類似修改的自動化提供良好的支持。而且，現在它還爲使用者提供幫助。
您所做的每項重構操作都會記入曆史。Eclipse 3.2讓您可以把這些曆史寫入到外(wài)部的腳本文件中(zhōng)，以便日後可以回放(fàng)。可以把這些腳本保存到CVS中(zhōng)或把它包含到一(yī)個JAR文件中(zhōng)，這樣該JAR文件的用戶就能夠在他們得到一(yī)個新版本時“回放(fàng)”同樣的修改動作。這與應用補丁是不同的。補丁隻能面向它們所針對的特定源文件操作而使用，而重構腳本卻能夠針對使用重構API的任意源碼文件進行操作。
維護一(yī)個不斷發展的API以便讓他人使用，這是一(yī)項相當困難的工(gōng)作，現在Eclipse使得這一(yī)工(gōng)作變得容易多了。重命名一(yī)個方法時，Eclipse 3.2能夠保持舊(jiù)的方法不變，把它标記爲“過時的”，然後對之進行重定向以便調用新的方法，并制作一(yī)個重構腳本，以便在調用者導入新的JAR文件時自動地轉換所有這些調用者。
代碼清潔器
一(yī)直以來，Eclipse都具有一(yī)種相當強大(dà)的代碼格式化功能，以幫助您在整個團隊中(zhōng)應用代碼格式化标準。3.2版本提供了一(yī)個新的“Clean Up”向導(見圖4)，進一(yī)步加強了這一(yī)功能。下(xià)面列出這個向導可以選擇實現的一(yī)些功能:
·删除不用的導出功能。
·删除不用的私有方法和構造器。
·添加缺少的和注釋。
·添加缺少的-NLS昵蛏境槐匾謀昵?/li>
·把所有for循環轉換爲增強的-for循環。
·把控制語句主體(tǐ)轉換爲塊。
·删除不必要的強制轉換。
·爲Serializable和Externalizable類添加連續版本ID。
·Clean Up向導可以在Java文件、軟件包或整個項目上運行。
圖 4. Clean Up向導讓您可以在整個項目範圍内應用一(yī)緻的标準。
結束語
如今，相對于任何其他語言和平台來說，可供Java程序員(yuán)選擇使用的工(gōng)具相當之多。我(wǒ)(wǒ)也搞不清楚這其中(zhōng)的原因——也許是用戶的巨大(dà)能量和積極性所緻，或者是沒有單一(yī)的壟斷供應商(shāng)(例如Microsoft)将其意願強加于平台并将其工(gōng)具直接與平台綁定的結果。無論原因是什麽，Eclipse都能夠與許多備選方案(包括NetBeans、IDEA、JDeveloper和JBuilder)相媲美。随着3.2版本的發行，Eclipse在Java IDE方面有了一(yī)次大(dà)的飛躍，這将會使所有的Java程序員(yuán)受益，不管您最終選擇的是哪一(yī)種工(gōng)具。
475003427