Java开发者的Groovy迁移

Question

Java开发者的Groovy迁移

javagroovy

3

我已经是一名Java开发人员多年了。最近，Groovy引起了相当大的轰动。我看了一下，觉得很有趣，但我没有看到任何内在的“哇因素”；也就是说，我没有看到开始使用它的内在价值。

现在，我非常确定我只是看不到整体的优势。所以，我向SO社区提问：学习Groovy对于任何Java开发人员有什么好处？它有什么特点/功能等等，比纯粹的Java做得更好吗？

软件世界中的事情不会无缘无故地迅速流行。我相信Groovy具有各种巧妙的小（和大）功能，使它成为必学的语言；我只是“没看懂”。提前感谢。

- IAmYourFaja

3

可能是为什么会选择使用Groovy而不是Java？的重复问题。 - ataylor

4个回答

1

......既然目前还没有人提供帮助，我建议看一下Groovy邮件列表。类似的问题也会时不时地出现在Grails上。这些都是由曾经遇到同样问题的人组成的伟大社区。

- vector

1

你来晚了。Groovy在大约4年前出现，当时人们厌倦了Java的冗长，准备为了代码简化而放弃性能，而Groovy正是以非常熟悉的语法提供了这一点。但现在它已经存在了一段时间，就像每种语言一样，它被过去所拖累，一些不太好的设计决策也会留下来，我相信它的性能问题也是如此。这基本上是Groovy++出现的原因，它的整个存在都表明它的前任存在一些问题。事实上，Groovy++解决了许多前任的问题，但它也有自己的问题：主要问题是它基本上只受到一个人 - Alex Tkachman的热爱驱动，没有资金支持，因此您应该看到所有涉及的风险。

现在越来越多的强劲竞争对手出现（Kotlin、Ceylon），我认为Groovy已经过了它的巅峰期 - 即使它的核心团队也在颤抖（您应该看到他们在Grumpy模式下的讨论）。这就是我逐渐开始离开这项技术，转而选择Scala，并期待即将推出的Kotlin的原因，这两个项目都很棒，但需要一些“Java思维”来切换，但绝对值得。

由于过于苛刻的反应而进行的更新：

设计错误：

为了实现Java粘贴兼容性而限制语法，虽然在实践中看起来很不错，但事实证明几乎没有使用。因为出于相同的性能原因，将Java代码迁移到Groovy通常是一个坏主意。但这导致了一些Java的荒谬继承，比如不能定义与外部上下文中使用的名称相同的变量。
尽管保留了一些Java的不良实践，但他们也放弃了一些好的特性，比如用花括号标记代码块而不是闭包。这个问题在Scala中解决得更好。
动态类型主要是因为很难实现良好的类型推断而选择的——这基本上是Groovy的创造者后来表示如果当时知道Scala，他就不会费心创建它的原因。

搜索“groovy performance”将给您足够的结果。这里有一个：http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html 我从未说过Groovy++是核心Groovy项目。

我想让你知道，我曾经是Groovy的忠实粉丝，并且在其中专门开发了两年。转向一种新语言对我来说是一个非常艰难的步骤。但是既然我熟悉Groovy的每个角落，了解它的核心团队和倾向性，你应该明白当我建议不要将Groovy作为Java的替代选择时，我知道自己在做什么。

- Nikita Volkov

这个回答中有很多含糊不清的不支持的断言。我们能否举出一些这些“不是最佳设计决策”或性能问题的例子。此外，您说Groovy ++是Groovy的继承者，这并不正确。它们是两个独立的项目。 - Dónal

1

它们只是两个不同的项目，因为Groovy的Codehaus保管人不想将他们无法直接控制的代码捆绑到Groovy 1.x发行版中。Groovy 1.x和++都使用相同的语法和解析器，而Groovy++是一个AST级别的插件，可以插入到Groovy发行版中。只需将Groovy++ jar文件放入Groovy 1.x类路径中，在您的Groovy程序中注释您的项目@Typed，您就可以突然获得更快的性能和类型推断。Grumpy是Codehaus对Groovy++的“刚好够用”的克隆版本，以阻止程序员使用Groovy++。 - Vorg van Geir

1

我认为这就是原因。现在我为Alex感到难过。由于政治决策，他所花费的所有时间都变得毫无价值。而核心团队却在重新发明轮子，而不是让Groovy进化。在我看来，他们唯一能拯救Groovy的方法是在2.0版本中将其变为静态，因为它无论如何都不兼容旧版。现在正在发生的只是悲哀：混乱和混乱的项目没有未来。 - Nikita Volkov

1

我想再补充一点，因为我没有看到它被明确提到。

对我来说，简洁性本身很好，但这不是重点。

无论你写什么代码，Java 看起来总是像 Java，它永远不会读起来像你要解决的问题——它会读起来像 Java，解决你的问题。

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

Groovy 比 Java 更具表现力、更具可塑性。它可以看起来像我想做的事情。其中一个经典例子就是内部 DSL。我经常使用的一个是 easyb，它只是 Groovy 代码，但在我大声朗读时听起来像我正在做的事情。还有很多其他例子，但 easyb 很容易推销。

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

对我来说，一种语言需要是可塑的、可变形的、灵活的：Java 不是。Java 具有贫乏的抽象模型，使得使用它非常令人沮丧——在整个语言中，无论是小规模还是大规模的额外工作量都让人难以置信。

- Dave Newton

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- socha23 · Accepted Answer

我认为，Groovy相对于Java的一些最大优势包括：

terser code thanks to overloaded operators and simplified property access. Instead of writing

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

you can write

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

我认为这种方式更易读。

inline notation for Maps and Lists. Instead of

Map attributes = new HashMap();
attributes.put("color", "red");
attributes.put("width", 1);

你可以编写

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

useful extensions to standard libraries. For example, you can read files and webpages like this:

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

syntactic sugar for initializing properties - for example,

MyClass myObject = new MyClass();
myObject.setFoo("bar");
myObject.setBaz(23);

可以被替换为

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

'safe'引用 - if (str != null) {return str.toUppercase();} else {return null;} 变成 return str?.toUppercase()
正则表达式更加美观
闭包让您以'函数式'风格编写代码，并使编写事件监听器等内容变得更加容易