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