Java-based Web development has been swamped by frameworks of every kind. It has been ages since I saw a Web application being developed without any framework being used. Name it and there’s a Java framework that claims to do it. Actually there might two or three that do the same thing. In this article, I'll take a closer look at the framework approach to development and some of the more popular Java Web frameworks available.
When you start development on a new Web application, you can:
- Build everything from scratch.
- Develop on exactly the same lines as an earlier application, copy-pasting and reusing much of the code.
- Use a framework and build around it.
Building things from scratch has its advantages if you're trying to learn a new technology, but for real life applications, this isn't an option. Doing so eats up time and resources and is a high-risk alternative. I like the second option only if the developers of that earlier project are part of the new one as well. These individuals can provide valuable inputs from their earlier experience.
The third approach is the best of the lot in most cases. Use a framework that has an established way of doing things and where you are just supposed to plug in components to get your application running.
You should try to answer the following questions before you choose a framework:
- Does the framework handle most things that are common to applications of the kind you wish to develop?
- Does the framework have a strong user community to back it?
- How much does the framework cost?
- How steep is the learning curve for the framework?
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. So choose 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 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 people resources. These few people become critical and are the only source of support for others using that framework. Also, with so many quality frameworks available for free, I seriously doubt if anybody will be willing to pay for it.
In all probability, you might have decided to go for a free, open source Java framework. In this space there are some really good options to choose from. The Wafer project is a research project that can help you quickly assess the options available. Based on this assessment, you can decide on the frameworks that you wish to take up for further evaluation.
Some of the more popular frameworks that top of the list of my framework alternatives are:
- Struts is almost the de facto standard for J2EE projects. Struts is an elegant framework that handles the flow of the application and a lot of other routine tasks. Another advantage of using Struts is the ever-growing number of people skilled in using Struts. Many of the popular Java IDEs also provide tools for Struts development, making life even easier for the developer.
- Cocoon is great if you are looking for a framework that has XML capabilities at its core and that makes great use of XML and XSLT. Unlike other frameworks that provide extensions to the core framework that enable XML and XSL usage, XML and XSL are the core of the Cocoon framework.
- WebWork is part of the OpenSymphony set of components and is considered to be a nice and simple framework. WebWork also has some momentum going for it lately, so it is certainly a framework that needs to be considered.
While many frameworks provide their own tags that can make it easier to use the framework, I do feel that the best option is to stick with JSPs that use the JSP Standard Tag Libraries (JSTL). The other options don’t offer enough flexibility and JSTL—being a standard—will have more widespread acceptance. Java Server Faces is another interesting development that needs to be explored. Although it won’t replace the frameworks, it should change the way developers use custom tags.
The Model View Controller pattern-based Java frameworks hold a lot of potential to make the developer’s life easier, their development time faster, and their application more maintainable. So the time invested in deciding on the framework to use will be well spent. But ease of use, strong user community, tool support, and widespread acceptance makes Struts the best option as of today.