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

最新推荐文章于 2022-04-02 14:11:24 发布

原创最新推荐文章于 2022-04-02 14:11:24 发布 · 93 阅读

CC 4.0 BY-SA版权

Groovy-Eclipse项目领导James Ervin介绍了当前的工作重点，包括稳定性改进、简化、定期发布和解决代码交叉依赖等问题。此外，Michael Klenk讨论了重构功能的实现，包括Extract Method、Inline Method以及重命名等，这些功能旨在提升Groovy开发效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这一条新闻属于我们有关动态语言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代码的抽象语法树的分析，可以让我们搜集到我们需要的所有相关信息。

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