Choosing Development Tools

Some aspects of J2EE development require tools. Tools for J2EE development are getting better, but many still fall short of their Microsoft counterparts. However, Java development - and, to a lesser extent, J2EE development - does not usually require heavy dependence on tools. Generic tools such as a good XML editor can simplify the editing of deployment descriptors and reduce the likelihood of errors. With EJB - and specifically, CMP entity beans if they are used - J2EE-specific tools become necessary rather than merely helpful. Automatic generation and synchronization of the multiple files required for implementing each EJB is helpful, as is generation and maintenance of deployment descriptors. It's possible to handle the Java files and write deployment descriptors manually if you are using only session EJBs and web components. However, EJB 2.0 CMP entity bean deployment descriptors and some server-specific deployment descriptors (again, usually where CMP entities are concerned) are far too complex for manual authoring.


Note that tools don't equate to IDEs. Many lower-tech script-based tools are often highly effective in J2EE development.

Let's survey some of the main types of tools that can be used for J2EE development. This discussion reflects my own experience and opinions; this is an area where there are many alternative approaches.

Visual Modeling Tools

At the slickest end of the tool spectrum are visual modeling tools with the ability to generate J2EE code, such as Together. These products are often expensive. Personally, I don't use them, although this is a matter of preference, and I know some excellent J2EE architects and developers who do. I do sometimes use visual modeling tools for their UML support (including code generation from a visual model), rather than J2EE-specific extensions. As UML modeling tools aren't tied to J2EE, they're not strictly relevant here.

Web-tier components and session EJBs aren't very different from ordinary Java classes, and hence don't require special tools. I tend not to use entity beans. When I do use them, I don't use object-modeling tools to generate code. As we shall discuss in , driving entity bean design from an object model can produce disastrous results as far as relational databases are concerned (the most common case today). Integrated visual modeling and J2EE code generation tools make this design approach dangerously easy. Their very slickness poses the threat that developers are unlikely to question the underlying approach. Inexperienced developers can easily use such tools to generate code quickly without really understanding it - a recipe for future problems.


Although many organizations standardize on a single IDE, I feel that individual developers should be left to choose the IDEs they are familiar with. IDEs are a poor repository for project configuration, and developers often have strong likes and dislikes that should be respected. Some developers remain passionately committed to their favorite text editors, although today's Java IDEs are so good that this is hard to justify (I became convinced of this a few years ago, when I said goodbye to vi and TextPad). In GUI development, a particular IDE may legitimately become critical to the development process: for example if it offers particularly strong "form" building functionality. With server-side development, there tends to be less Java code that's tedious to generate by hand, removing this argument for IDE standardization. I recommend considering support for refactoring when selecting an IDE. This saves a lot of time and promotes good practice (we'll discuss refactoring in ). Eclipse (, a free open source product, is particularly good in this respect. Eclipse provides automatic support for:

Build Utilities

A major problem with IDEs is that their use can't be scripted. Thus, actions can't be placed under version control and can't be repeated predictably. It may be possible to check in project files, but project files are IDE-specific and may use binary formats. Also, some tasks cannot be performed easily by any IDE. This creates a serious problem if a particular IDE is the definitive project repository. It's impossible to succeed in a J2EE project without an efficient repeatable way of building all project artifacts. Basic tasks include:

More advanced tasks include:

All these tasks can be accomplished using Another Neat Tool (Ant), now the de facto standard mechanism for Java build scripts. Ant is an open source tool from the Apache project, available at Ant shares many concepts with make, although it is XML based and uses Java, and not shell scripts. An Ant task corresponds to a make target, but Ant is more intuitive, and offers better cross-platform support and much better Java-oriented functionality. Ant's benefits include:

Ant is used widely in commercial and open source projects, so it's essential for any professional Java developer to understand it. Ant can be used for many tasks other than simply building source code. Optional tasks (available as an additional download from the main download site) support building WAR, EJB, and EAR deployment units. I never type in a classpath if there's any likelihood that I will run the command again: I create an Ant build.xml file or add a new task to an existing build file for every Java-oriented command, no matter how small. This not only means that I can immediately get something to work if I return to it later, but also that I can comment anything unusual I needed to do, so I won't waste time in future (I even used Ant to back up the source code and documents composing this tutorial).


If you aren't familiar with it, learn and use Ant. Continue to use your favorite IDE, but ensure that each project action can be accomplished through an Ant target. Spend a little time upfront to write Ant build files and reap the rewards later. See for guidelines on using Ant effectively.

Code Generators

There's little need to auto-generate code for ordinary Java objects and web-tier classes. However, the many artifacts required in EJB development made code generation tools attractive, especially where entity beans are concerned. EJB code generators are lower tech compared to IDEs, but can be very effective for EJB development. As discussed, it's impossible to produce and maintain all the required deployment descriptors (both standard and vendor-specific) manually if we are using CMP entity beans. The following free tools use special Javadoc tags in EJB bean implementation classes to drive generation of other Java required source files (home and component interfaces) and deployment descriptors for several servers. Unlike an IDE "EJB Wizard", this is a scriptable approach and is compatible with any IDE or editor.

An alternative EJB code generation approach is to define the necessary data in an XML document, enabling use of XSLT to generate the multiple output files required. Again, this is really only necessary for handling the complexity of entity bean CMP. One of several such products is the LowRoad code generator from Tall Software (

Version Control

It's vital to have a good version control tool; along with a good build tool such as Ant, a version control system is the cornerstone of every successful release-management strategy. CVS is widely used in the open source community and provides a reliable basic level of functionality. Several simple, free GUIs integrate with CVS (the best I've seen is WinCvs, available from, although there are also some platform-independent Java GUI clients). Popular IDEs like Forte and Eclipse also provide CVS integration. Any professional organization should already have a version control system in place before undertaking a complex development project such as a J2EE enterprise solution.