您对Groovy有什么看法？

7

我的团队最近使用Grails（并且暗示，Groovy）实施了一项小型AtomPub服务。总的来说，这是一个不错的经历。我们简单地将纯Java和JRuby视为替代品，但不考虑Jython或Clojure。该团队使用Groovy是因为它比JRuby更为熟悉，但提供了比Java更大的灵活性。

下面是一些我们遇到的问题：

减少刀具的支持比我们大多数人使用（交易这是多么大的取决于个人开发者你问）
可怕堆栈痕迹（这可能比Groovy的更多Grails的错误）
随着整个团队在飞行中学习语言，很难达到一致的，很受欢迎的风格
文件不理想对于Grails（同样，不是Groovy的错）;该文档正在迅速改变，所以现在情况可能已经改善

来源

2009-02-18 20:31:35

5

我目前正在使用Grails进行一个小型探索性项目。我以前没有使用Groovy的经验，只有Java。

到目前为止，我对于如何快速破解一些可用的东西印象深刻，而Groovy的特性，特别是Gpath表达式在这方面起着重要作用。我在Grails中遇到了一些bug，但在Groovy方面没有遇到任何根本性的问题。

Groovy的主要缺点是（对我来说）它比Java更不方便调试 - 堆栈跟踪由于Groovy引擎盖下发生的反射魔法而变得臃肿，并且错误消息可能是神秘的 - 但这可能在大部分原因是我缺乏经验。

来源

2009-02-18 20:32:14

2

我在Grails（当然还有Groovy）中完成了一个中小型项目，并且很享受它。一路上有确定的障碍。它们包括：

缺少好的调试工具（我决定使用，因为它的Grails的大多是原生支持Netbeans的，但它缺乏一个调试器......啊）
错误的网络流量的功能。 Grails 1.1有更新版本的Spring Web-Flow，它解决了很多这些问题。
弱jquery插件支持。我喜欢jQuery，但它不像原型（以及支持的其他JavaScript库）那样得到很好的支持。尽管如此，AJAXy的东西很高兴使用模板编写。
- 难以处理枚举和GORM中的多对多关系。为了解决这些问题，Grails 1.1将会有很长的路要走。

总的来说，我真的很喜欢我的经验，并在短时间内学到了很多东西。 Grails 1.1是一个重要的升级，将使这个框架企业做好准备。我真的只是在等待好的调试工具。我想我可以停止这么便宜，只需购买IntelliJ。我听说它对Grails来说是最好的。

从Java背景来看，走向Grails的道路似乎比用全新的语言和Rails的工具集开始更容易管理。

安德鲁

来源

2009-02-20 02:42:42 anschoewe

2

我们最近实施的中型项目使用Groovy/Grails的，Groovy中已经由Java的依赖团队的其他选择。正如Java的普遍情况一样，一切都花费比它可能的更长的时间。尽管Groovy从Java的冗长风格中提供了一个急需的缓解，但它仍然足够相似，以至于人们不断发现违反直觉的语法。 HLL背后的想法是提供便于人们思考的编程工具，而不是要求人们像计算机一样思考。来自稍微不同的背景，尽管对Java很熟悉，但恕我直言，另一种语言选择，如Ruby，Python或Clojure将为该项目提供更好，更快捷的基础。我与Thoreau一起提出“简化，简化，简化”，而不是厌烦的Java口头禅，“放大，放大放大”。希望纯Java，而不是JVM，将与COBOL一起加入编程垃圾堆。

来源

2011-01-20 15:26:48 totochto

10

我喜欢

瓶盖
的吸水剂
即没有必要在通常的冗余声明MyType x = new MyType()，这可以减少到仅仅def x = MyType()的。然而，在Groovy中输入是没有意义的（我不喜欢那样）。
您可以使用控制台快速轻松地进行测试（尽管公平地说，您可以使用main（...）方法对Java类执行类似的操作）。

我不喜欢

它是弱类型化。这会影响性能，并导致错误。没有什么可以阻止你，甚至也不是警告你，请执行以下操作：

def x = new MyComplexClass() 

// oops! accidentally made x equal to 1, that is, an integer 
x = 1 

// Many lines later ... 

// big fat error. Now x is an Integer, so it doesn't know handle myComplexOperation 
println "The result is ${x.myComplexOperation(a,b,c)}"

它会在运行时失败。

很难维护别人的代码。考虑到您可以将属性注入对象，您突然发现自己的变量不知道它们来自哪里，或者它们是什么类型。
的类型问题可以“缓和”与更多的单元测试，但随后的时间通过编写以下方法保存：
- 您需要决定是否可以接受'a'和'b'是您创建的字符串，整数或矩阵类，或其他。
- 如果您尝试
高清加（INT A，INT B）{A + B}

Groovy中会忽略的参数类型。所以任何人仍然可以通过字符串或其他任何方法“添加”。编译器不会抱怨。

好，你现在如果你想确保参数是整数添加某种验证：

def (Integer a, Integer b) { 
    assert a instanceof Integer 
    assert b instanceof Integer 
    a + b 
}

据我所知，静态语言编译器的目的是为了避免在错误编译时间，而不是在运行时。

如果一个方法调用能够“抛出”一个错误，编译器不会警告你必须放一个try-catch或者添加一个“throws”你的主要方法。如果您没有意识到某种方法可能会抛出异常，那么您可以在不知编译错误的情况下在不知不觉中编译Groovy程序，直到它在运行时激增为止！
控制台是不是很大，因为它没有提供像Eclipse这样做的IDE建议。因此，您需要打开浏览器或书籍才能查看课程的可用方法。还有另一个小陷阱：你不需要使用'def'来在控制台中定义一个变量，但是你需要在程序中使用它们。因此，如果从控制台复制并粘贴到IDE，但不要忘记def。
在我的感觉Groovy是在有限数量很大，但不适合大项目。这是因为许多可能的错误只在运行时才被检测到，所以更多的单元测试和断言是必需的，这部分地损失了编写Groovy程序的速度。
默认情况下，在Groovy的属性是公共的，并得到并自动创建集。你可以重写默认行为，但这只是另一件你可以忘记的事情，并且阻碍了你的类的封装。例如：
```
class Test { String a, b } 

class Test2 { 
    def t = new Test() 
    Test2 (String s) { t.a = s } 
    } 
} 

def t2=new Test2("I am public") 
println t2.t.a 
```

来源

2011-03-18 15:48:43 luiscolorado

3

一个真正的动态语言，它具有简单和漂亮的语法，对现有的Java团队，无与伦比的Java集成和提升以极大的许多方法在现有JDK，带来巨大的生产力收益平坦的学习曲线。它可以很容易地被称为Java/JDK 2.0

尼尔福特做Groovy和JRuby的 http://nealford.com/downloads/conferences/Comparing_Groovy_and_JRuby(Neal_Ford).pdf

关于性能之间的比较的强大，它高超的动态语言和Groovy 2.0支持静态编译使得它真能飞。使用@CompileStatic，Groovy的性能比Java慢1到2倍，没有Groovy，慢了大约3-5倍（...）这意味着Groovy已经准备好了性能必须与Java相当的应用程序。“

性能测试：Groovy的2.0与Java的 http://java.dzone.com/articles/groovy-20-performance-compared

如果你从来没有见过的动态语言的性能数字，你就会得到stucked之前，请参阅与在真实的使用情况等动态语言和Web框架基准（Groovy的1.8 - Grails的1.3.7）：http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

性能永远与你想要做的相关。自2008年以来，我一直在使用Groovy，并在大型项目上取得巨大成功。这只是让工作按时完成业务需求。

希望有帮助！

来源

2012-09-02 05:26:49

您对Groovy有什么看法？

回答

相关问题