实战 Groovy: Groovy 的腾飞

核心提示： Groovy 依然是 Groovy！在深入研究变化的内容之前，我要花几秒钟谈谈什么没有改变，实战 Groovy: Groovy 的腾飞(2)，首先，动态类型化的基本性质没有改变，则会造成解析器错误，幸运的是，变量的显式类型化（即将变量声明为 String 或 Collection） 依然是可选的

Groovy 依然是 Groovy！

在深入研究变化的内容之前，我要花几秒钟谈谈什么没有改变。首先，动态类型化的基本性质没有改变。变量的显式类型化（即将变量声明为 String 或 Collection） 依然是可选的。稍后，我会讨论对这一规则的一点新增内容。

知道分号依然是可选的时候，许多人都会感到轻松。对于放松对这个语法的使用，存在许多争论，但是最终少数派赢得了胜利。底线是：如果愿意，也可以使用分号。

集合（Collection）的使用大部分还保持不变。仍然可以用 array 语法和 map，像以前那样（即最初从文章“alt.lang.jre: 感受 Groovy”中学到的方式）声明类似 list 的集合。但范围上略有变化，我将在后面部分展示这一点。

最后，Groovy 对标准 JDK 类的增加没有发生多少变化。语法糖衣和漂亮的 API 也没变， 就像普通的 Java File 类型的情况一样，我稍后将展示这一点。

容易变的变量

Groovy 的变量规则对新的符合 JSR 的语法的打击可能最大。经典的 Groovy 在变量声明上相当灵活（而且实际上很简洁）。而使用新的 JSR Groovy 时，所有的变量前都必须加上 def 关键字或者 private、protected 或 public 这样的修饰符。当然，也可以声明变量类型。另外，如果正在定义类，希望声明属性（使用 JavaBeans 样式的 getter 和 setter 公开），那么也可以用 @Property 关键字声明成员变量。请注意 —— Property 中的 P 是大写的！

例如，在“alt.lang.jre: 感受 Groovy”中介绍 GroovyBeans 时，我在文章的清单 22 中定义了一个叫做 LavaLamp 的类型。这个类不再符合 JSR 规范，如果要运行它，则会造成解析器错误。幸运的是，迁移这个类不是很困难：我要做的全部工作就是给所有需要的成员变量添加 @Property 属性，如清单 1 所示：