BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

动态语言IDE:来自Groovy-Eclipse的新闻

| 作者 Mirko Stocker 关注 0 他的粉丝 ,译者 宋玮 关注 0 他的粉丝 发布于 2008年12月27日. 估计阅读时间: 7 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

这一条新闻属于我们有关动态语言IDE系列文章的一部分。第一篇是有关Ruby IDE的,其他部分可以通过DynamicLanguageIDEs标签找到。

现在SpringSource已经收购了Groovy和Grails的幕后公司,Groovy的普及率将进一步提高,并对Java开发者更具吸引力。

我们采访了Groovy Eclipse项目的领导James Ervin,询问了他们当前的工作情况:

目前由我和另外几个感兴趣的人一起开发这一plugin。Guillaume La Forge让我担当项目领导,因此我能够更新该plugin的官方版本,将已积累了一段时间的问题修复包含在内。我目前主要集中在稳定性、简化、定期发布版本并跟踪JIRA站点上的一些顶级问题等。例如,我正设法完成利用Groovy编译器中联合编译(joint compilation)能力(在需要的时候,委托Javac同时编译Java和Groovy的能力)方面的工作。这将解决那些涉及到附加二进制groovy目标目录的令人头疼的问题,以及用Groovy编写的代码与用Java编写的代码交叉依赖的问题。Michael Klenk和他的小组在Groovy Eclipse对重构(refactoring)的支持方面做了许多卓越的工作。在我完成手头的任务之后,集成他们的工作将是我的首要任务。

Groovy-Eclipse已经包含了Groovy实现因而并不需要一个外部Groovy:

Groovy Eclipse包含一个内嵌的Groovy运行时库,它本身是一个独立的Eclipse plugin(或者按OSGi的说法,一个bundle)。之所以这样,有以下几个原因:首先,一个内嵌的运行时可以让我们有机会使用Groovy编写该插件的部分内容。如俗话所说,这无异于“吃自己的狗食。”我更喜欢原始的表达,它更符合你的意愿,然而这却是一个友好的设置。其次,包含一个内嵌的运行时库,显然可以让用户跳过安装运行时这一步。最后,实际上是缺点,我们使用内嵌的groovy运行时来解析和编译项目中的代码。最后一点对我来说是痛处,我在“Groovy Eclipse路线图”中已做了说明。

看一下这个路线图,我们可以看到几个有趣的内容:

  • [...]提供至少一个支持Grails开发的基础层。我知道在提供Grails支持方面已经有一些现成工作了,但是我知道那是非常基础的那一类,Grails还有很多东西强烈要求IDE予以支持。
  • [...]能够在Eclipse Plugin开发过程中使用Groovy语言。这实际上更多的是一个个人意愿,我认为对Grails的支持或我所罗列的其他各点将会影响更多的人。能够用Groovy来做越来越多地Groovy Eclipse开发工作还是非常好的,不是吗?我是这么认为的。这样做的部分结果是,我们可以尝试利用和改善对EMF的Groovy支持。
  • [...]Groovy编译器与Eclipse JDT支持能够更好地集成。我看到Scala Eclipse plugin中的一个例子,其中该项目把Eclipse Java性质增加进了该项目,但是Java Builder并没有增加进来。这就允许Scala plugin提供Scala工具来构建类文件。我想Groovy Eclipse应该具备相似的功能,既然groovy编译器现在也要编译Java,那就更应如此了。

Groovy IDE的其他实现一定也在努力解决类似的问题,你们之间有协作吗?

我已经参与了GROCIDE项目的若干讨论,这在我的Groovy Eclipse优先级列表中也被排在较高优先级。我们第一位的问题是本项目没有资源(即,工时,尤其是专职的),但是各个IDE支持工具可以共享许多东西。这是我们必须包含进来的,尤其是有这么多高人针对Groovy在IntelliJ和NetBeans工具支持上已经做出了不少卓越的工作,我们更应该这样做。

我欲做出如下总结。我在Codehaus上Groovy Eclipse项目的主页里增加了如下内容:

“Groovy Eclipse plugin的目标是提升Groovy平台和生态系统,使其对工作于Eclipse SDK中的Java开发者来说,成为一个可行且高效的开发环境。”

这是尽我所能对我的目标所进行的臆测。今天,至少在北美,大量的Java开发是在Eclipse SDK上进行的。我想让Groovy兴旺起来,但是要做到这一点,我们必须为Eclipse做出一个非常好的Groovy plugin!

至于James所提到的重构,我们采访了Michael Klenk:

我们是从实现Extract Method重构功能开始着手的。在第一小步之后,我们开始实现其他的重构功能:Inline Method,重命名方法、变量、属性及类。我们还提供了一个源代码格式化工具以及一个支持开发者日常工作的层级视图。

你所提到的这些重构功能与手工操作(比方说重命名)相比有多好?

起先,查找并替换看起来是个不错的开始,但是程序中的名字通常是处于一个上下文中的,理解这一点非常重要。想象一下,如果写了两个方法,每个都声明了一个局部变量,且名字一致。用简单地查找和替换,你必须手工决定应该重命名哪一个变量。

另一个能证明重构多么智能的例子是:创建一个接口,它声明了一个抽象方法。现在这个方法在好几个类中都实现了。如果你要重命名这个方法,必须检查继承层次中的所有类,以找到应该做出改变的所有位置。

对于Groovy代码的抽象语法树的分析,可以让我们搜集到我们需要的所有相关信息。

这个列表给人的印象已经相当深刻了,这些特性将会包含在哪个版本中呢?

我们把所有这些重构特性都整合到Groovy-Eclipse项目开发主干中了。很快就会发布一个稳定版,届时所有开发者都可以使用这些重构特性。我们希望多数用户都使用这些重构特性并反馈改进意见。我们正在考虑实现的另一个比较酷的特性是,Java和Groovy语言间跨语言的重构特性。

Groovy-Eclipse的官方网站和专门的Groovy-Eclipse重构网站可以获得更多信息。

这一条新闻是我们有关动态语言IDE系列文章的一部分。其他部分可以在InfoQ的DynamicLanguageIDEs标签下找到。

查看英文原文:Dynamic Language IDEs: News From Groovy-Eclipse

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

值得期待 by 果 林


能够在Eclipse Plugin开发过程中使用Groovy语言


哇~·· 扩展下去,所有在Eclipse下开发的Java应用允许Java和Groovy混用,那将是一个很美好的远景。

Re: 值得期待 by GAO Sean

等Groovy的Eclipse插件很久了,之前的版本基本没法用。

看看隔壁NetBeans,唉,不知道什么时候才能在Eclipse环境下放心的铺开使用Groovy。

Re: 值得期待 by GAO Sean

@林果

方便易用的cross-compile是一个必须要实现的功能,否则在天生对Java支持良好的Eclipse环境下,Groovy插件没啥用武之地,就像被"阉割"了Wi-Fi的iPhone。

Eclipse 做 Groovy 和 Grails 开发还有很多问题 by Yang Lifan

用 Eclipse 做 Groovy 和 Grails 的开发的确还有很多问题,不如 NetBeans 来的方便。不过 NetBeans 调试 Grails 应用好像不如 Eclipse 来的好用

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT