自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上，还在初期因此也没什么文档，不过也快了。
【编辑推荐】
