服务热线:13616026886

技术文档 欢迎使用技术文档,我们为你提供从新手到专业开发者的所有资源,你也可以通过它日益精进

位置:首页 > 技术文档 > JAVA > 新手入门 > 基础入门 > 查看文档

eclipse 3.2 java开发新特征全面体验

引言

  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)。

eclipse 3.2 java开发新特征全面体验(图一)
图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版本提供的我最喜欢的特征之一。

eclipse 3.2 java开发新特征全面体验(图二)
图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)实现的。把鼠标停在一个更改块上将显示开发者的姓名、相应的日期和注释信息。它还会高亮在文件的其它部分中作过相同修动的代码。

eclipse 3.2 java开发新特征全面体验(图三)
图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文件、一个包甚至整个工程上运行。

eclipse 3.2 java开发新特征全面体验(图四)
图4."clean up"向导让你在整个工程范围内应用一致的标准。

  结论

  如今,比较于任何其它语言和平台来说,有相当范围的工具可以供java程序员选择利用。我也搞不清楚这其中的原因-也许这是用户的巨大能量和积极性所致,或者是缺乏单个主流供应商的结果。无论什么原因,eclipse都能够与许多选择对象-包括netbeans,idea,jdeveloper和jbuilder-进行媲美。随着3.2版本的发行,eclipse对java ide的许多方面都是一次大的跃进,这将会使所有的java程序员受益,不管你最终选择哪一种工具。

扫描关注微信公众号