home 
 
 
 
nlfr
 
Home
About ABIS
Services
Courses
Resources
Contact
MyABIS
C
What is available?ABIS Infor » 2017-09 » 2017-01 » 2016-11 » 2016-06 » 2016-04 » 2016-02 » 2015-03 » 2014-03 » 2013-04 » 2013-01 » 2012-10 » 2012-06 » 2012-04 » 2012-01 » 2011-11 » 2011-10 » 2011-08 » Java Frameworks - Can you see the wood for the trees? » MySQL: new features since version 5.0 » The pillars of our services » SAS and the adaptation to the RDBMS world » TOGAF » 2011-06Exploring Db2Presentations and papersTest your knowledge 

ABIS Infor - 2011-08

Java Frameworks - Can you see the wood for the trees?

Sandy Schillebeeckx (ABIS) - 30 June 2011

Abstract

Ever heard of the french expression "L'embarras du choix"? That's actually the first thing that came to mind when I started to dig into the multitude of Java frameworks that are available these days. So how do you choose the right one(s)? Is it even possible to state which is THE best?
In this article I will present an overview of some of the most popular Java Frameworks and give guidelines on how to choose one.

What's the problem?

Suppose you want to build a new web application, with a database in the back (a shopping cart application for instance), and you want to develop the whole thing in Java. A lot of requirements come to mind: it has to do its job (duh!!), but you also have to worry about scalability, availability, performance, security... And of course, maintainability.

As a quote by Martin Fowler says: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand".

You also have to take into account that the design can change, extra features are asked to be added,... . So you thought ahead, and you are nicely going to layer your code and separate the concerns.

But then what...

You could stick to the basics: pure JSPs and servlets for the web frontend and JDBC for the link with the database. However then you're in for much more than just coding the business logic. You will end up with a hard to read program filled with boilerplate code. Unless you've noticed that you could separate that kind of code out, making calls upon it... Congratulations, you've probably reinvented one of the existing frameworks, or even added a new tree in the wood...

So wouldn't it be better to use a framework from the start? They are designed to take a lot of the burden off of your shoulders, help you in writing nicely layered code. The only thing you should worry about is the real business code. Great, isn't it?

The Java framework landscape

Java frameworks span everything from the simplistic to the entirely comprehensive. Some frameworks, for example frameworks concentrating on user interface development, web applications, or persistence, are tightly focused. Others take a more "holistic" approach, providing benefit to many different areas of an application's development efforts.

One of the best web sites where you can find an overview of available (open-source) frameworks is http://java-source.net/.

You will find around 60 web frameworks, 40 persistence frameworks and 20 Java EE frameworks. A lot, don't you think?

Some of them will sound familiar if you have been in the Java business for a while, like Hibernate, JPA, iBatis (myBatis), Spring, JSF, Seam, Struts and EJB. Maybe also names like JDO, Wicket, Tapestry and WebWork ring a bell. But did you ever hear of Barracuda, Macaw, Sombrero, Smyle or Mr. Persister?

General considerations in choosing a framework

There are many different opinions on how to choose the right framework. Approaches used to select frameworks include:

But that's not all. You're probably not the first to develop an application in your company, and you won't be the last. And of course you hope that your application will stay in production for ages.

Companies are a lot like people (or governments). Each has its own character or style. Some are like dictators, they will decide for you which technology/framework to use (in which case you probably wouldn't bother reading an article about the comparison of frameworks). Some are conservative, they stick with the known and won't go with a new technology until they're sure that it will last forever. Others closely follow all new developments (like people that buy a new phone every 3 months).

Both of the latter have there pros and cons. The conservative type will mostly be assured that their application will stay maintainable later on. But they will miss out on a lot of better/nicer features. The eager type will have those nice features, but may end up following just a hype, and will be forced to rewrite their code more often. On the other hand if they bump into the correct ones, they will be the rich guys in the end.

Also the kind of project and its dependency with other applications can influence whether you play the conservative or the innovative guy. It's a matter of choosing the right man (framework) for the right job.

Overview of frameworks

In this part I will give an overview of a number of the most well known Java frameworks, where I will sum up some pros and cons that could help you while comparing them to choose the right one. As you will notice, an objective view is hard to give. Whether you like a framework or not is partly a personal taste. There are as many preferences as there are people. And you often tend to compare with the first one you learned (a bit like comparing every partner in your life with your first love).

I will mainly focus on the web frameworks: Struts (2), JSF, Spring MVC/Web Flow, GWT, Tapestry and Wicket. For other, more rich client applications, others could be considered.

A comparison of other (backend + persistence) frameworks will be done in one of the following editions of our newsletter.

Above, I listed some important criteria which can be used to compare frameworks: popularity, support (and community), learning curve, documentation, but of course also technical things like MVC compliance, AJAX support, testing possibilities, security, validation possibilities.

Struts was (one of) the first Java MVC frameworks which came out in 2001 under the Jakarta subproject of Apache. It is mostly controller/action oriented with Actions and ActionForms as some of the main parts. An XML file governs the configuration and flow. Downside of Struts is that the Action components are tightly coupled with Struts. You have to extend the Action class, and the "execute" method takes in HttpServletRequest and HttpServletResponse. You will still see a lot of Struts in existing applications, since it was for a long time the leading framework. But maybe better not to develop new applications in it.

Struts 2 is a major revision of Struts. Actually, it is a combination of WebWork and Struts and came out in 2007. It has taken away some of the burdens of Struts 1, and added a lot of possibilities. But still it mixes action and model. Struts 2 integrates well with Spring.

JSF is a mainly view-oriented MVC framework which came out in 2004. It uses dependency injection for managing and wiring beans. Navigation, actions, validations and conversions are very easy to code. The application code stays clean and the actions are pure Java methods. Nice separation of concerns. Regarding view technology you can choose between Facelets and JSPs, completed with the Expression Language for integration with the model. A lot of predefined view components exists, even more when you consider implementations like IceFaces (in which also partial reloads of pages are foreseen, which increases performance). JBoss Seam can be used to add functionality and requires much less configuration.

JSF is part of the Java EE 6 spec.

Spring is a very large framework which encompasses the whole application (business layer, persistence, web). It integrates well with Struts and JSF, but also has its own MVC framework. It is fully controller oriented (comparable with Struts). Spring 3 has simplified a lot. Actions are once again simple methods, controlled via annotations, giving back Strings which you can use for navigations. It binds the model cleanly in the view.

Google Web Toolkit was first released by Google in 2006. GWT emphasizes reusable, efficient solutions to recurring AJAX challenges, namely asynchronous remote procedure calls, history management, bookmarking, internationalization and cross-browser portability. The GWT SDK provides a set of core Java APIs and widgets. These allow you to write AJAX applications in Java and then compile the source to highly optimised JavaScript that runs across all browsers, including mobile browsers for Android and the iPhone. Very client oriented.

Tapestry 5 (project of Apache) is a component oriented framework for creating dynamic, robust, highly scalable web applications in Java. It is based on simple POJO classes. It also features streamlined templates, live class reloading, state-of-the-art exception reporting, first-class AJAX support, and a big library of built-in components. But it has a steep learning curve and the documentation stays rather conceptual.

Again an Apache project. Wicket seems to make it easy to approach web application design from an OO "mindset". In terms of web development, Wicket avoids the Mark-up <-> Code impedance mismatch by making a clear choice to favour Java over mark-up. It is lightweight. Documentation is not great (there is a lot, but not nicely ordered), but it is easy to learn. It doesn't require any XML configuration.

Conclusion

Choosing THE best web framework is impossible. If you stay in the group of the well known frameworks you're probably safe. Although it is never bad to keep following new technologies (like Play! and Vaadin for example). Frameworks tend to learn from each other and introduce improvements with each version. The best choice will be influenced by the project's goals, the environment, the people involved (and their preferences). So good research is required. But no matter what, it is certainly better than using no framework at all.

 

Several of these frameworks are treated in more detail in the courses of the JAVA-domain (see http://www.abis.be/html/enJAVACalendar.html).