Grails 1.0 已经发布了。这个消息在项目邮件列表、 Graeme Rocher 的博客和 Grails.org 都进行了声明。InfoQ 对 Grails 项目领导人、 G2One 的 CTO 兼共同创始人 Graeme Rocher 进行了采访，针对 Grails 1.0 发布中包含的种种特性，此版本的成熟度、易用性及 Grails 的未来计划进行了深入交流。
Grails 1.0 的发布说明页面上列出了所有新特性的细节，其中包括：
- ORM DSL ，在与历史遗留的数据表打交道时，可以避免依赖 Hibernate 映射。
- 易于使用的 Filters ，它可以被应用于特定的 actions、一个完整的控制器或是贯穿基于 URI 的多个控制器。
- 支持构建 REST 服务。
- 内容协商支持，用它可以便于在 HTML、XML、JSON 和其他内容表示形式之间切换。
- 自动化 XML/JSON Unmarshalling，用于支持通过 XML 或是 JSON 来提交数据。这项功能对于 Web Services 或是 RESTful 方式很重要。
- 范围内服务，允许在服务中存储状态时使用多种语言模型。
Grails 还利用了 Groovy 1.5 中的一些特性，如注解：
在 1.0 中，你可以使用与 GORM 对立的 JPA 风格的注解（目前只支持用 Hibernate 作映射），如果你喜欢的话。你还可以使用所有 Spring 的注解，如 tx:annotation-driven 。
虽然对于一个已经有过很多次发布的软件项目而言，1.0 版不过是又一次发布而已，但它依然可以给项目团队以强大的精神鼓舞和自信心的强化。如 Marc Palmer 所说：
很多人都能理解，1.0 版对于心理作用来讲是非常重要的。它为将来的发展设定了基线，夯实了基础。Grails 1.0 有着令人难以置信的庞大的核心功能集，而且它的免费插件数量也在与日俱增，这些插件为 Grails 添加了各种各样的强大功能。
当问到 Grails 的成熟度是否处于“就绪情况”时，Graeme Rocher 回答说：
我可以很自信地说，它已经足够 [成熟 / 就绪] 了！不过严格说来，从来没有任何一款软件能够做到在发布以后不出现 bug，如果一个软件厂商说他们的软件没有 bug，那他肯定是在撒谎。我能说的就是，如果我们过去所做的事情是在将 Grails 向正确的方向推进的话，那它在这条路上已经走了将近三年之久。我们很有信心，如果人们试着用了 Grails，那他们就会喜欢上它。
Graeme 列举了一些 Grails 的成功案例，他从网站上列举的那些开始讲起，后来又补充说：
Grails 的主要应用已经渗透到了企业内部，要把它们挑出来或是直接进行讨论还多少有点困难。比如 Grails 已经在法国一些主要的广播公司中得到了应用，还有一家大型 US 托管提供商和伦敦排名首位的几家 HR 公司。另外，SAP 也有了 Composition on Grails 项目，它可以用来在 SAM NetWeaver 7.1 上面快速构建组合应用。
Grails 的基础是一个成熟的栈，从 Groovy 语言（前不久，它已经为向企业应用进军最好了准备）到Spring 和Hibernate。Graema 补充说：“你会把Spring 和Hibernate 看作风险吗？”
Graeme 谈到了为什么 Grails 会被当作企业应用中的优秀选择：
对于那些现有架构常常是基于 Spring 和 Hibernate 构建的大型企业来说，掌握 Grails 特别简单。 往底层来说还有很多理由，譬如说，要重用现有的 Spring bean 定义再简单不过了，你把必要的 XML 文件扔进去就行了（在 Grails 里，这可能是你唯一需要看一眼 XML 的地方！）。
你还可以重用 Hibernate 的领域模型，同时还能享受 Grails 的所有好处，这个就不值一提了。
他接下来谈到了开发团队可以很轻松地使用 Grails 加速开发的步伐：
因为 Groovy 的设计思想是，从底部起力求做到在语法层面上尽可能地与 Java 平滑集成，所以一个由 Java 开发人员组成的团队肯定很容易把速度赶上来。 Grails 本身也是对 Java EE 大幅度的简化，因为说句实话，大多数现有的 Java 框架都比他们本来应有的样子复杂得多。这种巨大的复杂度差异也使得软件工程师们很难从其他平台转换到 Java 平台上来工作。
从这一点来看，Grails 也为其他社区的开发人员——如 PHP ——打开了一扇通往 Java 世界的大门。
不过，能够轻松自如地采用一整套的 Java 栈也会偶尔带来些代价：
在种种危险中，最主要的一点是我们已经对底层框架的抽象太成功了，以至于有时会出现问题。 例如，如果你不理解 Hibernate 中延迟加载和主动抓取之间的区别，那你肯定就会遇到麻烦。不过这些危险和其他任何 Java 项目并无不同，只是新手很容易会不时落入这些困境中。
有些人认为用动态语言做原始的开发很容易，但是维护成本特别高，因为没有比较有效的工具支持。Graeme 反驳说：
我相信 Groovy 是很不一样的。首先，Groovy 不是动态型别，而是任意型别。这就说明你可以指定它的型别，也可以不指定。在大多数情况下它的型别都是可以被推断出来的。譬如说，用了 IntelliJ 的 JetGroovy 插件，或是其他类似的工具，你就可以像 Java 语言一样获得对 Groovy 完整的重构和代码分析支持。 而且，Groovy 还是一个拥有联合编译器（joint compiler）的真正的混合源码（mixed source）语言，从 Java 转换到 Groovy 和转回来都一样容易。我觉得，其他动态语言的使用者会失去 Java 的代码分析和重构的能力，但 Groovy 绝不在其中，所以它的维护不像其他动态语言一样，和 Java 有那么大差别。
我希望以后 Eclipse 和 Netbeans 对 Groovy 的支持可以达到 IntelliJ 的水准，让更多的开发人员都可以接触到这种开发类型。
在展望 Grails 的未来时，Graeme 谈到了 1.0 以后其他版本的发布计划。他从 Groovy 1.6 和性能说起：
1.0 为向后的兼容性设定了一个基准。从现在开始，不管添加什么新特性进来，我们都要把现有的应用等相关情况牢牢放在心上。 肯定会有几个 1.0.x 版本，不过对于 1.1 而言，还有很多事情需要重点解决。首先，Groovy 和 Grails 的路线图关联的十分紧密，所以 Groovy 1.6 中将要添加进来的一个重要内容也会被加入 Grails 1.1 中，那就是通过调用点缓存技术（call site caching techniques）带来的性能方面的巨大提升。
我们的目标是让 Groovy 可以和 JVM 上其他一些最快的动态语言建立内联，这样做对 Grails 只会有好处。由于它是建立在坚实的基础之上，已经受益良多了。对于 Grails 自身而言，日程表上最重要的事情就是和 Java EE 技术及项目进行进一步的集成。
Marc Palmer 也提到了一种使用真实项目的新型集成测试将会被应用于 Grails 1.0 和之后的版本中：
我们也已经把一个用于自动运行功能性 Web 测试的框架放到了 SVN 的“specimen”应用中，它将会成为 Grails 持续集成构建的一部分。在服务器环境方面会有一些暂时性的困难，但是整个过程都是在本地执行的，我们只需要向 SVN 中放入一些优秀的测试应用，更重要的是，在应用中加入一些全面的 Web 测试脚本。 这将会很成功地构建出 Grails 的一个“TCK”，根据 1.0 版的基线功能保证其稳定性——另外，Grails 一直向产品内部不断地加入单元测试代码，目前的单元测试数量已经十分庞大了，这也是持续集成构建平台的一部分（Bamboo 也实在是太棒了）。我们也非常欢迎人们贡献非试用性的应用程序和全面的单元测试、Web 测试。
Grails 会继续集成 Java 领域内的最新技术，为做到一栈式的集成，成为 Java 世界中顶尖的框架之一而努力：
在 1.x 版本中，我们计划加入对 JPA、JSP 标签库和 Portlet 的支持，通过插件提供与其他一些流行框架的集成，像 JSF、GWT、Wicket 和 Struts 等。另外，我们计划通过一个 Maven 2 插件把 Grails 放入 Maven 的生命周期中，从而随着 Grails 提供对 Maven 2 的开箱即用（out of the box）的集成。记住，Grails 不仅仅是一个框架，还是一个软件栈，它的目标是解决软件生命周期内的所有问题，从构建系统到 ORM 层。
虽然 Graeme 也承认任何插件系统都有可能出现问题——一个插件无法和另一个插件协同工作，不过他还是聊起了一些较为流行的插件：
有些插件已经流传甚广，也拥有着优秀的成长中的社区，例如 JSecurity，Searchable（Compass 集成），XFire 和 RichUI（Yahoo UI 集成）已经有了不错的口碑，发展势头也很迅速。 其他插件的发展速度比较慢，不过“已经死去”的插件却寥寥无几，这是个好信号。
他最后提到的就是在 2007 年 10 月人们所见证的 G2One 的成立，它为 Groovy 和 Grails 提供了培训服务和咨询：
从 10 月份成立以来，我们的效益一直特别好，目前我们的规模已经翻了一倍。这对于 Groovy 也是一个重大利好，可以看到它解决的问题数量有了一个飞升。我们现在有很多全职或是兼职员工工作在每一个项目上，这把我们与那些打算采用 Groovy 但是还在寻求支持的人截然分开了。
社区中的反应纷纷从 Jaiku 和博客中传来，虽然大多数都是描述了这一发布的简单事实，但有些也在跟人们共享从前使用 Grails 的经验：
-
Michael Kimsal 早已期盼着这次发布的到来：
多少年我都没有像这样因为一次技术发布而如此兴奋了……从我去年春天开始使用 0.5 版到现在，Grails 已经走过了很长的路。Graeme 和他的那群人，嗯，就像一群训练有素的执法队员，在过去几个月内，为了 1.0 的发布干掉了狂多的 bug，修复了几百个问题。
-
同时，Ray Kreuger建议 Java 开发人员应该近距离看一看 Grails 了：
如果你是一个 Java 开发者，却对 Grails 或者 Groovy 不熟悉，你绝对应该把 Grails 的代码 check out 出来。Grails 是一个基于“惯例重于配置”思想的快速 Web 应用开发框架。它的设计思想跟 RoR十分相似，但它用的是 Groovy 语言。这种做法的最大好处是，Groovy 是基于 Java 的，所以给人的感觉与 Java 很像，于是开发团队的学习成本就会很低。另外一点则是，它把应用构建为 WAR 文件，所以你可以把构建结果部署到任何一个旧的应用服务器上。不需要做什么黑客性质的工作。这对于在“企业性质”很重的环境下部署是很重要的。
-
Bill Gloff 的看法是，你不要管我说了什么，只管自己去试试看：
Groovy 和它的伙伴——Web 框架 Grails——在这些天里已经给人们带来了很多令人兴奋的消息，我知道为什么用它是一种快乐的体验，它会帮你成为一名效率更高的程序员。Grails 从 RoR 那里借鉴了很多，但同时你还可以利用你掌握的 Java 与 Java EE 的知识。
-
GroovyZone 也主张使用 Grails：
对我来说，Grails 是 Java 上最快的原型开发平台。我仅仅是把那些现成的 Hibernate 配置好了的字节码文件丢进去，生成脚手架（scaffolding）视图，就已经完成了大量应用。它可以让你快速上手，把精力集中在正在构建的应用程序上。
-
最后，这场最近发生的对 Rails 和 Grails 进行对比的争论也许可以帮助你理解二者之间的差异：
- Darryl West 列举了从 Rails 转移到 Grails 上的 10 条理由。
- Graeme Rocher 附和说， Grails 可以让 Java 开发者忘掉 Rails。
- 因在 Rails 方面的工作而出名的 Relevance，把 Graeme 的观点归结成三部分，“转移的理由”，“边缘案例”和“屁话”。
- Jens Krämer 认为 Graeme 只是在祈求人们对 Grails 投入关注。
随着时间的推移，InfoQ 会继续跟进对 Groovy 和 Grails 的报道。
查看英文原文： Grails 1.0 Released: ORM DSL, Filters, REST and more
评论