Apache发布Groovy 2.5正式版及3.0预览版

栏目: Groovy · 发布时间: 6年前

内容简介：Apache基金会最近发布了运行Groovy 2.5至少需要JDK 7，在JDK 9+上运行可以忽略良性警告。尽管最近人们把关注点转到了其他JVM语言上（如Kotlin），但Groovy仍然有很大的增长。正如Groovy提交者、

Apache基金会最近发布了 Groovy 2.5，新功能包括：

AST转换的改进

新的宏支持

其他杂项改进

运行Groovy 2.5至少需要JDK 7，在JDK 9+上运行可以忽略良性警告。

尽管最近人们把关注点转到了其他JVM语言上（如Kotlin），但Groovy仍然有很大的增长。正如Groovy提交者、 OCI 首席软件工程师Paul King博士在最近的一次网络研讨会上所说的：

Groovy的下载量说明，它仍然是继 Java 之后JVM上第二大最受欢迎的语言，而且这个数字还在不断增加。今年第一季度，下载次数为9000万次，比去年第一季度下载次数的两倍还要多。所以我们可以看到，人们仍然对Groovy很感兴趣。

在过去的12个月里，Groovy增加了30个新的提交者。

AST转换——注解

如下图所示，为了保证转换之间的一致性，对很多现有的AST转换进行了改进，并在2.5版本中添加了11个新的转换。在Groovy 3.0中添加了一个额外的转换，但在GA发布之前可能会出现更多转换。

Apache发布Groovy 2.5正式版及3.0预览版

AST转换——宏

如上所述，Groovy提供了大量的内置AST转换。开发人员也可以创建自己的自定义转换，前提是需要了解Groovy语法结构的内部表示。

2.5版本中的宏功能消除了了解语法结构内部表示的需要，正如发行说明中所定义的那样：

在创建编译时元编程扩展时，宏可以让你直接使用Groovy语法，而不是使用内部编译器表示。因此，转换的创建将掌握在所有Groovy程序员手中，而不仅仅是Groovy编译器创建者。

例如，假设开发人员希望创建一个转换（ @Info ），用于生成一个方法（ @getInfo() ）。在2.5版本之前，需要编写以下代码：

...
def clazz = new MethodCallExpression(new VariableExpression("this"), "getClass", EMPTY_ARGUMENTS)
def body = new ExpressionStatement(new MethodCallExpression(clazz, "getName", EMPTY_ARGUMENTS))
classNode.addMethod('getInfo', ACC_PUBLIC, STRING_TYPE, EMPTY_ARRAY, ClassNode.EMPTY_ARRAY, body)
...

有了宏以后，上面代码中的前两行可以替换为：

def body = macro(true) {
    getClass().name
    }

更多详细信息可以查看发行说明。

Groovy 3.0

Groovy 3.0.0-alpha-3从6月下旬开始就可用，并计划于今年晚些时候推出其他beta版，候选版本预计于2019年初发布。

Groovy 3.0至少需要JDK 8才能运行，并对JDK 9及更高版本的支持进行了改进。一个名为Parrot Parser的新解析器将支持新的Groovy语法，这是一个重要的新特性。

InfoQ就最新版本的发布采访了King。

InfoQ：你能谈谈默认的Indy解析器和Groovy 3.0的新解析器Parrot之间的区别吗？

Paul King：要了解“Indy”和“Parrot”之间的区别，需要了解更多的细节。Groovy的解析器分多个阶段完成它的工作。早期阶段读取源代码并将其转换为内部抽象语法树（AST）表示，后续阶段将AST转换为可在JVM上运行的字节码，与从Java编译器生成的字节码运行的方式几乎相同。

当我们谈论“Parrot”解析器时，指的是Groovy 3中经过完全改进的编译器早期阶段。它经过重新设计，更加灵活，并使用了最新的技术。这方面的工作让Groovy能够进行快速演化，这意味着我们可以将Java中为“剪切”兼容性而做出的变更与原生Groovy变更结合在一起。

当我们谈论“Indy”时，它指的是编译器在后续阶段生成的字节码类型。在Groovy 2.0到2.5版本中，我们支持生成“经典”版本以及“Indy”版本的Groovy字节码。Indy版本的字节码的生成使用了JDK 7中引入的“INvoke DYnamic”字节码指令。尽管这些指令被添加到JVM中是出于多种原因，但其中的一个特定用处是用它们提升Groovy等动态语言的性能。支持这些字节码指令的JDK的早期版本包含了一些错误，虽然某些地方的性能有所提升，但其他地方在使用传统的字节码指令时速度更快，如手动编码的原始类型优化。为此，我们一直支持这两种变体。Groovy 3编译器的alpha版本仍然支持这两个变体，不过我们正在努力将Indy变体作为默认的选项，并进行其他的一些优化，争取完全移除旧的变体。

InfoQ：Groovy中提供了大量内置的AST转换，那么开发人员在什么情况下会编写自定义的AST转换？

King：AST转换可以用在很多场景中。可以用它们来移除样板代码、捕获常见的设计模式和编码样式，以及支持声明性编程。我们确实在Groovy中捆绑了很多有用的AST转换，我们认为它们都是可被广泛应用的转换。在以下这些显而易见的情况下，开发人员需要创建自己的AST转换：

如果某些转换有特殊用途，我们不太可能将它包含在Groovy中。
如果有人不喜欢内置转换提供的行为，并且无法使用注解属性来自定义行为，那么他们可以试试其他方式。首先，他们可以使用元注解功能将我们注解的组合“捆绑”在一起，也可以将它们与Spring注解结合起来。如果这样还不能满足他们的需求，那么就需要自定义一个。
有人可能正在编写特定于其领域的DSL，并希望在DSL中加入注解。这只是编写DSL时的一个选项。
有人可能正在编写自己的框架，并希望提供强大的注解，以简化框架用户的编码工作。

举个例子，Grails光是在Grails-core中就使用了大约20个AST转换，Griffon也增加了不少AST转换。Micronaut的AST转换需要处理超过100个注解。

InfoQ：有了新的宏功能，你是否预计会有更多开发人员编写自定义的AST转换？

King：毫无疑问，人们需要一些时间熟悉宏。但是，一旦有了一些例子，通常会出现雪球效应。我们必须拭目以待。在任何情况下，我都可以看到我们在Groovy代码库中添加了很多内容。

InfoQ：新的JDK发布节奏是否会影响Groovy开发？

King：是的，更快的发布节奏有一些非常好的方面，但它也给很多开源项目带来了压力。Groovy尝试运行尽可能多的JDK版本。版本越多，就越难做到。不仅我们需要做很多额外的工作，我们还依赖其他开源工具，这些工具必须保持最新，并且在各个版本中保持足够的一致性，这样我们才能够保持兼容。或许JPMS对我们的影响更大。它带来的一些变化仍在我们的待办事项列表中，在发布Groovy 3.0 GA之前需要修复它们。

InfoQ：是否有计划让Groovy 3.0支持JDK 11？

King：Groovy 3.0已经非正式地支持JDK11。它可以使用最近的JDK11 EA版本进行构建，一些测试套件也运行良好。就Java源代码兼容性而言，我们已经支持在局部变量lambda参数（JEP 323）中使用var作为def的别名，所以即使是在JDK 8上运行，你也可以在Groovy中定义lambda，如下所示：