Groovy—沉睡的雄狮
最近公司要开发新的项目，要用到Groovy。
自己又不懂Groovy，于是差了些资料：
贴图：
什么是 Groovy？
Groovy 是 JVM 的一个替代语言 — 替代 是指可以用 Groovy 在 Java 平台上进行 Java 编程，使用方式基本与使用 Java 代码的方式相同。
● 是一个基于 Java虚拟机的敏捷 动态语言。
● 构建在强大的Java语言之上 并 添加了从Python，Ruby和Smalltalk等语言中学到的 诸多特征。
● 为Java开发者提供了 现代最流行的编程语言特性，而且学习成本很低（几乎为零）。
● 支持DSL（Domain Specific Languages领域定义语言）和其它简洁的语法，让你的代码变得易于阅读和维护。
● Goovy拥有处理原生类型，面向对象以及一个Ant DSL，使得创建Shell Scripts变的非常简单。
● 在开发Web，GUI，数据库或控制台程序时 通过 减少框架性代码 大大提高了开发者的效率。
● 支持单元测试和模拟（对象），可以 简化测试。
● 无缝集成 所有已经存在的 Java对象和类库。
● 直接编译成Java字节码，这样可以在任何使用Java的地方 使用Groovy。
像Ruby, Python 甚至Java/ECMAScript这样的动态编程语言正在受到创新开发者们的亲睐，这种趋势已变得很明显。Ruby on Rails为提高Ruby编程语言做出了很大贡献， Ajax 正将更多的兴趣集中在JavaScript 上。Python 尽管还没有找到它的发展方向, 但它现在也在受到更多的关注。动态编程语言的时代即将到来。我的意思是：当动态编程语言成为一种“标准”而不是“异类”（“例外”）的时代即将到来。
在今后的五年当中绝大多数机构将在一些企业开发中运用动态语言程序。当然不是说在所有的开发中都会用到。因为对于传统编程语言的需求总是存在的，传统编程语言可以让你在编译时就发现（程序）错误而不是在运行时才发现。但是，动态语言摆脱被称为“危险物”或“玩具”的日子指日可待。
当创新开发者蜂拥向像Ruby这样的动态语言程序时，主流的开发群体却不太倾向于采用这种语言程序。这是因为两个原因：FUD和生产率。恐惧（Fear）、不确定（Uncertainty）、及怀疑（Doubt），即FUD, 不断得阻碍着开发者试图体验和使用动态语言程序的行动。听到人们说动态语言程序是“玩具”并且有“危险”的话也是稀松平常的事。但我所发现的是，说这些话的人通常都很少有或根本没有使用过动态程序语言的经历。“FUD”的出现通常只是因为“无知”。然而，对于动态程序语言为什么没有被大众采用还有一个更实际的原因就是：生产率。学习一个新的编程语言平台可不是一件轻松的事。虽然学习一种语言的语法不是很难，但学习一整个新的程序库却是一项巨大的工程。例如，Java 程序师花在学习如何使用标准、enterprise 、专利权及打开APIs （应用编程接口）的时间要比花在学习语法上的时间比例大很多。事实上， 依我看这种时间的比例在第一年可能是20：1，而在往后会是100：1。
如果你花费了所有脑力去学习如何合理的使用Java 程序包以及APIs（而不是学习语法），那么丢掉以前所学的一切而去学习一个全新平台的想法可能……似乎……有点愚蠢。或者更准确一点说，在这个全新平台的优势不是很明显的时候，这种选择是不实际的。从本质上来讲，这种选择会使一个java 开发者所了解的有关访问数据库、控制信息串、输入及输出等一切知识变得毫无用处。另外，新平台的生态系统也没有Java的坚固。
对于主流Java 开发者来说，把平台改为Ruby 那样的看起来似乎不是很理想。不要误解我的意思，我不是说Ruby不好，我也是Ruby 的一个忠实“粉丝”， 但是将Java 平台与 Ruby 平台做个很真实的对比，就会看到Ruby确实有所欠缺。Ruby 生态系统的规模以及APIs（库）的数量与Java 平台相比较显然逊色不少。全世界大概有400万或更多的Java开发者，而如果Ruby开发者的数量能超过10万我都会感到很惊讶。大概仅有5万人每天在“生产代码”中用到Ruby程序。当然这仅仅是一种推测，ruby开发者的真实数量也许会与推测的有所出入，但是很少有人会说ruby 开发团体的规模能与Java开发团体的规模相比。
动态程序语言（如Ruby，Python, JavaScript）总体来说要比传统的编程语言多产（效率高）。在我为期三年的研究中，我总是发现开发者在同一环境中使用动态语言要比使用传统语言多产近5倍。这也就是说一旦你能熟练操作一种动态语言，那你在产量和维护方面会有巨大收益。只要是清洁代码那么代码越少越容易维护。少量的清晰的代码更容易维护。
因此这就创造了类似于“第22条军规”一样的东西（So this creates a Catch-22 of sorts）:虽然动态编程语言相比而言更多产（更高效），但是学习一种新的平台要花费开发者很多时间，事实上就短期内而言转而学习Python或是Ruby是很不划算的。（学习它们花费的时间要比要比因为它们高效而节约的时间多很多）。另外，真的没有一种动态语言有与java一样的生态系统及基础结构——因此要采用动态语言程序就要接受资源、工具及技术人员数量较少的状况。
因此，解决这个问题的方案似乎是找到一种以Java 开发团体已熟知的平台为基础的动态语言。虽然很多动态语言是为java平台而创造其中包括：Jython, JRuby, BeanShell, Pnut, 还有其它一些动态语言，但我坚信groovy是其中最有潜力的动态编程语言。我这么说最主要的原因是groovy在java团体中正在被标准化。虽然“标准化”从来都不是衡量质量的量度器，但无奈的事实是技术不是仅靠着自身的优点而取胜的（也就说还要符合一定标准）。不难理解企业都会认为采用一种通过了标准化过程（类似于J2SE 和 J2EE标准化的过程）的语言要比采用没有标准化的语言舒心的多。不管是对是错， 权威们决定将标准化作为接受和使用一种技术的前提。
除了正在被标准化，Groovy 还有一个作为动态语言的优点，即从它被创造之初就考虑到了java开发者们。它保留了很多为Java开发者所熟知的语法和语义，同时又具备了动态语言的特征如动态键入、mixins 以及闭包。正是这些特征使得动态语言比传统语言更多产(更有效率)。还有最后一点就是，你现在所用的所有Java APIs 在Grooy中可以用完全相同的方式被使用。Groovy可以汇编成字节代码，因此任何你能够在java中输入和访问的字节代码同样也能在Groovy中输入和访问。
Groovy 标准化(JSR 241)是在几年前开始的，而现在正在取得成果。 对一些人来说这似乎是很长的一段时间，但有这种想法的人是不了解相关的历史，即不了解一种语言要走向成熟需要花费多长时间。例如，Ruby这个刚刚受到很多关注的编程语言已经在 open source团体中发展了13年，JavaScript 发展了14年，Python 15年。事实上，Groovy 编程语言标准的发展只用了三年时间已经算是取得了很显著的成绩。
前景看起来似乎很明朗：动态语言正逐步流行起来，它们的多产性（高效率）及广泛的适用性是不容忽视的。要知道Java 平台被400多万开发者的庞大系统以及成千的工具和APIs 支持着，如果任何一个动态编程语言要成功它就得：a) 被标准化b) 受到Java 开发者的亲睐c) 容易学习以及d) 能利用现有的Java 系统。现在只有一种动态语言程序能满足这些要求，那就是Groovy。
Groovy 周遭的大肆宣传已经平息，对于这个项目的嘈杂的评论也销声匿迹了，我认为这是再好不过的事情了，因为这样的结果是一种语言得以有时间发展成为一种真正有用的语言。在很多方面Groovy是Java平台和动态语言设计的完美结合。Groovy 一直都很安静，像一个沉睡的巨人，但是在它成为 JCP 标准后这个巨人必将苏醒过来并且成为最重要的动态编程语言。
Groovy 快捷方式
Groovy 的一个好处是，它的语法与 Java 语言的语法很相似。虽然 Groovy 的语法源于 Smalltalk 和 Ruby 这类语言的理念，但是可以将它想像成 Java 语言的一种更加简单、表达能力更强的变体。（在这点上，Ruby 与 Groovy 不同，因为它的语法与 Java 语法差异很大。）
许多 Java 开发人员非常喜欢 Groovy 代码和 Java 代码的相似性。从学习的角度看，如果知道如何编写 Java 代码，那就已经了解 Groovy 了。Groovy 和 Java 语言的主要区别是：完成同样的任务所需的 Groovy 代码比 Java 代码更少
