groovy 2.5.4
如今，流行的动态语言Groovy终于发布了2.0版本 ，这标志着其开发方面的重大变化。 此里程碑式里程碑的新功能包括静态类型检查器，它可使编译器告诉您代码的正确性，静态编译和新的模块化方法。 在Project Coin和Invokedynamic中，JDK 7也有了一些飞跃，从而保持了Groovy与Java的紧密联系。
SpringSource的Groovy项目负责人Guillaume Laforge是Groovy 2.0背后的关键人物之一。 最近在4月的Java技术期刊：Groovy宇宙中，我们与他进行了交谈，当时正在为发布做最后的准备。 第1部分讨论了Groovy的起源和2.0版本，而第2部分则讨论了以Java为中心的更新和该语言的未来。
尽管Groovy 2.0可能在5月发布，但值得等待。 我们很高兴终于可以在此向Groovy社区提供他们喜欢的语言的重要更新……
——-
JAX首先，第一件事是：版本号更改。 为什么要这样做，从1.8切换到2.0，却总共丢掉1.9？
Guillaume Laforge ：在项目生命周期中，从1.1切换到1.5时已经发生过一次。 这是我们第二次进行较大的版本号更改以反映版本的重要性。 最初，1.9（现在称为2.0）的功能范围较小。 但是，尽管该发行版完成了所有工作，但我们认为使该发行版显示为“次要”版本并不是很公平，尽管它相当重要。 我们的“点发布”一直是我们心目中的主要发布，因此旧的命名方案并未真正反映出该方面。 因此，从现在开始，我们认为的主要版本将真正具有一个可以反映这一点的版本号。 但请放心，我们不会增加Web浏览器之类的版本号！
JAX：此过程在1.8到2.0之间进行了多长时间？ 有多少提交者参与其中？
Laforge ：我们通常每年或最多一年半发布一个主要版本（当然，第一个1.0版本除外）。 因此2.0应该很快就会发布，希望在五月。 由于发布的范围会随着时间的推移而变化，因此很难给出确切的日期，而且还取决于我们的贡献者投入项目的时间等。我们总是有一些非常活跃的提交者（有些专职工作）在项目上），还有更多的人偶尔会为特定主题做出贡献。
JAX：您可以首先解释Groovy背后的一些关键概念吗？ 您是否对Java的某些方面感到沮丧，还是想对其进行改进？
Laforge ：的确，Groovy确实以某种方式对Java的某些方面感到沮丧而开始。 多年来，我们希望在Java中拥有许多其他语言可以提供的有趣功能，但是不幸的是这些功能不可用。 例如，闭包。 自2003年以来，Groovy就开始使用闭包，而在一两年之内只有JDK 8才使用Java编程语言。 不过请不要误会，我们确实喜欢Java，并且通常以Groovy为Java的表亲或最好的朋友来宣传，因为两种语言之间的互操作性一直是我们的主要关注点，甚至实际上是设计目标，因此Java开发人员可以立即在Groovy中提高生产力，而无需遵循任何陡峭的学习曲线。
Groovy的核心是在Java语法的基础上以多种方式扩展Java的语法，以使代码更简洁和更具表现力。 该语言的主要设计目标一直是生产力：确保Groovy开发人员可以专注于手头的关键业务任务，而不是编写过多的样板代码以防止他们编写业务逻辑。 除了Java开发人员非常熟悉的语法外，Groovy还增加了诸如闭包之类的关键功能，一些易于编程的函数式编程风格以轻松处理集合以简化复杂算法的编写，并且对关键JDK API进行了许多改进以增加缺少的功能。
另外，Groovy的本质是成为一种“动态”语言。 这是一种具有多个调度运行时的语言，而不是静态编译的行为。 它为库或框架作者提供了非常有趣的观点。 诸如Grails，Gradle，GPars，Griffon，Spock等项目，都在利用这些方面，以使其使用变得非常容易和可读。
JAX：Groovy被描述为一种强大的语言，吸收了Java和其他语言的概念。 什么使Groovy与其他JVM语言区分开？ 特定领域的语言？ AST转换？
Laforge ：您将手指放在Groovy的两个主要 优点 上。 我还要添加第三个相关点，即脚本的可编写性和可嵌入性。 特定于领域的语言（DSL）凭借其简洁，灵活的特性和元编程功能，很容易用Groovy编写。 您可以执行一些操作，例如为数字添加属性，编写类似于英语的句子，使某些运算符重载等。将所有这些技术组合在一起时，与仅使用Java API相比，您的业务逻辑变得更加可读，易于理解和维护。 这就是为什么Groovy经常在垂直应用程序（金融，医疗等）中用作业务语言。
由于我添加的第三点，这也是可能的，因为您可以轻松地将Groovy嵌入Java应用程序（Spring，Java EE，任何框架）中。 因此，您可以让Groovy仅涵盖业务逻辑方面，而基础结构技术代码只是Java。
实际上，AST转换（抽象语法树）是DSL方面的一部分，因为它是可用于操纵Groovy语言以适应特定业务需求的技术之一。 您可以以某种方式劫持该语言的语法，并将其弯曲或限制为您的需要，以更好地表示您正在使用的域的概念。
JAX：就功能而言，Groovy 2.0的主要目标是什么？
Laforge ：拥有大约100万Groovy用户，我们已经意识到，如今使用Groovy的方式有很多，而且显然不是每个人都需要相同的东西。 Groovy用户使用Groovy编写了成熟的应用程序，而其他用户只是将Groovy业务规则嵌入其Java应用程序中。 有些人将Groovy用作更灵活的Java。 还有一些用户需要性能来进行大量计算，而其他用户则对模板功能感兴趣，而对Swing UI功能则不感兴趣，反之亦然。 这就是为什么此版本的关键主题是安全性，性能和模块化。
首先，关于“安全性”，使用Groovy作为更灵活的Java的Java开发人员倾向于像使用Java一样喜欢使用Groovy。 因此，他们不需要Groovy的所有动态方面。 他们还希望能够获得针对简单错误的编译时错误，例如方法名称或变量名中的拼写错误，其分配的类型错误等。这就是Groovy 2.0提出新的AST转换以带来编译时类型检查的原因，这会使编译器变得脾气暴躁，并抱怨常见错误。
现在，关于“性能”。 如果您不需要动态功能，我们也可以将您的代码编译为与javac生成的字节码几乎相同的字节码，从而获得与Java相同的速度！ 对于使用更多实时系统等的人来说，这是一个令人信服的论点。但是，如果您依赖Groovy的动态功能，请不要担心，因为JDK 7“调用动态”支持即使对于应用程序逻辑的那些动态部分，也将带来一些不错的性能改进。
并且本着“并非每个人都需要所有东西”的精神，我们将重点放在模块化上，将Groovy库拆分成较小的模块，以便用户可以只选择他们感兴趣的模块。我需要Ant脚本功能，但不需要秋千支持。 我需要模板功能，而不是JMX支持等。在进一步的发展中，它还应该使我们能够更轻松地开发API，以便我们可以提供当前拥有的更新更好的API。
JAX：您已经升级到JDK 7，并增加了许多JDK 7支持。 这种进展自然吗？ 为什么现在做出这个决定？
Laforge ：从某种意义上说，我们已经“升级”到JDK 7，因为它为在JDK 7上运行的用户提供了一些特殊的支持。这里特别重要的两个方面是：项目硬币语法增强和Invoke Dynamic支持。 我们将采用大多数JDK 7语法增强功能，因为Java开发人员将逐渐熟悉它们，因此他们希望在Groovy中也可以使用它们。 第二个方面是通过使用新的Invoke Dynamic字节码指令和API来加速Groovy的动态方法调用，其方法缓存功能等等，从而继续提高Groovy运行时的性能，尤其是其动态心脏。 尽管前者在语法添加方面是可见的，但后者对我们的用户是透明的，因为他们将从性能改进中受益，而无需更改程序中的任何内容。
因此，考虑到Groovy和Java与其他替代语言的紧密性和互操作性，这是一个继续从更新的JDK的新颖性中受益的自然决定。
为什么现在？ 好吧，现在，尽管Java 6仍然是占主导地位的Java版本，但是JDK 7的部署越来越多，因此Java开发人员正在采用它，并且希望利用Java 7和JDK的那些新功能。
JAX：告诉我们更多有关从Project Coin引入新事物的信息吗？
Laforge ：源自Java 5语法的Groovy语法意味着很大一部分Java程序实际上也是有效的Groovy程序！ 一些人甚至经常将其称为“复制粘贴”兼容性–请注意将Java代码段复制到Groovy程序中这种容易出错的方法！
确实，Groovy初学者用户经常使用非常像Java的语法在Groovy中进行编码。 随着他们对Groovy的了解不断发展，他们逐渐利用了Groovy提供的各种快捷方式和API。
考虑到语法级别的兼容性，我们希望我们的用户希望能够重用Java 7语法增强功能（即新的Project Coin语法元素）中发现的某些新颖性。 Groovy用户已经习惯了其中一些，例如，自2003年以来，Groovy用户已经能够在其switch / case块中使用Strings和更多类型。但是很高兴看到Java仍在发展，尽管速度较慢。
因此，Groovy 2.0用户将能够使用新的二进制文字，数字文字下划线，菱形运算符等。当前，唯一不支持的语法是try / resource位，因为Groovy已经提供了许多方法来处理作为其API的一部分，包括资源，流，文件等。 我们将查看用户群是否有需求来决定是否最终还要支持该功能。
另外，有趣的是，尽管在Java 7和更高版本中都可以使用Project Coin方面，但是即使在JDK 5之上运行Groovy，Groovy用户也可以使用这些增强功能！ 他们现在可以使用将来最终升级到JDK 7时将要使用的功能！
JAX：您能否详细介绍JDK 7支持的一些新的主要方面？ 您为什么决定添加调用动态支持和静态类型检查？ Groovy社区对他们有什么要求吗？
Laforge ：因此，我们已经提到了Project Coin语法增强功能，您可以在顶级JDK 5+上使用它。 我们将添加Invoke Dynamic支持，以从JDK 7提供的动态语言的性能改进中受益。生产力，简化和有效的语法始终是Groovy语言开发人员所重视的主题。 静态类型检查和静态编译肯定会吸引对动态语言具有先验知识或想要类型安全或类似Java的速度的Java开发人员。 因此，它肯定会增加语言的使用范围，以吸引新用户并涵盖更多用例。
JAX：转向模块方法有什么好处？ Groovy怎么做到的？
Laforge ：Groovy以JAR的形式提供，您可以在项目中将其用作库。 并且作为发行版的一部分，带有命令行和UI工具以及第三方库。 Groovy库包含语言本身（解析器，编译器等），但在诸如Swing，JDK集合类，Ant脚本，JMX集成，模板等功能之外还具有许多库增强功能。正如我之前所说，并不是每个人都需要所有东西，因此能够只拾取您感兴趣的位非常重要，这样您可以在项目中添加较小的依赖项。 此外，模块化将使我们将来能够更轻松地开发Groovy提供的API，以便用户可以升级到可能出现的更新更好的版本。
因此，我们将Groovy源代码和JAR分为较小的子项目和模块，最终将形成具有特定功能的其他JAR。 然后，您可以在需要时将其导入项目中的特定模块。 这也将使我们能够继续扩展Groovy提供的API集，因为考虑到Groovy运行时的大小，我们有点不愿意添加新的API支持。 但是有了模块化，我们将能够更轻松地添加新的API。
JTJ：重申一下，JDK5 / 6中仍然会支持这些功能，对吗？
Laforge ：是的，计划是继续支持Groovy 2.0的JDK 5和更高版本。 我们仍然有Groovy用户对JDK 5有所了解，因此我们试图与他们保持公平，并允许他们继续使用Groovy，直到他们有时间迁移到较新的JDK为止。 但是对于更高的Groovy版本，我们肯定会需要更新的JDK作为基础，甚至可能会跳到JDK 7作为新的基础。 仍有待辩论。
JAX：Groovy的最佳属性是什么？ 您认为与Java和其他语言相比有优势吗？
Laforge ：Groovy一直是任何基于JDK的项目的非常好的伴侣，并且Groovy始终与Java进行无缝的互操作。 尽管提供了一定程度的集成，但这是其他替代语言经常忽略的关键优势。
对于大型Java开发人员社区，Groovy的语法非常易于学习和使用。 因此，与许多其他竞争性替代语言相比，它们的语法和语法可能太陌生，或者需要博士才能理解一行代码，因此学习和掌握起来要容易得多。
与其他语言相比，Groovy无疑在JVM平台上的学习曲线和易用性方面闪耀。
JAX：还有很多其他项目是对Groovy的致敬，例如Gradle，Grails和最近为Groovy 1.8添加的GPar。 您是否认为在某种程度上有助于围绕语言建立了一个充满活力的社区？
Laforge ：Groovy是一个非常受欢迎的项目，全世界许多开发人员都将其用于非常不同的项目和领域。 Groovy的多功能性，表达性和强大的功能使其成为用于其他库和框架的不错的语言，从而以不同的方式使用该语言，从而在Groovy周围催生了完整的项目生态系统。 反过来，这个生态系统为该语言带来了许多新用户！ Grails就是一个非常突出的例子，它使人们对语言有了很大的了解。 今天的Gradle也是一个使用Groovy的构建自动化项目，许多企业项目以及诸如Spring或Hibernate之类的大型开源项目都使用了Gradle。
项目生态系统是Groovy取得巨大成功的关键资产。
JAX：问这个问题可能还为时过早，但是，对于Groovy路线图，他们未来有什么计划？ 暂时只是将注意力集中在使Groovy 2.0尽可能地出色上吗？
Laforge ：我们仍然有很多工作来完成Groovy 2.0的定稿，因此我们将大部分时间都花在为我们的大用户社区实现这个重要的里程碑上。
也就是说，我们当然也有更高版本的计划！ 特别是，我们希望完全重塑Groovy（元对象协议）的动态心脏，使其更加同质和强大，对动态功能进行更细粒度的控制，并更加安全地控制元编程更改的范围等
我们还想重写解析器以使用更新版本的Antlr，从而在IDE中提供更好的工具来发展Groovy的语法。
关于模块化的工作也将继续进行，并将使我们能够更轻松地发展现有的API。
和往常一样，我们将继续认真听取用户群的需求，以实现他们对改进和新功能的愿望。
——-
本文最初发表在Java Tech Journal：Groovy Universe中。 在此处进一步查看以Groovy为中心的文章。
翻译自: https://jaxenter.com/groovy-2-0-is-finally-here-interview-with-guillaume-laforge-project-lead-104695.html
groovy 2.5.4