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

这一条新闻属于我们有关动态语言 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