Eclipse 3.2冒险之旅

作者:gramophone;gramophone
原文:http://www.matrix.org.cn/resource/article/2006-12-05/Eclipse+3.2_1e27a96c-83fa-11db-bc5a-8183484e8085.html
关键字:Eclipse 3.2;新特性

JDT的开发
JDT的历史可以追溯到1996年左右用Smalltalk开发的Visual Age for Java（VAJ）。在VAJ中，输入的所有内容都在内存中编译、执行。这种设计负载不好，很难进行扩展，陈旧的文件很难被修改。

在1999 年，IDE团队开始开发Visual Age Micro Edition（VAME）。它使用了Java里的标准窗口工具集（Standard Widget Toolkit，SWT）来开发用户界面。VAME的目标就是嵌入式空间。它使用了标准的Java虚拟机（Java VMs），并且把工作台保持在文件系统中。然而文件和文件夹的名字是不可读的UUID。

VAME增加的编译器要比VAJ中的快10倍以上。这种模型的构建是基于状态的（与当前基于资源的的Eclipse不同）。VAME有自己的知识库，称作Rapider，通过插件是可扩展的。

VAME 在社区里没有流行起来。但是它包含了很多好的想法，这些想法在他们开发下一个项目Eclipse时得到应用。2001年，Eclipse 1.0发布。它被描述成“一种IDE，它能够开发任何东西，没有例外的”。从一开始，Eclipse和JDT都是可以作为其他开发工具的平台。工作区被存储在磁盘上，并且对其他人是可见的。Elipse1.0集成了CVS，取代了以前只是开发者自己的知识库。
Eclipse与它的前辈比还有一个很重要的不同：它是开源的。用户社区激增，并且自给自足。Eclipse 3.2的大多数新特性都是Eclipse用户需求的直接结果。自从3.1发布后收到了超过3万份的固定和增强要求。因为要把所有的都讲一遍将花费太多时间（同时也很乏味），我们只强调一些对大多说开发者来说特别重要的。

Eclipse 编译器
JDT最大的特点之一就是内嵌了Java编译器，它是与javac完全相容的。尽管你可以使Eclipse使用Ant和javac，甚至使得问题制造者在IDE中显现出来（这是3.2的新特性），但是Eclipse的编译器能够提供更好的诊断和快速的回转。
JDT编译器最开始是为VAME开发的，后来修改之后用在Eclipse上。它是建立在被开发人员称作“编译三原则”的基础之上，这是仿照Asimov提出的机器人技术的原则：
1.正确性：编译器不应该与源程序相悖
2.有效性：编译器一定要快，除非速度与第一条相矛盾
3.友好性：编译器一定要帮助用户改正编程错误，只要这种帮助不与前两条相矛盾

正确性：当设计一个Java编译器时，不应该仅仅满足规范，而是规范的精神。不要仅仅考虑正确就行了。所以JDT的开发者这些年都在一直努力工作以满足其他编译器已达成的共识，包括Sun公司的。Eclipse 3.2中正确性通过15000例单元测试来检验（相比之下，VAJ用了0例）。

有效性：数千个工程和数百万行的代码组成了标准。其中有许多个暗示，例如内存损耗应该是可预测的和等高的。Eclipse 3.2以最优化的方式继续精炼这些。例如，开发者使用位操作重写了流程图，使得它的执行时间由20%减到4%。

友好性：报告错误也是一门艺术。行号并不足够。二次错误应该最小化。例如，如果你在某一行少写了一个分号，那么它应该不影响依赖于该行的其他行。改进的静态分析会发现错误的模式。Eclipse也检查Javadoc的正确性。

随着3.2的发布，Eclipse编译器是与Java-SE-6.0相容的。正确，尽管在Java 6还没有发布，但是Eclopse已经支持Java 6里的分类（categories）和StackMapTable属性。此外，编译器中有大量的新的诊断模式可以帮助你在执行程序之前发现代码里的错误。与有45种诊断模式的3.2版编译器相比，VAJ里只有三种诊断模式。包括检测在内的一些新特性如下：
●使用明显为null的变量
●检查不必要的null
●随机分配方法参数
●根据前面的情况来进入Switch语句
●使用non-generic（raw）类型
●不使用标签
●不必要的$NON-NLS$标签

上面的大多数默认情况下都是关闭的。你也可以通过@SuppressWarnings注释来使它们失效。

如果你想在Eclipse之外使用Eclipse编译器，那么从3.2开始有单独的下载。它的命令行参数与javac是相容的，并且下载只有1MB左右。因为Eclipse编译器是开源的，所以其他很多项目，如Apache Tomcat，在它们的软件中捆绑了它。

编辑
任何一款开发环境最基本的特征就是编辑器。你把大多数时间都花费在这里，因此编辑器应该舒适、界面友好，并且功能强大。自从Emacs以来，基本上每一款编辑器都内嵌了语言的公共资源的基本信息，这样它能够提供语法高亮。JDT使用Java模型走的更远。例如，它知道类和接口对象的区别，因此能够给它们标以不同的颜色。它甚至能够分析源码的注释，然后告诉你调用的方法是不是不推荐的，同时在调用的方法上画条线以强调这部分代码需要注意。

在这个Java编辑器中最有用的命令之一是Ctrl-Space（内容助手）。记不得某个对象的方法，或者如何拼写某个类名，那么请按Ctrl-Space。 Eclipse会给你提供在给定点正确的所有候选项的列表。Eclipse 3.2继续改进这个特性。例如，你是否发现自己敲入过如“LongJavaName”的长标示符？现在你可以敲入“LJN”，然后按Ctrl- Space，Eclipse就知道你是什么意思。这叫做CamelCase completion（注：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建议就会排在最前面以便你更快地取得它。代码生成甚至在Javadoc中也起作用。因此你可以创建一个@links 或者正则表达式而不需要记住那些冗长的名字。

你是否问过自己，“如果IDE足够智能，能够指出这行的错误，为什么它不能改正它呢？”。Eclipse有一个称作快速修补（Quick Fix）的特性，它做的要比那多。把光标移到有问题的那行上，然后按Ctrl-1，Eclipse会提供改正错误的建议。

Eclipse 的每一次发布都会添加新的快速修补。例如，在3.2中，如果使用粗类型（raw types）时得到警告，把光标移到那行，按下Ctrl-1，然后选择“Add type parameters”来修改。同样是在3.2中，快速修补不仅能够修正同一文件中的许多常见问题，甚至能够处理多个文件，这样就不用对每一个问题分别进行处理。

另外一个我想提到的重要特性是“类型的重命名”（rename type）。你是不是也像我一样，经常把变量和方法命名成与类型相似。例如，如果你有一个Bar类型，或许你有一个叫做fBar的变量，一个叫 createBar的方法（见图2）。问题是，如果你想把Bar进行重命名，那么其他许多地方也要被修改。然而在3.2中，根据类型的变化来改变那些与类型有相似名字的变量和方法变得很容易。这个神奇的重命名是3.2中我最喜欢的特性。


图2 当你在Eclipse 3.2中修改类型的名字时，它提供了修改与类型有相似名字的变量和方法的名字的途径

运行
在一些IDE中，你设置某个工程是主要工程，然后使用一个全局运行命令来运行程序。Eclipse的工作方式不同于此。在Eclipse中，你有个初始配置列表，包括运行，调试，测试代码的足够信息，如命令行参数，类路径，JRE版本等等。通过使用过滤和执行环境，Eclipse 3.2使得管理初始配置很容易。

过滤可以减少列出来的配置，使得出现的都是你感兴趣的。执行环境使得你可以描述Java运行时的相容性，你可以使用如“J2SE-1.4”这样普通的名字。Eclipse会选择满足或者超过你对环境要求的JRE。

你是否发现在开发的时候要多次进行测试？在3.2中，你可以同时运行多个测试，同时你也可以返回察看前一次运行的历史纪录。Eclipse 3.2同时也支持最新版——4.0版的JUnit。

团队合作
你是否发现自己在一行不知道是谁编写的，为什么在这里编写的代码处开始工作？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文件时，生成的重构脚本可以自动地修改所有的调用者。

代码卫生（Code Hygiene）
Eclipse长期以来一直都提供了强大的代码格式，帮助你在整个团队里都使用一样的代码格式标准。3.2版通过提供Clean Up向导使得这更进一步（见图4）。下面就是这个向导可以选择性地做得事情：
?        移除没有使用的引入（imports）
?        移除没有使用的私有方法和构造函数
?        添加缺少的@Override和@Deprecated注释
?        添加缺少的$NON-NLS$标签，或者移除不必要的
?        把所有的for循环转化成增强的for循环
?        把控制语句部分转化成控制块
?        移除不必要的映射
?        给Serializable和Externalizable类增加连续版本ID（serial version ID）

这个Clean Up向导可以在Java文件，包，或者整个工程级别上运行。


图4  Clean Up向导让你可以在整个工程中都使用一致的标准

总结
Java 程序员可以在大量的开发环境中工作，这比其他语言和平台要多得多。我不知道为什么会这样，或许是用户活力和激情的结果，或许是缺少单一的占支配性地位得卖主，像Microsoft，把它们的意志和工具强加在平台上。不管什么原因，Eclipse和其他产品竞争，包括NetBeans，IDEA， JDeveloper和JBuilder。随着3.2的发布，Eclipse再次提高了Java IDE的横杆，这将使得所有的Java程序员都受益而不管你最终选择的是何种工具。

资源
Matrix:http://www.matrix.org.cn
作者的博客:http://blogs.zdnet.com/Burnette/

Ed Burnette是一个资深开发者和作者，目前住在北卡罗莱纳州的卡里