面向 Java 开发人员的 Groovy 迁移

Question

我从事 Java 开发人员已有几年了。最近，关于 Groovy 的讨论相当热烈。我检查了一下，它看起来很有趣，但我没有看到它有任何固有的“哇因素”；也就是说，我没有看到任何开始开发它的内在价值。

现在，我确信我在这里只是没有见树木不见森林。因此，我向整个 SO 社区询问：学习 Groovy 对任何 Java 开发人员来说有何意义？有哪些特性/功能/等等。它比普通的 Java 做得（或者做得更好）吗？

软件世界中的事物不会无缘无故地像野火一样腾飞。我确信 Groovy 具有各种漂亮的小（和大）功能，这使其成为必须了解的；我只是没有“明白”它。提前致谢。

Answer 1

在我看来，Groovy 相对于 Java 的一些最大优势是：

• 由于重载的运算符和简化的属性访问，代码更加简洁。而不是写

  if (obj1.getBar().equals(obj2.getBaz())) { 
      obj3.setFoo("等于");
  }
  

  你可以写

  if (obj1.bar == obj2.baz) {
      obj3.foo = "等于"
  }
  

写，我认为这样更具可读性。

• 地图和列表的内联符号。而不是

  映射属性 = new HashMap();
  属性.put(“颜色”,“红色”);
  属性.put("宽度", 1);
  

您可以为标准库编写

    def attributes = [color: "red", width: 1]

• 有用的扩展。例如，您可以像这样读取文件和网页：

  def fileContents = new File('readme.txt').text
  def pageContents = new URL('readme.txt').text
  

• 用于初始化属性的语法糖 - 例如，

  MyClass myObject = new MyClass();
  myObject.setFoo(“酒吧”);
  myObject.setBaz(23);
  

可以替换为

    def myObject = new MyClass(foo: "bar", baz: 23)

• 'safe' 解引用 - if (str != null) {return str.toUppercase();} else { return null;} 变为 return str?.toUppercase()

• 正则表达式看起来更好

• 闭包允许您以“函数式”风格编写代码，并使编写事件侦听器等内容变得更容易

Answer 2

...由于到目前为止还没有人参与，我建议查看 Grooy 邮件列表 。关于 Grails 的类似问题也时常出现。这些都是伟大的社区，由曾经在某个时刻面临过相同类型问题的人们组成。

Answer 3

我会添加另一个，因为我没有看到明确提到它。

对我来说，虽然简洁本身就很好，但这并不是重点。

无论您编写什么代码，Java 总是看起来像 Java，而且它永远不会读起来像您正在解决的问题——它读起来像 Java，解决您的问题。

我想要相反：我希望我的代码读起来像我正在解决的问题，用[在此处插入语言]编写。

Groovy 比 Java 更具表现力、更具延展性。它可能看起来像我正在尝试做的事情。典型的例子包括内部 DSL。我经常使用的一个是 easyb，它只是 Groovy 代码，但听起来像我的代码当我大声读出来时我正在做。还有很多例子，但 easyb 很容易推销。

还没有提到的是 AST 转换允许很酷的编译时技巧。您可以使用 AspectJ 等工具在 Java 中玩类似的游戏，但它并不是“内置”的。像 @Delegate、@Singleton 等这样的东西非常方便。

对我来说，一种语言需要是可延展的、可变形的、灵活的：Java 不是。 Java 的抽象模型贫乏，使用起来令人沮丧——整个语言中大大小小的额外工作量有时令人难以置信。

Answer 4

你参加聚会有点迟到了。大约 4 年前，Groovy 迎来了它的曙光，当时人们厌倦了 Java 的荒谬冗长，准备为了减少代码而放弃性能，而 Groovy 正是以一种非常熟悉的语法为他们提供了这一点。但现在它已经存在了一段时间了，它像所有语言一样受到过去的拖累，一些不是最好的设计决策仍然存在，就像我很确定它的性能问题一样。这基本上就是 Groovy++ 出现的原因，它的整个存在表明它的前身存在一些问题。事实上，Groovy++ 解决了其前身的许多问题，但它也有自己的问题：主要的一个问题是它基本上仅由一个人的奉献驱动 - 即 Alex Tkachman， - 并且没有资金，所以你应该看到所涉及的所有风险。

如今，越来越多强大的竞争对手出现（Kotlin、Ceylon），对我来说，很明显，Groovy 甚至已经过了它的顶峰 - 甚至它的核心团队也在颤抖（你应该看看他们对 Grumpy 模式的讨论）。这就是我开始逐渐放弃这项技术而转向 Scala 的原因，并期待即将推出的 Kotlin，这两个项目都是很棒的项目，但要让“Java 思维”转向需要付出一些努力，但绝对值得。

由于过于挑剔的反应而进行的更新：

1. 设计错误：
   • 限制 Java 粘贴兼容性的语法，虽然在实践中看似简洁的功能最终被证明根本没有使用，因为出于同样的性能原因，将 Java 代码迁移到 Groovy 通常不是一个好主意。但这导致继承了一些Java的荒谬之处，例如无法定义外部上下文中使用的名称的变量
   • 在保留 Java 的一些不好的做法的同时，他们也放弃了它的一些好的特性，比如用大括号而不是闭包标记的代码块。这个问题在 Scala 中解决得更简洁
   • 之所以选择动态类型，主要是因为正确的类型推断很难实现——这基本上就是 Groovy 的创建者后来声明 如果他当时知道 Scala，他就永远不会费心去创建它。
2. 谷歌搜索“groovy Performance”会给你足够的结果。这是一个： http://stronglytypedblog .blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html
3. 我从未说过 Groovy++ 是与核心 Groovy 相同的项目。

我想让您知道，我曾经是 Groovy 的忠实粉丝，并且连续两年专门使用它进行开发。转向新的语言对我来说是非常困难的一步。但由于我了解 Groovy 的每个角落，我了解它的核心团队及其倾向，所以当我建议不要将 Groovy 视为 Java 的替代品时，您应该明白我知道我在做什么。