自Groovy++问世，Groovy++就在极力避免成为Groovy分支，Groovy++到底是什么语言呢？且51CTO为您娓娓道来！

51CTO推荐专题：Groovy开发技术

静态类型Groovy到底是什么？

大家都知道，用Java编程非常繁琐、不便。Groovy则非常富于表达而且语法构造非常接近Java，因此学习曲线相当平滑。Groovy与Java之间可100%互操作，Groovy对象就是Java对象，反之亦然。

但是Groovy运行时很慢，我做过很多改善Groovy性能的工作，对这一点自然也是开诚布公。你会发现，有些计算或数据转换用Java重写会快3-5倍，有时会到8-12倍甚至更高。有些人因此认为不要用Groovy做计算和后台处理……但是，我们为什么要把自己限制于简单的Web页面开发或处理上呢？

更糟的是，Groovy对多核计算机支持不好，用Groovy编译的几个线程执行代码实际上会相互影响速度。有些人可能会认为这只是并行实现的缺陷，随时间推移会得到改进。我却不这么想，我觉得这些问题源自Groovy动态本质。如果你需要在任何地点动态改变任何调用行为的能力，那么就必须付出代价。这是自然法则。

好在我们并不总是需要动态行为。杰出的语言表达能力加上强大类型推断，可以得到神奇的静态编译代码。这就是静态类型groovy的由来，我们应该区分要求高性能的代码和那些要求完全动态特性的代码。

这是否意味着我想达到好的性能还不用像Java那样到处要标明类型？

是这样，我们在类型推断方面做得相当不错。这里一个一般原则是API的开发者应提供足够的类型信息（当然和Java比也算少的），API的使用者就不用提供太多类型信息了，编译器会推断出其余信息。

Groovy++的主要目标是，一方面富于表达，非常接近Java；另一方面，一部分代码块可以享用性能和编译时类型检查，而另一部分代码则完全动态。

Groovy++是官方项目名称吗？是开源的吗？

是的。其关系有点像C和C++。我们不是在创建一个新语言，而是对Groovy自身的扩展，以为该语言带来新价值。Groovy++是增强Groovy而非替代它的。大家都知道，在Groovy社区，我们以前从未说过Groovy替代Java语言之类的话，这并不是因为我们不需要一个更好的语言或Groovy不够好，而是因为Groovy太慢且不能提供编译时检查。有了Groovy++，一切改变了——富于表达、快速、动静兼修、完全与Java可交互……这些不都是下一代Java的主要需求么。

Groovy++是开源的，一部分已经开源，另一部分很快也就开源了。该项目分两部分：编译器和标准类库。标准类库已经开源了，编译器在未来几个月会开源。

我们之所以没有立即开源编译器，因为其中用到了不少商业产品的技术，待将这些部分抽取并替换/重写之后，就可以开源了。另外，我们与几个知名厂商就对该项目投资事宜进行了洽谈，在讨论还未完成之前就最终定案开源软件许可也没太大意义。

Groovy++是Groovy分支吗？

Groovy++不是Groovy分支，而是建立在Groovy 1.8.x之上，仅仅在其发行包中增加了一个jar文件而已。从***天起我们就尽量避免其成为Groovy的分支，即使现有Groovy编译框架对我们的静态编译器来说并不是***的。幸运的是我们找到了所有正确的解决方法，甚至还回过头对这些方法的bug进行了修正，这些方法在Groovy中并未广泛使用。

Groovy++如何工作？

非常简单，只需在代码块上加@Typed注解即可。Groovy中的AST转换帮了大忙，我们可以把静态和动态类型代码任意组合。对静态编译部分，编译器进行类型推断及所有必要检查，并产生运行效率高的字节码。对动态代码则使用普通Groovy编译器，因此Groovy++并不会破坏你的Groovy代码。

我个人比较喜欢所谓的混合编译模式，这种模式下静态编译器尽其所能解析方法和属性，但如果解析失败则产生动态调用。这种方式将Groovy的动态特性与快速运算***程度的结合在一起。

为什么需要标准类库？

我们的标准类库是对Groovy的一个扩展。至于为什么需要标准类库，有两个原因：***，Groovy以动态分派方式实现其服务，而在Groovy++中则不然，Groovy++标准类库出现并不是说Groovy标准类库性能不佳，而是因为其缺乏类型信息，在静态语言中使用不太合适；第二，由于Groovy++性能更优，提供附加的工具类也是有意义的，比如在多核机器上调度多任务或对集合提供函数型操作。

还有一点比较自豪，那就是这个Groovy++标准类库全是用Groovy++编写的，没有一句是用Java写的。

Groovy++当下还有什么缺点？

我只发现一个小小的不便——简单的从动态代码copy/paste到静态代码不一定行了。（因为可能需要额外的类型信息）。

和Scala/Clojure比，Groovy++如何？

Groovy++从它们吸取了很多有益思想（比如actor、trait），但是Groovy++更贴近900万Java开发者。对他们来说学习曲线更平滑。

说说项目路线图？

下两到三个星期，我们想发布0.2版，其将包含全部功能的静态编译器，然后一两个月全心解决bug、编写例程、文档和手册。为四五月份出0.5做准备。同时我们还将改进标准类库，以更好支持多线程及分布式编程。

在这一领域我们有很多想法——分布式actor以及数据缓存，软件事务内存、erlang式的supervisor tree。现在还不好说其中哪些将进入标准类库，哪些可能创建单独项目，以及哪些病入其他项目如GPars。可以肯定的是，集表达力、性能和编译时检查于一身的Groovy++能够成为解决复杂问题的候选语言，并使这些问题对普通开发者来说解决起来更加简单。

IDE支持方面有什么计划？

凡对Groovy支持不错的IDE均可使用，不需要什么特定的IDE支持。

末了还有什么想法？

我有个梦想，有一天所有Java开发者都会将Groovy++作为其下一个项目的候选语言。同时，我希望每个人都试试Groovy++，让我们也了解一下你们的感想。本项目的源代码部分在Google Code上，还在初期因此也没什么文档，不过也快了。

【编辑推荐】

1. Groovy 1.7.3发布 值得关注的新功能
2. 基于Groovy 加速Google App Engine开发
3. JVM流行动态语言Groovy 1.7发布
4. 比较与分析Groovy与Java
5. Jython和JRuby，以及Groovy：Java平台的统一认识模型