我在平台上长时间缺席后开始使用Java开发一个LoB应用程序（过去8年左右在Fortran，C，一个微软的C ++和后来的.Net中度过）。
Java，这种语言，与我记忆中的方式没有太大的变化。我喜欢它的优势，我可以解决它的弱点 - 平台已经发展并决定了无数不同的框架，这些框架似乎做了很多相同的事情是一个不同的故事;但这可以等待另一天 - 总而言之，我对Java感到满意。然而，在过去的几周里，我迷上了Groovy，纯粹是出于自私的观点：但不仅仅是因为它使得针对JVM的开发变得更加简洁和有趣（并且，很好，“groovy”）命题比Java（语言）。
最让我印象深刻的是Groovy的内在可维护性。我们所有人（我希望！）努力编写记录良好，易于理解的代码。但是，有时我们使用的语言会让我们失望。例如：2001年，我在C中编写了一个库，将EDIFACT EDI消息转换为ANSI X12消息。这不是一个特别复杂的过程，如果稍微涉及，我当时认为我已经正确记录了代码 - 我可能已经 - 但是大约六年后我重新访问项目（并且在适应C＃之后）我找到了我自己迷失在如此多的C样板（mallocs，指针等等）中，经过三天深思熟虑的分析，才终于明白我六年前做过的事情。
今天晚上我写了大约2000行Java（毕竟这是休息日！）。我记得最好，因为我知道如何，但是，在那些2000行Java中，很大一部分是Java锅炉板。
这是我看到Groovy和其他动态语言获胜的地方 - 可维护性和后来的理解。 Groovy让您专注于您的意图，而不会陷入特定于平台的实现;这几乎是，但并不完全是自我记录。我认为这对我来说是一个巨大的好处，当我重新审视我当前的项目（我将在几年后将其移植到Groovy asap）以及继承它并继续开展良好工作的继任者时。
那么，有没有理由不使用Groovy？
答案 0 :(得分：26)
我可以想到两个不使用Groovy（或Jython或JRuby）的原因：
这些都是大问题。在大多数应用程序中，性能可能不如人们想象的那么重要，静态类型检查是一个宗教问题。也就是说，所有这些语言的一个优点是它们能够与本机Java代码混合和匹配。两全其美和所有这些。
由于我对您的业务不负责任，我说“去吧”。
答案 1 :(得分：13)
如果你使用Groovy，你基本上丢弃了有关类型的有用信息。这使您的代码“groovy”：简洁明了。
Bird b
变为
def b
另外，你可以玩所有的元类内容和动态方法调用，这些都是Java中的折磨。
然而 - 是我已经广泛尝试过IntelliJ，Netbeans和Eclipse--在Groovy中不可能进行严重的自动重构。这不是IntelliJ的错：类型信息就不存在。开发人员会说，“但如果你对每一个代码路径（hmmmm）进行单元测试，那么你就可以更轻松地进行重构。”但不要相信炒作：添加更多代码（单元测试）将增加大规模重构的安全性，但它们不会使工作更容易。现在，您必须手动修复原始代码和单元测试。
所以这意味着你不经常在Groovy中重构，，尤其是在项目成熟时。虽然您的代码简洁易读，但它不会像每天，每小时和每周自动重构的代码一样精彩。
当您意识到不再需要Java中的类所代表的概念时，您可以删除它。在Eclipse或Netbeans或其他任何东西中，您的项目层次结构就像圣诞树一样亮起，告诉您究竟是什么搞砸了这一变化。 def thing告诉编译器（以及你的IDE）没有关于如何使用变量，方法是否存在等等。并且IDE只能做很多猜测。
最后，Java代码中充满了“样板文件”，但经过多次重构后，它已被捏成最终形式。对我而言，这是为未来的程序员提供高质量，可读代码的唯一途径，包括那些未来的程序员是你未来的。
答案 2 :(得分：9)
Scala可能是Groovy的一个引人注目的替代方案的两个原因：
答案 3 :(得分：7)
使用动态语言时丢失的最大问题之一，特别是在大型代码库中，是使用IDE重新分解因素的能力。现在的IDE无法解析允许动态地向对象添加代码的语言，以允许从Eclipse等处获得简单的重构方法，用于Java，C ++等。
这不是“动态语言比静态更好”的情况。使用最适合你的东西。 Groovy特别酷的一点是你可以在同一个项目中混合搭配Java和Groovy，它们都可以在VM上运行。是的，Scala是另一个例子。
答案 4 :(得分：2)
我认为最大的问题是与java相比缺乏IDE支持，但Eclipse和Netbeans的插件一直在变得越来越好。另外，如果我没记错的话Groovy不支持匿名内部类，如果你出于某种原因真的需要它们。我会随时选择Groovy。