"The Problem is Choice."

Containers, containers, containers. Boy there are a lot! It can be very daunting to figure out what container you need or should use. This page tries to give a fair answer. In my not so humble opinion, you should still do your own evaluation, rather than trust me to have the right answer.

It's assumed you're sold on java, know what a container is, and are otherwise a reasonably experienced programmer.

Decision-making for dummies

This questionairre doesn't take into account a huge amount of choices. It will most likely give you a suboptimal choice most of the time. However, mostly all of the projects (exception: geronimo) referred to are stable projects of rather high quality.

1Do you want or need to use a J2EE-like and/or compatible container?

Yes: use Apache's in-development Geronimo, or JBoss. They're not certified J2EE yet though. If you want something certified by sun, visit their website. Skip to 5.

Yes: use a servlet engine, either Jetty or Apache's Tomcat. Skip to 5.

No/don't know: don't use a servlet engine. Go to 4.

4Do you want to run the container as a standalone (daemon, commandline tool or GUI) program?

Yes: You should evaluate loom. If you pick this, you can skip 5. If not, you'll have to write your own framework(which is not hard). Make sure to take a look at libraries like commons-cli and the java service wrapper to make that job as easy as possible.

No: Go to 5.

5Would you like to use a "framework" that makes some design decisions for you?

Yes: you need to pick one or two. That's the next question.

No: you don't want a container at all. Go away. Do make sure to evaluate every link on this page and others, since you'll want to steal ideas from the container world.

6Are you writing a web application? (ie one that speaks HTTP)

Yes: did you pick a servlet engine? If not, you might want to investigate using an embeddable webserver like simple. Go on to 7.

No: good for you. You can skip a whole lot of container choices! Go to 9.

Feature-based decision-making

Sensible decision-making

Look at that database referred to above and the process outlined above. A few things to look out for:

standards. J2EE, SOAP, HTTP, ISO, Unified process. Figure out which standards matter to you and which projects support what.

project maturity. Take a look at the number of releases made, the number of bugfixes, the documentation, who else is using it.

project activity. Take a look at the bugtracker and the development mailing list. If there's no messages on the developer mailing list, its a bad sign.

developer pool size. Be weary of "one-man codebases". Even with projects with many developers listed as active, some might actually not be. Investigate cvs commit logs and mailing list posting.

licensing and ownership. Is (L)GPL (not) a problem for you, or do you (not) want BSD-style licensing? What about patent clauses? Is the project copyrighted by a company, a non-profit or not-for-profit, or one or more individuals?

user support. Read the user mailing list. Do people provide useful answers to support questions? Evaluate the bug tracker. Do bugs get fixed? How quickly? Is there a track record of fixed bugs?

lock-in. How easy is it to stop using a particular solution and replace it with something else? The easier the better.

and so on and so forth. Lastly...

featureset. What do you need (no, you don't need a fancy persistence framework, AOP, lots of magic)? Do you need transactions, and are they available and easy enough? Do you need to connect to a particular database, and is that easy to do? etc etc.

Comments

The above is currently just the ideas of a single person. Feel more than free to add and correct. If you're not sure you're being objective enough, add your comments below instead of just changing the main text.