Laforge、Rocher谈：Groovy、Grails和Java的未来

个人简介 Graeme Rocher是SpringSource Grails开发部门的负责人、Grails web应用框架的项目负责人和创始人之一，他还是Groovy语言标准化规范（JSR-241）专家组的成员。Guillaume Laforge 是SpringSource Groovy开发部门的负责人、官方Groovy产品经理、JSR-241规范的负责人。

   

1. Guillaume，你能给我们讲点Groovy 1.8及其新特性吗？

Guillaume Laforge: 我们最开始准备在10年底到11年初发布Groovy1.8 ，最终于2011年4月27日正式发布。目前，我最喜欢的特性是DSL书写方面的新功能。在你编写一个DSL时，一定希望写出可读性较强的代码，最好能像普通英语句子一样。用了我们的“扩展命令表达式（extended command expressions）”，你就真的可以用自己的DSL写出普通英语语句，就你能写出的DSL API而言，这将极具有潜力，我非常喜欢这个特性。

除了这个，我们还为闭包增加了新的函数风格，比如，闭包组合、把闭包作为注解的参数。还有一个叫做GContracts的项目给Groovy增加了“按契约设计”，尽管Groovy不是为此目的而设计的，但是这种语法和新的特性还是能做一些让人意想不到的事情。这些只是其中的一些新特性，还有诸如性能的提升、Groovy开发工具的小改进等等。

   

2. Grails 1.4有些什么新特性？

Graeme Rocher: 这要从几个方面来说。首先是改进GORM，我们要增加对数据库逆向工程、迁移的支持，对以前没有支持的抽象继承树和接口提供支持。除此之外，我们还要继续提升框架的生产效率，从已有的基于类加载的重装系统转向JVM基于agent的重载，这样就允许更多种类型的改变可以在不重新启动容器的情况下生效。我们为静态资源引入了新的资源抽象，以便更容易声明所依赖的JavaScript框架。另外，Gzipped、缓存优化（cache optimized）及e-tagged也作为框架的一部分被收纳进来。这些好东西都是插件开发者可以加以利用的特性。新版本里有不少好内容。

   

3. Groovy和Grails的开发过程看起来是你中有我，我中有你。下一版Grails会利用到新版Groovy的哪些新特性呢？

Graeme Rocher: 我们对“命令表达式”及如何利用其改善Grails DSL表达约束和URL映射颇有兴趣，它给Grails带来了很多可能性，我们为此感到非常兴奋。我们会继续给Groovy团队提供反馈，表明进一步的需求，两个项目之间的关系非常密切。

   

4. 就Groovy语言而言，如何选定不同版本应包含的特性？除了满足Grails的需求之外，有无其他考虑？

Guillaume Laforge: 每个版本的不同特性都是在长时间期许之后才加进去的，也就是说，“大多特性都是随时间推移逐步加入这门语言的”。有时，摆上日程的一些特性其实是借鉴了其他工具。比如，在Groovy 1.7中加入了Power Assertion，可用来显示断言是如何求值的，或者显示每个子表达式的值。该特性原本是Spock测试框架的一部分，当时我们想“哇，这个特性太棒了！我们应该把它包含到Groovy中来。”

借鉴是一方面，另一方面是Groovy使用者们对Groovy的贡献。这有一个Groovy早期版本的例子，比如ExpandoMetaClass的概念，它是Graeme在开发Grails内部功能时的产物，我们将其迁移回来并入了Groovy。还有些是来自其他项目的东西，一些由来已久的概念，我们也会考虑借鉴。这些都是可能的。

当然，我们的用户也是将某些特性融进Groovy的催化剂，所有这些因素都可能导致某版本新特性的诞生。

   

5. 对Grails而言， 在选择Grails1.4或更高版本未来特性和安排特性开发时有哪些考虑？

Graeme Rocher: 这其实是由社区驱动的，有很多人在使用Grails；我们社区有个Buzz可以给我们发送邮件。每天我们会从社区中收取超过100封邮件。这是Grails团队与社区持续反馈的循环过程，从中会产生出大量的需求，比如框架静态资源管理的需求就是这样诞生的，我们准备在1.4中加入静态资源处理特性。在此之前，还有要求Grails内含标准化安全框架这样的需求，为此我们开发了Spring Security和Spring Security 插件。

有很多创新来自插件生态系统，当新的最佳实践从中浮现，我们便会将最流行的最佳实践纳入到核心框架中并使其成为标准。这并不是说只是由框架开发者引入我们认为人们应该喜欢的东西，而是由人们在社区中先做实验，其中一些东西很可能是一个伟大概念的开端，在它们形成插件以后，我们会考虑将该插件变为更加稳定的形式融入框架。

Guillaume Laforge: 有些是我们生态系统中趋势性的东西，比如云计算及NoSQL运动也激发了我们项目中的一些创新。

Graeme Rocher: NoSQL是个不错的例子

   

6. 说到云，SpringSource 最近发布了Code2Cloud。Groovy和Grails如何应用于这一平台？

Graeme Rocher: Code2Cloud也支持Groovy和Grails应用，整个Code2Cloud集成是通过我们的STS工具套件完成的，其支持Groovy和Grails应用的构建。从IDE到部署至Cloud，所有hook（钩子）都支持Grails应用，我们对此非常振奋。所有即将面世的SpringSource及VMware的云基础设施都将支持Grails；VMforce将能够在VMforce基础设施上运行你的Grails应用。每个云都已经或将要对Spirng和Grails应用提供良好支持。

   

7. Spring Roo 许多灵感来自Grails框架及其行事方式。Roo和Grails团队是怎样合作的，在没有类似Groovy语言而必须使用Java的情况下，Roo团队要构建类似于Grails的特性时会面临哪些挑战?

Graeme Rocher: 正是由于Grails和Roo团队与Spring核心团队通力合作，才定义出了两个项目都需要的Spring核心功能。我们还一起开发过一些新特性。其实，两个项目是相互借鉴的关系，比如，Grails将会包含类似Spring Roo shell这样的东西，我们两个项目将会继续合作下去。至于说Roo团队所面临的挑战，这个问题最好留给Roo团队来回答，不过给静态类型语言增加一些个动态特性确实是不小的挑战。

有些特性,比如DSLs，在Spring Roo里是不可能实现的，不过幸运的是，SpirngSource背后还有AspectJ，Roo团队正在用AspectJ做一些神奇的东西，以便让Java开发者活得更轻松些。但是我们必须记住这两者是大大不同的工具。Grails拥有运行时组件，而Roo是开发时工具，因此Roo应用及Roo shell虽能产生所有的代码，但是在运行时，你的应用是静态的Spring应用；而Grails所拥有运行时环境及插件模型在构建时及运行时都存在。

   

8. 能解释下Grails1.4中GORM的变化吗？包括GemFire 和 Redis?

Graeme Rocher: 好的。Grails社区对NoSQL数据存储的兴趣很大。我们正在与Spring Data项目的几个提供商通力合作，使Spring和Grails应用可以方便地访问这些存储。我也参与了这个项目，正在为建立于SpringTemplate API之上的高层映射架构构建GORM接口，以便与这些数据存储进行交互。关键是既能用一个好的高层API来访问这些存储，但又不损失与它们直接交互以利用其优良特性的能力。

例如，如果你做一个Mongo映射框架，你一定想要用类似于GORM的高层DSL来处理常见的用户场景，不过你还想要能下探一层以调用你自己的MapReduce函数。我们必须仔细检察整个发现的过程，以便为每个存储都找到最佳的方式，我们尝试的第一个存储是Redis，效果不错。GORM for Redis是在去年11月份发布的，其在Redis哈希内部使用了GORM实体模型，查询是通过在Redis中设置算法来完成的，它会为你构建索引。

如果想下探到更低一层Redis， 并且对底层Redis数据存储的有全部访问权限，你可以构建自己的索引，做自己的算法。但是如果你只想在高层做一些基本查询功能，GORM for Redis都为你处理好了。它看上去和GORM for Hibernate是一样的：一样的GORP API，一样的直接查找器条件、命名查询特性等等。在此次大会上我们还宣布了另一个实现—GORM for GemFile。NoSQL数据存储通常用于伸缩性问题的解决方案。

早在NoSQL这个术语出现之前，GemFire已经被用于解决伸缩性问题多年了。其本质是一个有事务性关系数据库在背后支持的的分布式分区键值存储。它支持分区、持续查询（continuous querying）、网格计算、MepReduce—一大堆人们无需了解的特性。它的确很强大，也有完整的队列API。我们在GORM中利用了这些特性，所以你可以把你的GORM实体置于GemFire数据存储之中，并执行目录查询（Direct Finders）,条件查询（Criteria Queries）。

我们还支持GemFire里面的一个超棒特性，叫做持续查询（Continuous Queries），你可以注册一个持续查询，得到返回的事件，在数据更新到你的数据存储时响应那些事件。这个特性非常棒。我们已经完成了1/3的工作量，它操作最终的数据存储，并且是一个并发的hash map。没错，它是个原始的key value 数据存储。不过用它来测试再好不过了，这样你就可以针对Redis或GemFire编写相同的逻辑，但是当你在测试中运行它的时候，则可以使用并发hash map。将来我们会把重点放在Mongo、Cassandra上。

   

9. 这项工作与SpringData项目有什么关联? 似乎SpringData在为Spring Framework做类似的工作

Graeme Rocher: 这两个项目是关联的，我们是在Spring Data项目之上构建的，就如同Grails是构建于Spring之上一样，我们是在Spring Data上构建GORM for Redis和GremFire等等的。它们是相互依存的。

   

10. 自Java 6发布以来已经很长时间了，Java7开发过程比预期得要长得多。给人的印象是Java语言正处于停滞状态。这对其他JVM语言，如Groovy，会有什么影响？

Guillaume Laforge: 像Groovy这样的开源项目的好处是我们可以以自身步调发展。从2003年第一天起，我们就已经有了闭包（closures），属性（properties），以及许多JDK7或JDK8中已经列入计划或还未列入计划的特性。那都是些已经在Groovy中就有的特性，就算不是一开始就有，也已经有很长时间了。显然，你有机会进行更多创新而不是因循守旧。我们总是能从新版Java的新特性中获益，比如在Java 5问世的时候，我们加入了类似注解、泛型和静态引入之类的东西。

我们将继续沿此道路走下去，不仅要支持新API、新构想，而且要改善对它们的使用等等。如果Lambdas、闭包或其它什么玩意出现了，我们一定会用Groovy闭包与之交互。我们仍将站在Java EE巨人的肩膀上，持续围绕语言特性及API进行不断创新。

   

11. 我们刚刚谈论的可能对JVM语言非常有帮助的特性之一是InvokeDynamic（动态调用）。InvokeDynamic对Groovy来说意味着什么？

Guillaume Laforge: InvokeDynamic非常有趣，因为首先它允许我们移除代码库中一些模拟InvokeDynamic的代码。因此就代码库而言，这一特性让我们的代码更加精炼了。而且该特性还加速了一些动态方法调用—这是另一个好处，我们利用它获得了更快速的方法调用。对动态语言来说，InvokeDynamic显然很有帮助，其新字节码指令及所有新的API都将成为新包Java.lang.dyn的一部分。

我们仍在等待这些特性变得更加稳定，它们在过去几个月变化非常大。不过它们正在稳定下来，好消息是我们已经准备就绪，迎接JDK 7的到来【已经发布】。我们翘首期待。

   

12. Grails插件生态系统对Grails的推广和成功有何帮助？

Graeme Rocher: 插件生态系统实际上是Grails成功的关键。从一开始，我们就把实际的结构放在插件API上，并在各Grails版本间维护其兼容性，这让我们的插件生态系统得以蓬勃发展，也让我们的社区更容易做出贡献并让平台得以进化，即使在没有主版本出现的情况下也是如此：即便你正在用Grails1.3.5，1.4还未发布，插件社区仍在不断创新，虽然另一个主版本并未发布，Grails平台也在不断增强。

这是它带来的实际益处。例如，在过去若干月里，我们发布了GORM for Redis、GORM for GemFire—所有这些插件都可工作于Grails 1.3.5。我们准备发布一个Flex插件用以集成Grails和Flex应用，这样你就可以开发“Grails后台+ Flex前台”的应用程序了。我们发布了一套Spring Security插件，包括核心Spring Security插件及针对OAuth、OpenID和Facebook集成的可插拔扩展模块，所有这些都不需配置。

还有一个非常好的Spring Security UI 插件，你只需安装这一插件即可获得完整的UI来管理你的用户、角色及授权等等。因此我们在不断进化并增强平台，即使没有新的主版本发布，其好处是社区每天都可以看到功能增强。目前我们有499个插件，马上就要突破500，这些插件里既包括像Weceem插件（如果你需要CMS系统只需安装Weceem即可）那样完整的CMS系统插件，也包括很小但非常有价值的插件。

你所提到的Google分析（Google Analytics）插件就是一个很小的插件，但它使用起来非常容易，你只需运行“Install plug-in Google Analytics”，在页面上增加一个标签，它就可以工作了，比起你查阅各种Google API文档自己写要简单多了。Grails有大量这样的插件，而社区还在不断的进行创新，这是一个令人激动的领域。

   

13. 在Groovy上构建Grails，是怎样使得开发者在使用Grails时效率更高的？

Graeme Rocher: 大部分的生产效率得益于语言层面。Groovy是非常高效的语言。与Java相比能减少40-50%代码，较少的代码即意味着较少的代码维护量。实际上我们可以拿着你的应用对你说“这部分是我的代码。那部分是你的应用程序代码；现在，你不用做任何事情，让我们用各种新特性来增强你的代码吧。”

通过使用元数据编程和混入就能取得巨大成效，更不要说DSL、URL映射DSL、约束DSL了。有许多DSL可出力的特性领域，如校验等。没有Groovy就没有Grails。

   

14. 非常感谢二位。

Graeme Rocher: 很荣幸。

Guillaume Laforge: 谢谢。