JVM Frameworks, which one?

I don't have much experience in frameworks or languages, so i need your help.

Here's what i've done so far so you can understand where i'm coming from.

I've developed a web app using Java/Spring MVC/Hibernate. on the front end i've got some jquery datatables doing ajax calls to a db, another pages executes a stored prod and thats about it.

Now i got fed up with all the configuration, beans, hibernate mapppings, spring mappings, apache tiles, and the list goes on.

I had a play with Groovy/Grails and that seems so much easier, but that means i need to learn groovy and i've heard about it's performance weakness.

So i ran into Play Framework, can someone tell me if Play would make my life easier with the above scenario or should i just go into Groovy/Grails or even scala/lift.

I don't have too much time on my hands to pick up another language so if i can stay with core Java and use Play that would be great.

So is my described headache the reason why there's RoR/python-django, grails ect,ect? or is it something else?

thanks,

glenn.

I can tell you from the perspective of a 10 year J2EE developer who went from JSP/servlet to Grails to Play. 6 years ago I discovered groovy and I liked it very much, I've been using groovy and it's GSP templates in my other projects for code generation. I really love groovy syntax. Because you can do a lot in a single line of code ;) Because of groovy I tried Grails. But, besides the use of the language to code something in perhaps some 20% of the project time, you are 80% dealing with Grails conventions. How do they map this and that and to the persistence layer (which is JPA underneath the surface). So you're browsing the docs most of the time.

Then I found play. It really felt natural. Everything is so quick with it. Everything is direct, it is 80% undisturbed, productive coding, only 20% reading the docs. The code completion of any Java IDE is literally sufficient support. In Grails you either need a Grails IDE or you find yourself frequently browsing the docs.

The biggest attractor of Play to me is the hot code swap feature, which nearly completely eliminates the build phase. Play's class enhancers give you enough comfort to get over the loss of those dynamic finders in Grails. In the meantime, I even write my own enhancers to get even more comfort.

In a real project, the strongly typed Java language is a huge benefit to all developers. You just can't break it so easily as you can with groovy.

Also, if you look at the Play package, you always get reasonable defaults. Things that all developers like. jQuery based CRUD, beautiful code samples, good visual experience. And it's all as minimalistic as possible. Which means, you can always go to the play framework source itself and read the code to understand play's behavior.

So to sum up, after 10 year of Java and J2EE frustration and almost giving up on Java I switched back to it as implemented by Play, because in Play it is so much fun and I now love it again. I recommended play to 2 other developer friends and they love it too. It feels like the Java that it should have been in the first place. Fast, clean, secure & a lot of fun. I will never use something else based on Java, not even for a simple main() ;)

Play!

After 6 or 7 years of Spring/Hibernate, a couple of more with JSP/EJB I was done with the Java world, looking for other alternatives like Scala, Node.js, Rails, etc. Play Framework has made me fall in love with Java all over again, even though I do recommend Scala.

I have lots of information about Play on my blog http://geeks.aretotally.in and http://playframework.info.

It's super easy to pick up, it's crazy productive and you will have lots of fun!

If you ask a Play framework guy, he will tell you to use Play. If you ask a Scala/Lift guy, he will tell you to use Scala/Lift.

Ideally you'd like to find someone who has used Groovy/Grails, Scala/Lift, and Play, but unfortunately there are not too many of those around.

FWIW, I use Groovy and Grails, and like it a lot. If you already know Java, Spring, and Hibernate you already know most of what you need to be productive with Groovy/Grails.

If you don't want to spend a lot of time learning a new language, I'd stay away from Scala, as it's a very different language to Java, whereas Groovy is almost a superset of Java, and with a familiar syntax.

I know virtually nothing about Play, but I'd be concerned about the size of the community - check the number of Play and Grails questions on stackoverflow for a rough comparison.

Grails 2.0 performance will be pretty much on par with the static typed languages out there.

Based on your current architecture, Grails would be the most natural fit - you can re-use all existing classes and code without an issue, and have it directly picked up. You can freely use @Autowired and other Spring annotations, java code, and Grails picks it up - because Grails is Spring under the covers. The only part that might need a little tweaking are JSPs, but I was able to get existing JSPs and custom taglibs working without an issue. Grails uses SiteMesh to compose it's Groovy Server Pages (think JSP groovy-ized, and removing some of the JSP restriction gotchas).

Nothing against Play, Lift, Clojure's web framework, SEAM, or any of the other frameworks out there -- but if you want a simple transition from what you have to something a little more productive, then Grails would be the closest fit.

Of course these days, just about every one of those frameworks supports polyglot programming - you use Scala for something, Groovy for something else, and Java all around - compilers, build environments, and tools are all addressing polyglot development.

Long story short, it comes down to requirements and risk management - do you need functional programming, dynamic typing, re-use of your Spring controllers, or just some simplification and productivity boosts?

Even a simple Spring 3.1 upgrade may eliminate some of your XML files for annotations and solve most of your problems.

Happy Hunting!