Groovy++Groovy 增强版

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支持。