我们正在用Java编写一个大型生产系统,我正在考虑是否可以用一种基于JVM的动态语言编写一些组件.从Java互操作性的角度来看,Groovy似乎是最好的选择.但是Groovy实现是否足够可靠以便在生产中使用(我会这么认为),并且Groovy语言规范本身是否足够稳定,以便我们不必在一两年内大幅修改我们的生产代码？你有什么经历？
总结(2009年5月30日):好的评论,我得到的意思是你应该谨慎地采用Groovy进行关键任务生产使用,它适用于诸如组合测试用例之类的辅助用法,并且它有一个中间地带,它是可能没事,但先做好功课.性能是一个问题,需要与开发人员生产力的提高相平衡.比尔和Ichorus基于Groovy的使用有同样有用的答案,所以这是一个抛硬币.
更新(12/3/09):最近我一直在认真研究另一种JVM语言Scala.它由Martin Odersky设计和实现,他是当前javac编译器的原作者和Java Generics的联合设计者.Scala是一种强类型,但使用类型推断去除大量的样板.它是面向对象和函数式编程的完美结合.詹姆斯戈斯林喜欢它.Groovy的作者James Strachan 也喜欢它.而Odersky在撰写javac方面的经验意味着Scala的原始性能与Java相差无几,令人印象深刻.
Ich*_*rus 20
编辑:差不多四年后,Groovy变得更加稳固.
我可以全心全意地推荐它用于生产级项目.
我一直在使用Groovy来支持生产应用程序一段时间,为此它足够稳定.至于在真正的生产代码中实际拥有Groovy; 我不认为我会这样做.Groovy做了太多令人惊讶的事情.在过去一年左右的时间里,它在这方面已经变得更好了,但是每隔一段时间我就会遇到一个由于生成的代码而难以追踪的错误(我的问题似乎围绕着范围界定).
我已经离开了Groovy(虽然我们使用的东西很简单而且仍然可靠)并使用了Python(jython实现),我认为这更加可预测.此外,python在可读性方面胜过Groovy.
你可以在Groovy中编写一些非常有趣的代码,包括闭包和运算符重载等等.
这些语言用于方便和快速的辅助代码...如果需要可以动态切换的东西.它们都没有投入生产.我不认为我会把它们投入生产,除非它是一个权宜之计,以便在一个重要的时候把一些关键的东西拿出门外,或作为一个概念或原型的证明.
在将它放入实际生产的情况下,它必须处于最严峻的环境中,我会指派某人用纯Java重写它以用于下一个版本.我98%肯定要么生产好,要么2%是不必要的风险.
bil*_*dev 17
我们在Grails上运行了几个生产应用程序(使用Groovy作为语言).到目前为止,没有出现任何问题.至于JVM兼容性,看一下JVM字节码在过去5年中的变化有多少......就像添加了1条指令一样,并且没有任何一条是令人满意的.
Groovy的新版本会在明年推出吗？是.你会被要求改变吗？不,虽然你可能想要,1.6是一个巨大的速度提升.
这给我们带来了Groovy的主要缺点,即速度问题.显然,Groovy比直接Java慢.某些操作的当前数量最多可达10 倍.那就是说,你的CPU是你应用程序的瓶颈吗？对我们来说,主要是数据库访问和延迟.如果它对你来说是一样的,那么如果CPU花200ms来处理页面请求而不是35ms呢？
这是Groovy唯一的问题吗？不.动态语言具有重构困难,因为代码中的任何地方都不一定有完整的类规范.但是,这部分地通过较小的代码大小来平衡,这使得更容易找到修改代码的位置.
无论如何,Groovy是一种非常适合生产用途的语言.如果您担心可靠性,请将它与Java混合用于"关键"代码.这是Groovy的最佳部分......它与Java类的混合程度是多么容易.
我目前正在探索使用 Groovy 仅编写单元测试。这有以下效果
当然，我们还没有开始，但这至少是我尝试将替代 JVM 语言引入我们的新项目（可能还有现有项目）的方式。我和你有同样的担忧，尤其是性能而不是稳定性。
| 归档时间： |
|
| 查看次数： |
4723 次 |
| 最近记录： |