Ed. Note: This article was originally published in March of 2009. It has been reprinted here because it provides excellent guidelines for evaluating and selecting the right Java web development framework. However, readers should be aware that some details about specific frameworks have changed in the year and a half since it was first published.
Open source application development frameworks have increased in both popularity and number over the past decade. Today, developers can choose from a wide range of frameworks, each of which offers a unique combination of features, limitations, and benefits.But choosing the right framework can be a challenge.Web application development frameworks have become very popular in the last several years. Wikipedia lists over 85 web application frameworks, with a large table comparing features.This article covers some of the factors you should consider when evaluating and selecting a framework for building a Java web application. However, this is never a simple process and many different criteria can and should be considered. In other words, you will want to perform your own additional research.When it comes to adopting a new technology, many of the decision points are organizationally — not developer — driven. When an organization intends to adopt an application development framework, it is typically looking to accomplish three things:
As you begin the evaluation and selection process, beware of people giving easy, emphatic answers. Your development environment and goals are unique. Use this article as a starting point and a general guide, and you should be able to make a decision that helps you increase productivity and decrease pain.
First, we need to define the term application development framework and provide a little history. Application development frameworks are not new. They originally started with user interface (UI) development and have expanded into other areas. Just defining the term can be a little squishy. However, application development frameworks typically provide:
Next, we need to define the types of application development frameworks currently available. There are, in general, three primary types of frameworks:
Zeroing in on web application frameworks, there are two broad classifications to be aware of:
So what's the current landscape? Basically, there are two large conceptual categories that you need to be familiar with: "Full-stack" frameworks and Model View Controller (MVC) frameworks.
Full-stack frameworks address back-end web development for a web app from start to finish. They have some infrastructure or component that addresses the common MVC paradigm plus components that address interacting with databases, possibly in a create-update-and-delete (CRUD) fashion. They interact with message buses, and with naming and directory servers like LDAP.
MVC frameworks are typically the most popular frameworks in the Java web development world and are structured around the framework of a re-usable web application. Re-usability is discussed with the model, the business domain objects, or the controller that handles to request processing.
In summary, both obviously have advantages and disadvantages, and there are too many to list them all. But at a high level, MVC frameworks are typically the most popular frameworks, so we’ll focus on those in our selection process below. However, should you decide to evaluate or select a full-stack framework, you’ll want to consider popular options like JBoss Seam and Spring (though it is debatable if Spring should be classified as a full-stack framework).
MVC is a design paradigm or design pattern that grew out of user interface development. Some people attribute it to Small Talk UI. At any rate, the real focus is to try to figure out how to structure a user interface application around good object oriented programming (OOPs) concepts like encapsulation, cohesion, loose couplings, and abstractions. All of these object oriented programming concepts can create re-usability.
If we were to dissect a user interface in the MVC world, in general we’d find three components:1. The view is responsible for rendering the UI and is directly tied to a model for the state data of the UI. More specifically, as the view renders itself, it calls out to the model and gets back information from the model, so that it could draw a check-box either as a selected check-box or an unselected check-box, depending on the model structure.2. The model contains the state data for the UI and supplies information to the view as requested.3. Depending on the MVC paradigm, the controller functions as a traffic cop to allow the interactions that are triggered through the UI to propagate through the model. So, if somebody selects a check-box, that selection is going to go through a controller, and that controller is going to (hopefully) update the model. Then, the model notifies the view and the view redraws itself.Of course, there are many ways an MVC architecture can be structured. In the interests of simplicity, we will not cover that information here. However, there are two main kinds of competing architectures or ideas on how an MVC framework should be implemented, and they are very important in making your decision. The two types of MVC frameworks that you will encounter are:
We’ve selected six of the most popular MVC frameworks to compare – three action-based and three component-based. You may wish to evaluate different options, but the evaluation process outlined below will help you determine the best framework for your needs regardless of the options you consider.
The action-based frameworks we’ll compare are:
There are many different opinions on how to choose the right framework. Approaches used to select frameworks include:
Since none of these approaches provides a complete picture, we decided to use them all to evaluate the six frameworks outlined above.
Popularity. If you choose a framework strictly based on popularity, you'll pick JSF. But, consider that Sun, IBM, and Oracle have invested time and marketing dollars to make JSF popular, so popularity here is skewed by marketing budgets.Community. If you choose by active community you might base your decision on frequent releases, or the most current release, or the most active mailing list. If your decision was based on the most current release, it would be Stripes. Obviously, in some cases, you might find a recent release simply because of coincidence.Learning. In general, the availability of documentation is common, so perhaps you might narrow down this category to the number of books written on the subject. If that is your differentiator, then again you'll choose JSF (based on Amazon numbers). But then again, it's possible that JSF has more books because it's harder to understand. Choosing, then, by larger numbers of books might not be a great thing to do.Architecture. Looking for Plain Old Java Objects (POJO) is one way to examine the various frameworks. (POJO, used to be "JavaBeans" but the Java community does not like the term because of the enterprise JavaBeans world.) There is constant debate on how much imposition a framework should have on one's architecture. The trend in the last 3-5 years is to separate the application from the framework by using some POJO structure. Some are POJO-based, some "hedge their bets" and let you use POJO with annotations or create a subclass of one of the pre-built classes already included. It's all over the board, so it would be pretty hard to decide based on the cleanest architecture.Pragmatist. One of the major reasons for choosing an application development framework is to reduce the amount of code you have to write, or to increase the productivity of the development team. In that case, you should first and foremost be using "The Pragmatist Formula" as well as the other criteria. Unfortunately, measuring productivity of a development team is a crap-shoot. If someone could figure that out conclusively, they would be very wealthy! Different developers code at different speeds, some developers learn really quickly, others take longer but really master it completely once they get it. Ultimately, it's very hard to measure accurately.
The real motivation for using an application framework is simplified development. While not always the case, simplified development usually translates into increased developer productivity. Therefore, we suggest choosing your framework with productivity in mind instead of using the five criteria mentioned above. Here are some key elements that could be used when making a productivity-focused decision.
When it comes to rapid application development (RAD) consider measuring productivity in terms of support for:
And, yes, it would certainly be possible to add other items here to measure, but the point is to narrow down the list to have a succinct discussion.
When it comes to rich internet application development (RIA), consider measuring productivity in terms of support for:
Convention over Configuration. The idea here is that as a Java developer — historically, at least — you spend 50%-60% of your development effort on configuration. Too much time is (or at least used to be) devoted to dealing with XML files, property files... lots of different pieces. It's been said that "configuration is the demise of Java." The hope has been to move some of that configuration burden off of the developer and let the platform be smart enough to adopt some convention. As long as the developer adopts best-practices or coding conventions the framework can figure out what's being done.
Scaffolding. This generates a boilerplate code, the views, the controllers, the CRUD operations — in other words, a first rough pass at taking the developer's database design and mapping to the web application. Scaffolding has become popular due to the RAILS movement.Inversion of Control. In the Java world, specifically in the Java EE world, there is the mechanism called the Java Naming and Directory Interfaces (JNDI) used to look up internal or external services. These could be an enterprise JavaBean, a database, or a message queue. Instead of the developer doing all those extra steps to look up internal or external services, the framework does the work and hands to the component or object a reference to that external service. In other words, the service look-up responsibility is delegated to the framework.
Choosing a winner is obviously subjective. It's certainly possible to use all of the various formulas discussed above: popularity, community, learning, and architecture, plus pragmatically looking at RAD and RIA. The chart below, then, is based purely on numeric ranking. The lower number is best.
For Popularity, JSF is ranked first.Note: For RAD and RIA, the ranking is 1st, 2nd, and 3rd for Action-Based, and then again for Component-based, so they're ranked twice. Therefore, Stripes is ranked as more productive under Action-based RAD, though it's only more productive because it supports more of the evaluation criteria, and Spring MVC is better from a RIA perspective because it supports more of the capabilities that were identified. On the Component-based side, Tapestry supports more of the RAD capabilities for both RAD and RIA.So, in conclusion, obviously the list of frameworks we evaluated is not comprehensive. You may want to add to the list or take things away. It depends very much on the type of web application that you intend to build and what features and functionality you are looking for. And, to be clear, in the table above, Tapestry comes out as the winner, but in no way does this suggest some sort of absolute winner. Nor is JSF the biggest loser.
There are other criteria that you may very well want to consider. Licensing is one. In this case, every single framework supports the Apache 2 license, which is very good for the developer community.
They all support Java 1.5 except for Spring MVC, which utilizes Java 1.4. This may not be an issue if your organization only has 1.4.Most of the frameworks support Spring, so typically you can layer your framework on top of Spring. There's some debate and discussion on whether you can get Spring and Wicket to work nicely together, hence the question mark here.JSF support is uneven, but all of the frameworks support a validation mechanism. You could also evaluate whether the framework supports JPA, or EJB, or has a templating engine.A Note about ScaffoldingIf you truly want to get that scaffolding functionality with generation of the UIs or the views, and generation of the controllers, models, and CRUD operations, the first thing you probably have to do is move away from an MVC and into a full-stack implementation. Seam, for example, has a full-stack implementation. The challenge with SEAM is that it is really focused on Java EE development, and if you don't like Java EE that's not so great for you. More commonly, if you want the full scaffolding support, you'll use a dynamic language in a dynamic language framework like Ruby on Rails or Grails. The point is that if you want the full-stack capability interacting with a database you have to move beyond a framework that is just structured around re-usability of the model view and controller.So... that's how things stack up!
Allowed tags: <a> link, <b> bold, <i> italics