您的当前位置:首页正文

Guillaume Laforge谈Groovy 2.1

2024-11-29 来源:个人技术集锦


近日,SpringSource发布了。

在该版本中,Groovy添加了几个新特性:

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

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

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

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分析程序生成器来重写语言的语法,这是为了保证语法的平稳进化,同时确保语法的维护工作能更加容易一些。

查看英文原文:

显示全文