Choosing a Java Web Framework now?

Question

we are in the planning stage of migrating a large website which is built on a custom developed mvc framework to a java based web framework which provides built-in support for ajax, rich media content, mashup, templates based layout, validation, maximum html/java code separation. Grails looked like a good choice, however, we do not want to use a scripting language. We want to continue using java. Template based layout is a primary concern as we intend to use this web application with multiple web sites with similar functionality but radically different look and feel.

Is portal based solution a good fit to this problem?

Any insights on using "Spring Roo" or "Play" will be very helpful.

I did find similar posts like this, but it is more than a year old. Things have surely changed in the mean time!

EDIT 1: Thanks for the great answers! This site is turning to be the best single source for in-the-trenches programmer info. However, I was expecting more info on using a portal-cms duo. Jahia looks goods. Anything similar?

Answer 1

I would second the Spring recommendation. I'm not a huge fan GWT, I don't think the Java -> Javascript crosscompiler is quite there yet. I am working on an AJAX app that uses spring on the server and jQuery on the client. Although there is technically not "out-of-the-box" support for jQuery, implementing a spring-MVC AjaxView is dead simple and took about 25 lines of code.

Answer 2

Ext GWT + Spring

Answer 3

The top three choices for me are (alphabetically):

• JSF
• Spring MVC
• Struts 2

They:

• have good ajax support
• allow you making actual web-sites, not applications (like GWT)
• stable, well-documented, widely used
• MVC
• pure Java
• easy integration with Spring as middleware

Answer 4

JSF is a nice framewrok, but JSF 1.2 lacked vision for years to come from its release. JSF 2.0 looks promising and has many new things added fro m JSF 1.2 like ajax support, facelets, Annotation support and default conventions (less XML),easy component building than 1.2.

It integrates well with Spring also, if you are concerned for DI support.

Answer 5

Is portal based solution a good fit to this problem?

Personally, I would stay away from big fat Portal solutions (they are often productivity killers). I've heard good things about Gatein though but I don't have any real experience with it.

Any insights on using "Spring Roo" or "Play" will be very helpful.

About Spring Roo, I've read previous answers like Spring roo Vs (Wicket and Spring) and other things over the Internet but I'm still not convinced (maybe I don't get it), I'm not sure of its maturity, and, more important, I'm really wondering what SpringSource is doing with Grails and Roo (no, Grails vs Roo - why SpringSource is pushing two very similar technologies? doesn't convince me that they will both survive).

I can't say much about Play. I've seen the demo like everybody but I would like to read real life feedback. Until then, I'll wait.

I did find similar posts (...). Things have surely changed in the mean time!

Yes and no :) But let's enter the presentation frameworks hell: there is no single answer to your question (like one year ago), there are dozen of frameworks around there and no clear winner. Just to cite a few:

• JSF: Lots of skeptics about this component based framework, including me so I'm not the best one to talk about it but...
• JSF 2 (+ CDI/Weld): JSF skeptics are encouraged (by Gavin King) to "take a second look". Indeed, I think that JSF 2 is a big improvement, especially with CDI, but... it is still pretty new (understand, it lacks of feeback). If you want to embrace Java EE 6, check it out though.
• Wicket: Another component based framework that is getting more an more attention. I hear mostly good things about it: simpler than JSF, nice design, high testability, HTML designer friendly, etc. You may like it.
• Tapestry: Just don't (see Why did you stop using Tapestry?)
• Struts 2, Spring MVC, Stripes: Action based frameworks. All decent and will cover your needs (personally, I like Stripes and its convention over configuration approach, see Stripes vs. Struts2 to get an idea of it).
• GWT, Flex, Grails: These aren't maybe not what you're looking for. I can't really talk about (recent versions) of Flex and GWT but I know that Grails does have some fans.

Actually, I'd suggest to take a look at Matt Raible's presentations, he really did a great job at comparing web frameworks, showing their strengths and weakness, gathering facts and numbers, showing trends... I recommend:

• Comparing JSF, Spring MVC, Stripes, Struts 2, Tapestry and Wicket (still not obsolete)
• Web Frameworks of the Future: Flex, GWT, Rails and Grails (just to get a taste of alternatives)
• Comparing Kick-Ass Web Frameworks (this one is the most recent)

Really, have a look at these presentations, they will help you to find an appropriate framework (there is no unique answer but you can restrict the choice by elimination) and might change your point of view.

Answer 6

Play is closely similar to ROR, a ROR version in java

Answer 7

Top choice for me is Wicket. Clear separation of markup and java code. Very easy to write and use components. Simple to use Ajax, testability. You can debug right into your pages / components and don't get cryptic error messages from your JSF implementation ;)

There is also a good comparison wicket <--> JSF in terms of performance

Answer 8

I've found stripes to be really effective and surprisingly lightweight....it aims to be more lightweight than struts. I've heard from friends that are fulltime web developers that JSF is not worth bothering with, although I have no firsthand experience, and can't back that up with examples (!).

Answer 9

I think what you are looking for is something close to Jahia. It supports GWT, Mashups, Media Content etc.

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templates http://www.jahia.net/downloads/jahia/jahia6.0.0/readme/index.html

Answer 10

Try http://www.hybridserverpages.com/

It is a very simple technology all described on less than ten web pages. There are only two things you have to know: Java and HTML. It is based on Servlet API but completely hides it below a much more convenient pages and components.

Answer 11

Have a look to RESThub, that follow the same principles that Play! but implemented by reusing some enterprise grade frameworks/tools like Maven 3/Spring 3/Jersey/jQuery.

RESThub is very disruptive comparing to other frameworks since it is a full stack toolkit, but without any serverside MVC or servlet based framworks. Instead, it use a jQuery UI based GUI that use JAX-RS (REST) webservices and a Javascript templating system based on embeddedJs.

Servers are stateless, and we use HTML5 sessionStorage to keep session on client side. This approach is design for RIA and scalability.

Some demo applications are provided (even if under construction).

Answer 12

Maybe I am too pessimistic, but it seems that currently every webframework has a major disadvantage:

JSF2 - Released and already aged. Still only a few news/articles/blog posts/experiences out. I am sceptical. Still waiting for the next major release of Richfaces/Icefaces which fully supports jsf 2 - currently only alpha builds can be downloaded.

Struts 2 - Seems to be only a good thing if you're still relying on struts and want to refactor most of your code. Otherwise: Don't.

GWT - I do not like the single-page and the java->javascript approach. I am not sure if one session - multiple views/windows can be easily achieved. For me, this framework should be used for massive-users single-window rich internet applications.

Wicket - Nice approach, but a little bit verbose and too less documentation available (except the good wicket in action book, but this covers only 1.3). Also, for me it lacks of big projects which are built on top on it. And I currently cannot see where the road of wicket is travelling or if it has already been droven to a dead end.

Spring MVC - Did not tried this yet, but you have to include many jars (spring mess) in your classpath to work with this framework properly. And it relies on JSP (in most projects), which I consider already dead. And you get only a pure MVC framework - all other things (ajax and others) have to be implemented/integrated.

Stripes - A small and nice designed MVC framework, but too less documentation, too less commits/committers, too less releases, too less industry support, too less mailing list activity.

I am also curious if I missed a major framework out there (I left Tapestry out intentionally) which might be an option for you (and also for me, too).

Answer 13

I've been using Spring 3 and Jquery for a while but heard about Play and gave it a shot. I really like it, Play is a great fit between something like PHP and the heavy duty Java frameworks like Spring.

The things I like most about play are:

• Very easy to get a play application off the ground, you have to go pretty far with coding and configuration to get a simple crud application on the screen with Spring (though Spring 3 has made it a lot easier).
• Spring Security is awesome but it comes at the cost of complexity. Play's security module is very very simple and covers the needs of probably 90% of applications out there.
• You can make a code change and hit refresh in the browser to see the change like with PHP instead of having to do the whole redeploy thing with Servlet based frameworks.
• Error messages are displayed nicely and not so cryptic most of the time. Play still needs to work on their error handling
• There's a plugin mechanism for Play that's pretty simple.
• Object persistence is done very nicely in that an in memory database and JPA comes with the framework so there's no configuration of external object persistence tools. Going from the in memory database to an actual RDBMS is a one line change in the config file.
• The MVC setup is done very well. The Model class you extend to create your domain objects integrates with the JPA entity manager. They're not just POJO's.
• Mapping URL's to controllers is simple and flexible and all in one "routes" file.
• Whenever you create a project Play handles all the jar dependencies and Play has a utility to eclipse-ify (or whatever IDE you like) the project so that it imports directly into your favorite IDE.

Things I don't like about Play

• The documentation isn't all the way there yet, lots of undocumented features still exist.
• The framework is the server so you have to dedicate a port to each application. I think someone is working on a virtual host plugin but I haven't seen it in action yet.
• It's young, the project is awesome and technology is awesome but it really needs some more developers. I would love to dedicate some time to it, we'll see.

Answer 14

BACKBASE PORTAL SOFTWARE

Couple of years back have used portal software "Backbase" this was not very matured then. But was good and easy for development.

Answer 15

Also check out the wiki article:

http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller

Answer 16

Something that deserves more than just a bullet are player based RIA frameworks. Ex. Adobe Flex + Java (Of course this can hinge somewhat on whether your "site" is really a "site" or more like an "application", you wouldn't do a blog site in Flex.)

ajax,

In the AJAX-as-a-buzzword sense, Flex typically uses AMF (a binary protocol that's more efficient than protocols used by AJAX apps), although you can also do strictly AJAX stuff with Flex too. So Flex supports AJAX, but also supports "better than AJAX".

rich media content, mashup,

Being that Flex runs on the Flash 'virtual machine' platform, I think little needs to be added.

templates based layout,

Not sure what this is getting at exactly, but it sounds like Flex mxml.

validation,

Supported of course, although you may decide to do some custom stuff if you want to get fancy. (Not that you have to.) The nice thing is that you can get as sophisticated as you want--or not.

maximum html/java code separation

You can't get more separated by using a 'virtual machine' development approach like Flex/Silverlight/JavaFX. This doesn't just enable you to keep your presentation code separated from your server-side logic and data access layer--it ensures that they're separated. 'Virtualizing' your development environment gets you cross-browser compatibility, a consistent target platform, no worries about new browsers or new browser releases breaking your application, top of the line java-like debugging capabilities, and a more professional/impressive looking end product.