近日,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
评论