When it comes to developing web applications using Java, writing all the code from scratch has its advantages if you’re trying to master a new technology, but for real life web applications, you have to go for a framework as many expert developers would agree. Otherwise you risk a great deal of failure because of having allocated too much time and too many resources by re-inventing the wheels.
There are some hardliners who still argue why there’s ever a need for a framework, since everything can be accomplished by Servlets, JSP and Filters. One of them is Bear Bibeault author of JQuery in Action.
The cost is an important factor—although “free” in most cases also means widespread usage, community support, and no dependence on a single vendor. It takes some time for developers to get used to a framework and be good at it. Therefore choosing a framework as a long-term strategy. You cannot be switching frameworks for every project. Sticking with one framework also helps as once the expertise in that framework builds up; customizing the framework also becomes a possibility.
A tempting option is for organizations to build their own framework to address needs specific to the kind of work the organization undertakes. Although it does
seam seem to make sense on paper, for my money, this is a suicidal strategy. Thoroughly testing and maintaining a framework is a huge task that will need dedicated human resources. These few people would become critical and the only source of support for others using that framework. Also, with so many quality frameworks available for free, I seriously doubt it really is necessary.
As with many web frameworks emerging nowadays, the ever-increasing number of Java web application frameworks out there today is intimidating for many developers even to look into because of being presented with too many choices. However, matching the criteria of popularity, widespread usage and tooling support, I can list a few of the best Java web application frameworks here and in a descending order of my personal choice. Sorry if I haven’t listed your favorite Java web framework here, feel free to agree or disagree in the comments section.
- Struts (2)
Struts 1.x was the first most popular and widely accepted web framework for Java, because of the way it handled the MVC model 2 paradigm and its action-based architecture. It was an elegant framework that handled the flow of application and a lot of other routine tasks. Another advantage of using Struts was an incredibly growing number of developers preferred it as a de-facto J2EE standard. Many of the popular Java IDEs also provided tools for Struts development, making life even easier for the programmers. Even today IDEs like NetBeans and JBoss Developer Studio have built-in support for Struts 1.
Apache Struts 2 was originally known as WebWork 2 built on top of XWork, which provided a generic command pattern framework as well as an Inversion of Control container. After working independently for several years, the WebWork and Struts communities joined forces to create Struts2.
Programming the abstract classes instead of interfaces is one of design problem of Struts 1 framework that has been resolved in Struts2. Most of the Struts 2 classes are based on interfaces and most of its core interfaces are HTTP independent. Struts 2 Action classes are framework-independent and are simplified and they resemble POJOs. Framework components can easily be loosely coupled.
Struts 2 Actions are simple POJOs. Any java class with execute() method can be used as an Action class. With Struts 2 you don’t even have to implement interfaces. Inversion of Control is introduced while developing the action classes. This make the actions to be neutral to the underlying framework
ActionForms are also gone in Struts2. Simple JavaBean flavored actions are used to put properties directly. No need to use all String properties.
Biggest downfall of Struts 2 is poor documentation and no debugger feedback for missing properties or invalid OGNL expressions which makes debugging a nightmare.
“With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again” says the Apache Wicket Team in their description of this young and popular framework. “Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML”.
It’s a wide-spread Java web application framework mostly adopted by Struts old-timers and those who refuse to switch to JSF and Seam as far as what I observe.
Wicket strives for a clean separation between the roles of HTML page designer and Java developer by supporting plain HTML-based templates (which live next to Java code) that can be built using any WYSIWYG HTML design tools. The templates can then be made dynamic with little modification.
Like other frameworks, Wicket is built on top of Sun Microsystems’ servlet API. However, unlike frameworks based on the Model-View-Controller (MVC) model (such as Struts), Wicket takes away from you the task of handling request/response objects, which is inherent with technologies such as servlets. By taking away this task, Wicket allows you to concentrate on the application’s business logic.
As a Wicket developer, you should think in terms of building reusable components that are stateful, instead of building controllers that handle request/response objects and worrying about multithreading issues. Instead of creating a controller or action class, you create a page, place components on it, and define how each component reacts to user input.
Wicket is great for Java developers, not especially for web developers. It requires a good grasp of objected-oriented programming as everything’s done almost in pure Java. It It has tight binding between pages and views and there’s an active community support including support from its creators.
Spring MVC and Webflow
Spring is the most popular application development framework for enterprise Java, that provides an incredibly powerful and flexible collection of technologies to improve your enterprise Java application development that is used by millions of developers.
Some of its advantages are:
- Lifecyle for overriding binding, validation, etc.
- Integrates with many view options seamlessly: JSP/JSTL, Tiles, Velocity, FreeMarker, Excel, PDF
- Inversion of Control makes it easy to test
- Advanced security
- Advanced support for Aspect-Oriented Programming (AOP)
Many mission-critical Java enterprise applications are based on the Spring framework. Although you can integrate JSF (even Seam) with Spring, it lacks built-in JSF and AJAX support unlike JBoss Seam.
Java Server Faces
Although JSF is not fairly a new framework, it’s become a Java EE standard (as of Java EE 5), developed through Java Community Process (JCP), that makes it easy to build user interfaces for java web applications by assembling reusable components in a page. Fast and easy to develop with initially, JSF comes with a plethora of ready to use components which you can quickly and easily reuse or add to many times in a page and capture events generated by actions on these components.
JSF is based on the well-established Model-View-Controller (MVC) design paradigm. Applications developed using JSF frameworks are forcibly well designed and usually easier to maintain than others.
Unlike action-based frameworks such as Struts and Spring, JSF applications are event-based. You typically embed components in a web page using custom tags defined by JSF technology and use the framework to handle navigation from one page to another.
JSF offers a flexible and extensible architecture that makes easy creating reusable, complex server side UI components without limiting developers to a particular mark-up language, protocol, or client device by combining the UI component functionality with custom renderers.
Some other advantages of using Java Server Faces are:
- JSF provides standard, reusable components for creating user interfaces for web applications.
- JSF provides many tag libraries for accessing and manipulating the components.
- It automatically saves the form data and repopulates the form when it is displayed at client side.
- JSF encapsulates the event handling and component rendering logic from programmers, programmers just use the custom components.
- There are many GUIs available these days to simplify the development of web based application based on JSF framework.
See my other articles on JSF for more detailed information, tutorials and resources.
JBoss Seam is a framework that brings together existing Java Platform, Enterprise Edition (Java EE) standards to enable them to work as an integrated solution. At its core, the Seam framework ties the Enterprise JavaBeans 3 (EJB3) and JavaServer Faces (JSF) specifications. However, Seam does not just stop there—it will also join together other component models that you may be used to, such as Hibernate (for ORM), jBPM (for business process management and workflows), Drools (business rule management system), and more.
To be useful, your application has to be a multitiered application that uses specific components for the presentation, business, and persistence tiers. Before, you may have accomplished this with a combination of Struts (presentation), Spring (business), and Hibernate (persistence) frameworks. Now, following the Java EE specification, you will be using JSF (presentation), EJB3 session-beans (business), and EJB3 entity beans (persistence) with Seam. As before, each of these components requires lots of glue to link them together to talk to each other where Seam solves all of these.
EJB 2.1 had some negative connotations, especially regarding the way it relates to stateful session beans and entity beans. Thanks to the new EJB3 specification, EJBs have become lightweight plain old Java objects (POJOs) that do not require as much of the “plumbing” as before.
Seam has been designed from the ground up to eliminate complexity at both architecture and API levels. It enables developers to assemble complex web applications using simple annotated Java classes, a rich set of UI components, and very little XML. Seam’s unique support for conversations and declarative state management can introduce a more sophisticated user experience while at the same time eliminating common bugs found in traditional web applications.
Seam 2 introduces the concept of bijection, taken from Spring’s dependency injection feature where objects can be in-jected or out-jected to/from assigned variables using the @In and @Out annotations.
The framework also expands the concept of contexts. Each Seam component exists within a context. The default Seam context, a conversation, can span multiple pages and usually spans the whole business flow, from start to finish. The session context captures all actions of a user until he/she logs out or closes the browser – even across multiple uses of the browser back-button.
One can automatically generate a CRUD (create-read-update-delete) web-application from an existing database using the command-line tool seam-gen supplied with the framework.
Where there are holes in the specifications (for example, limitations in the JSF lifecycle for GET requests), Seam fixes them. And the authors of Seam are working with the JCP expert groups to make sure those fixes make their way back into the next revision of the standards.
Seam facilitates development through the use of JBoss Tools, a set of plug-ins targeted at the open-source Eclipse integrated development environment.
Seam also includes built-in libraries for creation of PDF documents, Microsoft Excel worksheets, graphs / charts (independent from Excel) and emailing them.
The possibility of integrating Seam with Spring might make it the ideal choice for developers who are also keen for making the switch to JSF.
Although Tapestry and Stripes might deserve a mention, I purposefully omitted them in this article as I don’t believe they’re in the top 5 java web frameworks. Tapestry with its HTML-based templates is almost as old as Struts, very productive once you learn, but with its scarcity of learning resources and steep learning curve, every adopter chooses – sooner or later – to switch to something else. As for Stripes which could deserve mentioning for its convention over configuration (no XML) and good documentation, has some major drawbacks such as the size of its community being too small, and it’s not actively developed as other projects.