我们有一个12人的团队，他们都是经验丰富的高级Java开发人员，他们从0.6B开始学习Grails，我们都还在从事基于Grails的项目。我不会心甘情愿地回到Java，我们都松了一口气，因为我们已经学会了如何使用Grails应用程序快速到达某个地方。
这是一场斗争，并不容易，也有挫折感。
尽管如此，考虑到我们的持续努力，我们很快就交付了一些东西。有一些bug，其中很多都有变通方法。
我听说过几个擅长Java的开发人员试图深入研究Grails项目的复杂咒语的例子。我们避开了所有的Java，转而使用纯Grails和Groovy。我们确保从简单开始，尽可能可管理地和尽可能实际地构建复杂性。我们不敢深入到最深的地方，希望我们的Java知识足以支撑我们。
我们最终创建了一个巨大而复杂的东西，它工作得非常好，而且比编写纯Java/Spring/Hibernate版本要快得多；而且没有像样的IDE支持，就bug而言，情况也比现在糟糕得多。
至于对Eclipse的支持，唯一真正用于Grails/Groovy的IDE是Intellij -- Eclipse的支持远远落后于此，遗憾的是:我是一个Eclipse爱好者，远不是Intellij的转换者-- Grails/Groovy的支持完全颠覆了其他一切。
是的，与Spring相比，Grails可能还不成熟。或者休眠。我敢打赌，在它们存在的头1.5年里，它们同样充满了问题。
这就是说，将责任放在你身上，注意将复杂性保持在绝对最低限度，仔细测试-优先(在我们看来)，逐步并小心地建立复杂性。
一旦在堆栈中涉及Spring/Hibernate，Java就没有快速的代码解决方案。Grails体现的复杂性反映了Spring/Hibernate本身的复杂性。如果你觉得你的时间花在纯Java上更好，我不会争辩。我仍然有我的WTF，但现在陡峭的学习曲线已经过去，我想我会坚持更多的Grails。