Matt Raible of Raible Designs gave this morning's keynote presentation comparing Java Web frameworks (slide - PDF). Matt started off with an overview of the pros and cons of each framework, as he saw them.

Java Server Faces or JSF is the Java EE standard. Lots of demand and lots of jobs working with JSF. Initially, its fast and easy to develop with. There are a lot of tools and component libraries are plentiful. The bad news: Tag soup for JSPs--the pages are lots of anything but HTML. JSF doesn't do REST-style Web services well and security can be a problem. What's more, there's no single source for an implementation. Consequently, it's hard to track down answers about problems.

Spring MVC has lifecycle for overriding binding, validation, etc. It also integrates iwth many view options seamlessly: JSP/JSTL, Tiles Velocity FreeMarker, Excel, XSL, PDF, and others. Because control is inverted, it's easy to test. The downside: lots of configuration. Also, it's almost too flexible. For example, there's no default parent controller. Spring MVC doesn't have built-in AJAX support. That can be an advantage since built-in AJAX support in other frameworks is frequently out of date.

Stripes doesn't use XML following the Rails mantra of convention over configuration. There's good documentation and Stripes is easy t learn. An enthusiastic community is eager to help newcomers get up to speed. The cons: the community is small and development is not as active as in other projects. If Stripes does what you want, great. If it doesn't then you may be out of luck. Another problem, Action URLs are hard coded.

Struts 2 has a simple architecture that's easy to extend. The tag library is easy to customize with FreeMarker or Velocity. You can use either controller-based or page-based navigation. Digging into the code is pretty easy. The downsides: Documentation is poorly organized. It's wiki-based and mostly just thrown together. There's too much concentration on new features rather than stabilization. Using Google will give you back Struts 1 documentation rather than Struts 2 documentation.

Tapestry can be very productive once you know it. Templates are HTML, so it's very designer friendly. Lots of innovation happens between releases. On the other hand, the documentation is conceptual rather than pragmatic. It can be hard to find answers to specific problems. There's a steep learning curve and a long release cycle.

Wicket is great for Java developers, not Web developers. There's a tight binding between pages and views. There's an active community and getting support from the creators is easy. But... HTML templates live next to Java code in the package. Could be a good thing, but it throws people off at first. You need to have a good grasp of OO. You need to be willing to live with the "Wicket way"--everything is done in Java.

Matt moves into an evaluation based on the following criteria:

• Ajax Support: Is it built-in and easy to use?
• Bookmark-ability: Can users bookmark pages and return to them easily?
• Validation: How easy is it to use and does it support client-side (JavaScript) validation?
• Testability: How easy is it to test Controllers out of container?
• Post and Redirect: How does the framework handle the duplicate post problem?
• Internationalization: How is i18n supported and how easy is it to get messages in Controllers?
• Page Decoration: What sort of page decoration/composition mechanisms does the framework support?
• Community and Support: Can you get questions answered quickly (and respectfully)?
• Marketability of Skills: If you learn the framework, will it help you get a job?
• Job Count: What is the demand for framework skills on dice.com and indeed.com?

I won't report the detailed results of the evaluation of each framework in these areas. See the slides if you want to see the results (and pretty graphs). What do people use? Struts and JFC were reported as the most used in an AppFuse survey.

After the session, I asked Matt which of the Java frameworks is most like Rails. He said that Struts2 and Spring were trying hard on the convention over configuration front and Tapestry 5 is promising dynamic class loading. He ended by speculating that the best solution was probably a hybrid with Java doing the heavy lifting on the back-end and some dynamic language doing presentation on the front end.