"Restful" Java WEB MVC frameworks

Question

The application I am developing will be "responsive" , do async communication and pass a lot of JSON back and forth.

I Need a Java MVC WEB framework that supports

1) Minimum amount of BLOAT and "behind the scenes magic". With any framework, there is always a trade-off between framework functionality vs complexity. But, when the time comes when i face a problem and have to "fight the framework"(and that time always comes), I want it to be a fair fight. Minimizing the sheer size of the framework increases the probability of a fair fight.

2) Native RESTFUL support. I.e. route html verbs and perform content negotiation.

3) Straightforward support for processing JSON. Using an arbitrary json processor of my choice, i.e. jackson or gson e.t.c..

4) Straightforward persistance support, e.g. JPA e.t.c.

5) Some set of template systems, e.g. freemarker, velocity e.t.c.

6) Native authentication/authorization security scheme with support for a "role based" security OR Integrate easily with spring security

All of the above should be integrated in the framework. Not in some third party user contributed module that rots away when a new version of the framework comes along.

I sat down for a day and experimented and found the following candidates

Spring MVC 3

1) To get the proverbial "Hello World" example up and running in Spring MVC 3 i needed the following jars:

• org.springframework.beans-3.1.0.RELEASE.jar
• org.springframework.expression-3.1.0.RELEASE.jar
• org.springframework.asm-3.1.0.RELEASE.jar
• org.springframework.context-3.1.0.RELEASE.jar
• org.springframework.core-3.1.0.RELEASE.jar
• org.springframework.web-3.1.0.RELEASE.jar
• org.springframework.web.servlet-3.1.0.RELEASE.jar

And finally some definitions in xml file, "dispatcher-servlet.xml". I don't know if that accounts for BLOAT or too much behind the scenes magic. But it doesn't give me a warm and fuzzy feeling of being somehwat in control

2) Spring 3 supports this and from the examples i saw it does not look too nasty

3) Supported, but from the link in (2) it seems as if processing json is limited to using the jackson library. At least if you want to use the magic annotations for content negotation.

Quote:

"Underneath the covers, Spring MVC delegates to a HttpMessageConverter to perform the serialization. In this case, Spring MVC invokes a MappingJacksonHttpMessageConverter built on the Jackson JSON processor. This implementation is enabled automatically when you use the mvc:annotation-driven configuration element with Jackson present in your classpath."

Bit of a warning signal for me. I would like to have clear programmatic control over what JSON processor i am using. Maybe i am missing something here. This qualifies as unwanted "behind the scenes magic" in my book

4) Yep

5) Yep

6) Yes

Play Framework

1) Version 1.2 weighed 88,5 MB on my disk. Doesn't run in servlet container, so getting the hello world example and running was easy peasy compared to spring, where even finding out which jars i needed was shrouded in secrecy. Obviously a lot of stuff happens behind the scenes in play. I guess all I can hope for is that it does not do more than it has to. And that the arcitecture is sane. But, when i have to fight the framework some day, will I be dead on arrival ? Who knows...

2) Yep and it does so elegantly. Thumbs up.

3) Yes, but it uses gson under the covers. Again, why can i not control this programmatically ? Fortunately, one can pass an arbitrary serializer to gson to override the default. And I think that parameter maps to the second parameter of the play renderJSON() native function. So play passes with half a thumb up.

4) Yep. Has a JPA module

5) Yep. Uses groovy. Fine by me.

6) Should be possible by combining the secure and the deadbolt modules. Don't know how well it stacks up against spring security. I dont see any in-built support for password encryption and the likes. And have no idea how difficult (if even possible) it would be to integrate with spring security. Don't know if i would be comfortable deploying sensitive data and relying on the play! framework for security. Would probably have to build something on top of it.

Restlet

Maybe a peculiar candidate as it's marketed to be used for "restless web services". But for my points (1) -(6) and my type of application where most of the user interaction is async, it seems like a good fit. I can run it on static resources or dynamically generated content and spit out any content type.

1) Restlet 1.1.1 is about 54 MB. Glanced the hello world example. I liked the absence of XML files. And just like play it has its own server(jetty connectors). The hello world example looked very clean and easy.

2) Yes, and the approach is very "programmatic"

3) Yes, but it seems only via a jackson extension module. Given the programmatic nature of this framework, it seems likely that there are other options but i didn't find anything in the documentation or in the user group forums.

4) Describes itself as "persistance agnostic". OK, that's good i guess. But i want to persist and not re-invent the plumbing on my own. Or at the very least i want a little howto showing that it CAN be done with some effort. There is a third party jpa module But it's built on restlet 1.0. Restlet has a spring module though, so maybe i can integrate with spring persistance stuff ...

5) Yes, there is a freemarker extension

6) Has a native scheme for this. At a fist glance, not as "rich" as spring security. Again, maybe I can integrate?

SUMMARY

Spring MVC 3: Supports all of the requirements, maybe with the exception of (1). Only concern I have is that it seems complex and I get a vague unpleasant feeling of not being in control. I really don't want to be "bogged down" by the framework later on as my application grows.

Play: Very pleasant experience. Fun even. If only the security scheme was more advanced, or if I could at least integrate with spring security(and find documentation on how to do it)

Restlet: For some reason this framework resonated with me. The Programmatic approach induces a feeling of control. But if I can't do persistance in some easy-cheasy way then it's a no go. Can't really understand why this is not built in. Doesn't everyone need this?

• What say people who have used any of the above frameworks?
• Are my observations accurate?
• Did I leave out a framework that should be here?
• Alternatives?

Answer 1

the comparison between Spring and Play is now highly out of date, since Play 2.0 has been rewritten in Scala and is better in almost every possible way.

Check it out: http://www.playframework.org/

Answer 2

I can only speak for Spring here.

When I was forced to use Spring for a non-REST project last year I cringed. Not only did I have just a few days to pick up the basics, I didn't like all the "magic" it did, nor was I familiar with IoC principles.

But it grew on me. It grew on me pretty fast too. Since then, I've used Spring for all kinds of Web projects, including one that exposes a RESTful API.

The strengths of Spring from my perspective are: a) it's actually pretty lightweight and usually keeps out of your way once you've got things configured, b) TONS of examples and a great community for support, c) doing REST is a cinch, once you get your configuration right, d) an API design that makes the gods weep with joy, and e) IoC is life-changing.

Speaking to your concern with bloat... I've used other Web frameworks for Java, and Spring is the least bloaty of them all IMO. It might LOOK like a lot, but it's really not. Compared to Struts and Seam (both of which I still have nightmares about), Spring is antithetical to bloat. Moreover, the IoC will let you get away without having to write tons of boilerplate, making your app less bloaty as well.

You mention you don't want to get bogged down by the framework as your app grows. This will not happen in Spring, I guarantee you. It is designed to stay out of the way and to keep you from becoming dependent on any one framework. Your code--if designed correctly--could drop Spring in the future for something else with not a whole lot of cursing and head banging. It favors convention over configuration, meaning the common stuff should work out of the box without having to tinker around too much. For those things that are off the wall, it gives you enough rope to hang yourself.

In summation, I would highly consider Spring.