Guillaume Laforge谈Groovy 2.1

近日，SpringSource发布了Groovy 2.1。

在该版本中，Groovy添加了几个新特性：

• 完全支持Java 7的invokedynamic
• 通过特殊的注解来辅助文档与领域特定语言的类型安全，超越了传统的静态类型检查能力
• 新增的编译自定义选项
• 用于组合注解的元注解设施
• GPars 1.0，Groovy的并发框架

InfoQ有幸采访了SpringSource Groovy部门的领导Guillaume Laforge以了解这些变化以及Groovy的成功之处。

InfoQ：invokedynamic是如何简化Groovy运行时的开发工作的？

Laforge：我们不能说invokedynamic简化了Groovy运行时的开发工作，我们依然将精力放在常规的缓存技术上以加快动态运行时的速度，因为我们希望用户依然可以使用JDK 5或6。实现invokedynamic并不是那么简单的事情，因为各种JDK 7更新并不是完全稳定且没有瑕疵的。幸好，随着底层VM实现与APIs的不断成熟，这种情况已经有了极大的改观。因此，在未来的Groovy版本（如Groovy 3）中将只会使用invokedynamic，那时JDK 7将是所需的JDK的最低版本。接下来，我们就可以摆脱自己所用的一些小技巧，而不必在代码基上使用两套代码路径了。

InfoQ：invokedynamic在性能上是否有明显的改进呢？

Laforge：invokedynamic可以让我们更具效率，特别是在内存使用上，因为我们就不需要在运行时生成那么多的类了，这样占用的内存会更少。对于性能来说，我们已经注意到一些重大的改进了。现在还很难给出一个百分比数字，因为在不同的微基准上，其变化还是非常大的。

InfoQ：哪些用例能从这种性能改进上获得最大的好处？

Laforge：Groovy已经在使用原生类型计算方式了，因此对于那些数学密集型基准来说，Groovy的运行速度已经与Java不分伯仲了，所以说invokedynamic对于速度上的提升并没有那么大。

大量依赖方法调用的代码会得到最好的改进，在某些情况下，方法调用的速度是以前的两倍之多！此外，结果在很大程度上还取决于我们所用的JDK 7更新版本。总的来说，结果很不错，我们对invokedynamic很满意。

此外，invokedynamic还有助于优化我们的代码基，因此对于那些无法升级至JDK 7的用户来说可以从中获益。最终，对于动态代码来说，invokedynamic可以使我们在很多情况下都能达到与老的优化技术相当的结果，而且还不会引入他们的缺点。如果使用我们在Groovy 2.0中所添加的静态编译特性，那么代码可以与Java一样类型安全，速度也有保证。

InfoQ：为了保证语言的可读性，你在引入或拒绝新的语言概念时遵从什么样的流程呢？

Laforge：语言演化是个很有意思的问题。在过去几年中，我们对语言新特性添加的要求更为严格，因为我们不希望语言变得过于复杂而无法理解与使用。此外，我们还严格坚持某些基本的可读性与一致性原则。

首要的是，我们一直希望能与Java的语法保持紧密的联系，这样Groovy学习起来就会容易一些，更易于被具有Java背景的新的开发者所用。据说，每个Java开发者实际上都是Groovy开发者！

其次，我们不希望简洁导致语言变得过于神秘。我们总是希望Groovy成为一门易于学习且维护的语言。这正是我们为何不使用ASCII-art操作符的原因所在，因为没人能够理解它。

在社区的帮助下，我们总能在语言特性上达成一致，能够在简洁、效率与可读性上达到最佳的平衡，这可以确保语言的优雅性与易用性。

InfoQ：显然，invokedynamic要求你抛弃过去的一些代码，为了避免回归问题需要做哪些测试呢？

Laforge：在过去几年中，我们积累了大量的测试套件，包含了来自于用户、框架开发者等的用例，这都是为了强化实现以避免向后不兼容问题的发生。我们在各种系统环境和JDK版本下运行了所有的测试套件，就是为了确保高质量与向后兼容性。

InfoQ：在2.1版中引入了哪些其他的编译自定义优化特性呢？

Laforge：Groovy 2.1在编译定制化方面进行了一些精化。

Groovy非常适合于实现领域特定语言，出于这个目的，Groovy带有很多技巧，开发者可以操纵已经编译好的代码。你可以挂进编译过程来转换代码（我们称之为“AST转换”，可以将其看作是一种编译宏），比如说，可以添加新方法、添加导入，也可以限制语法元素等。

Groovy 2.1简化了配置编译器以使用这些技术的过程，你可以使用特殊目的的DSL（Groovy“构建器”）来描述编译器的配置，用户也可以指定包含自定义配置的脚本位置，然后传递给Groovy编译器。

最后，我们的目标是简化想要进一步利用Groovy领域特定语言能力的开发者与框架作者的工作量。

InfoQ：能否介绍一下新的元注解特性么？

Laforge：注解在Java生态圈中得到了很好的应用。但有时使用的注解有些太多了，对于一个简单的成员变量、方法或是类来说，你可能会声明好几个注解。

在Groovy生态圈中，我们使用注解来触发某些AST转换，给定的类集（就像是应用的领域类）可能一直都需要相同的注解集，因此你可能想要将几个注解放到一个当中。这正是元注解系统想法由来的原因。

某些框架（如Spring Framework）提供了定义元注解的功能。这通常是特定于框架的解决方案，我们想要更加通用一些的解决方案，这样就可以脱离特定的框架而使用了。

我们这里的做法是在编译期使用元注解所包含的注解来替换掉它。通过这种方式，类、成员变量、方法与参数会使用组合后的注解，而不是框架在运行期需要处理的元注解。

最后，借助于元注解，代码的可读性与表述力会更好，你可以在编译期而非运行期使用包含其他注解的更高层的注解。

InfoQ：Groovy的下一个主发布会有哪些值得期待的特性呢？

Laforge：在Groovy的下一个主版本中，我们尚未计划任何重要的语言特性。显然，我们已经有了一些关于新特性的想法，但我们还是将大部分精力放在了语言的架构与实现上：其动态特性、编译后端与语法等等。

目前，我们正在为完全重写的动态后端编写一个原型（“Meta-Object Protocol”），该原型完全基于invokedynamic，这么做是为了更好地利用JVM的性能，促进我们的动态特性。

稍后，我们将使用新发布的Antlr v4分析程序生成器来重写语言的语法，这是为了保证语法的平稳进化，同时确保语法的维护工作能更加容易一些。

查看英文原文：InfoQ Speaks to Guillaume Laforge about the Recent Groovy 2.1 Release