A good IDE should provide all the tools and features necessary for developing, debugging, and testing an application. J2EE projects call for an enhanced feature set from the IDE beyond that of conventional J2SE applications. The IDE must contend with multiple file types, additional build steps, deployment concerns, and interaction with J2EE servers. Some products also support the design phase and provide additional modeling features.

Whatever IDE you select, one of the most important selection criteria is whether the product can support the way you work. We have covered software engineering practices that can greatly assist in the rapid development of J2EE solutions. Here is a summary of some of the techniques covered:

The ideal IDE should support us in applying these techniques and working with the products and frameworks listed. In addition, the IDE must also be J2EE-specific and have built-in support for all the J2EE artifacts we are likely to work with.

So, what can we reasonably expect an IDE to provide beyond a standard code editor? The following lists some of the core features an IDE should offer for J2EE development.

These features are in no way a comprehensive list, and we should expect to see most IDE vendors providing development productivity features that add additional functionality to the workbench. Such additional functionality might include metrics-gathering, code quality analysis, and profiling support.

To showcase the features we would expect to find in an IDE targeting J2EE projects, the remainder of this chapter concentrates on the Eclipse IDE.

Eclipse is not strictly an IDE but is instead a generic Java-based platform for hosting development tools. The Eclipse Platform uses pluggable tools to build IDEs for supporting the development of a range of applications using a diverse set of technologies. The base Eclipse platform provides the functionality to detect, load, and integrate different development tools known as plug-ins into an Eclipse workbench. Collectively, these plug-ins form an IDE for a specific development technology, for example, Java, Smalltalk, or C++.

Eclipse’s pedigree can be traced back to IBM. In producing tools for the IBM range of development products, the project teams at IBM found themselves continually producing IDEs from scratch for each new product. Recognizing this approach as wasteful in both time and effort, IBM focused its attention on developing a generic IDE platform that could be tailored for each new product. The Eclipse Platform was the result of this effort. IBM then contributed the source for the platform to the open source community and established and funded the Eclipse Foundation to encourage the development of the platform.

In its basic state, Eclipse is too generic for developing applications. To make Eclipse usable, the download comes complete with Java Development Tooling (JDT), a collection of tools targeted at the development of Java applications. The JDT provides the Eclipse Platform with all the features necessary for developing, running, testing, and debugging Java applications. In this chapter, we look at additional plug-in tools for supporting the development of J2EE solutions.

The Eclipse Web site is located at http://www.eclipse.org. This site provides the news on the Eclipse platform, articles, documentation, and the latest versions of Eclipse ready for download. The full Eclipse download comes complete with the JDT, so Eclipse is all ready to go for Java development.

For the installation, you may either pick up the designated formal release or take a build from the current development stream. Certain development builds are periodically flagged as being stable, so if you want to see all the latest features, then go for one of these. However, if you’re new to Eclipse, you may wish to download a reliable formal release.

Eclipse is downloaded as an archive and extracted into an appropriate local directory. On a Microsoft Windows platform, launch Eclipse using the eclipse.exe executable.

Although Eclipse runs directly from this file, it is advisable to set a few configuration parameters before starting the IDE. Specifically, you can tell Eclipse the JVM to use with the -vm flag. Explicitly stating the JVM is useful for machines with multiple JVM versions installed and avoids problems when upgrading to new versions of the J2SE platform.

Here is an example of the command line for running Eclipse with this option set:

eclipse.exe -vm c:jreinjavaw.exe

You can set the option on the Windows platform by creating a desktop shortcut and providing the additional command-line arguments.

Note that the setting of all these parameters is optional and serves purely to enable the customization of the Eclipse platform for your specific environment. Eclipse runs perfectly well straight out of the box.

Eclipse adopts the concept of a user’s workspace for managing applications under development. A workspace comprises a series of projects, and each project maps directly to a directory on the file system. Under a project directory resides all the source files for building a specific application or component.

Within a workspace, dependencies can be expressed between projects that govern build order. This makes workspaces an effective mechanism for organizing applications and allows large systems to be broken down into smaller subprojects.

From version 3.0, Eclipse supports the use of multiple workspaces and allows you to create a new workspace or select an existing one at startup. Alternatively, the location of the workspace can be passed to Eclipse on the command line with the –data argument. For example, eclipse –data c:myprojectworkspace.

Developers interact with Eclipse using the workbench paradigm, which is based on the concept of editors, views, and perspectives:

An example of an editor and a view is the Java source editor and the accompanying outline view. Here the outline view displays the structure of the Java class open in the editor.

Perspectives are a common source of confusion when learning the intricacies of Eclipse, since they are a concept not normally found in IDEs. Essentially, perspectives are a convenience for organizing editors and views according to a logical grouping, such as Java development or debugging.

Figure 13-1 shows the Eclipse workbench with a Java file open for editing. In addition to the editor, three views are visible in the perspective: the package explorer, which shows the Java project’s package structure; the outline view, which provides an at-a-glance overview of the methods and attributes of the class being edited; and the console, responsible for displaying all output.

Figure 13-1. The Eclipse workbench.

Perspectives can take a little time to become familiar with, but after some experimentation, you’ll find them a useful way of organizing the workbench.

The ability to tailor an IDE for a particular environment with custom plug-in tools is an important feature. The Eclipse Platform takes the use of plug-ins to the extreme and relies on plug-ins to provide the workbench with the development features required for a particular language or technology.

Plug-in tools are both the Eclipse Platform’s main strength and its Achilles’ heel. Heavy reliance on modular development tools makes the platform infinitely extendable and customizable. On the downside, the use of multiple tools can lead to integration problems, with badly behaving plug-ins causing instability within the workbench. Such instability, if it occurs, is extremely frustrating, especially as reliability must rank as one of the top requirements for an IDE.

When selecting a plug-in, you should determine the version of Eclipse the new tool supports. Tool versions that target a formal Eclipse release are likely to be more stable than those targeting a milestone, and hence a beta, version of Eclipse—user beware!

Numerous plug-in tools are available for the Eclipse Platform, with a highly active Eclipse community engaged in the development of both open source and commercial tools. The teams involved in tool development are required to “commune” away from the main Eclipse site. Sadly, this can make tracking down appropriate plug-ins difficult.

Two sites that carry an extensive list of tools are http://www.eclipse-plugins.info and http://www.eclipseplugincentral.com. Each of these resources provides searching facilities and sorts plug-in tools by category. The sites also rank each tool according to activity and download rate, making it easy to see which tools developers are actively using.

This chapter introduces a number of tools for enhancing Eclipse for performing J2EE development tasks. Table 13-1 gives a selection of popular open source and commercial tools available for the workbench.

The next section looks at the features of an IDE necessary for supporting J2EE projects.

Code wizards rely on passive code generation to generate much of the boilerplate code associated with the task of programming. They offer a significant saving in terms of time and effort.

To take advantage of the productivity gains passive code generation affords, it is worthwhile selecting an IDE that provides code wizards for some of the more common J2EE operations.

The base JDT provides wizards for generating common Java artifacts such as classes and interfaces. Installing MyEclipse enhances the Eclipse workbench with an additional set of wizards that target J2EE components.

The wizards available include project-level wizards for generating Web applications (WAR), EJB components (JAR), and enterprise application (EAR) deployments. MyEclipse also adds wizards for generating code-level artifacts, including support for generating the following:

Figure 13-2 shows the MyEclipse EJB Wizard, used for generating XDoclet based EJB components.

Figure 13-2. MyEclipse EJB Wizard.

The EJB wizard provided by MyEclipse is template based. From the templates available, enterprise bean types of session, entity, and message-driven beans can be autogenerated. Note that the code generated is XDoclet based, and the code wizard generates a single bean implementation adorned with XDoclet annotations.

The editor is the tool around which the workbench revolves. A powerful code editor contributes immensely to developer productivity. In this regard, the Eclipse Java editor is very advanced and offers a number of time saving features. As an example, here are some of the features from the Eclipse editor’s source menu that you may find particularly useful.

You should expect most Java development tools to offer similar time saving features.

J2EE applications require editor support for file types other than Java source. A typical J2EE project could comprise the following:

The editor should help us to quickly and accurately write files of all these types and should afford features such as context-sensitive help, syntax highlighting, and code assist (sometimes called code completion).

The plug-in model of the Eclipse platform makes it ideally suited for dealing with the various file types of J2EE projects. One primary file type not directly supported by Eclipse is JSP. Here, the MyEclipse plug-in adds JSP editor support, providing code assist and syntax highlighting features, and allows the JSP to be syntax-checked and previewed prior to deployment.

A prerequisite for any IDE is its ability to integrate with Apache Ant for performing build tasks. An IDE is an unsuitable tool for constructing a reliable and repeatable build process because most development platforms lack the functionality to cover all of the eventualities required of a build system. For the majority of projects, the Apache Ant build utility is used for this purpose. In order for an IDE to integrate with the build process, it must be able to invoke Ant build file targets directly.

The ability to integrate an Ant build file into the IDE is especially significant if code generation tools such as AndroMDA and XDoclet form an integral part of the build process, as these tools require Ant for invocation.

The Eclipse developers recognize the importance of Ant’s role in Java software engineering and ensure that Ant is well supported by the Eclipse workbench. No additional plug-in is required to support Ant integration.

Figure 13-3 illustrates the Ant view, which forms an integral part of the Eclipse workbench.

Figure 13-3. Eclipse Ant build file view.

The Ant view lists all targets in a build file. Build targets can be invoked directly from the workbench using the Ant view. All output generated by Ant is written to the Eclipse workbench’s console.

For writing build files, the Eclipse workbench comes with an Ant file-aware editor, which can be associated with all XML file types and provides syntax coloring and code assist for Ant tasks.

This level of integration with Ant makes it possible to write and run build files within the confines of the Eclipse workbench, thereby providing a single environment for project development work.

If a project is using a code generator, then the chosen IDE should both integrate with the code generator and work with the generated code.

A major criterion for integrating the IDE with a code generator is the ability of the IDE to invoke the generator by executing targets in an Ant build file. As we learned in the previous section, Eclipse is very accomplished in this area. Furthermore, the IDE should be able to contend with multiple source paths, because it is good practice to output generated source to a different directory than that of handwritten code. This is possible with Eclipse because Java projects may define multiple source paths.

Velocity Templates

For working with template-driven code generators, it is desirable for the IDE to provide support for editing the template files. An open source editor for Velocity templates is available for Eclipse. The plug-in Veloedit can be downloaded from http://veloedit.sourceforge.net.

Figure 13-4 shows Veloedit editing an AndroMDA cartridge template. The editor supports both syntax highlighting and code assist for Velocity files.

Figure 13-4. Editing a Velocity template with Veloedit.

Velocity is becoming widely used for code generation, so the Veloedit plug-in enjoys a high number of downloads—currently, about a thousand downloads a month, which is a significant amount.

XDoclet

The MyEclipse plug-in makes extensive use of XDoclet for generating J2EE components. As we have seen, the EJB wizard generates a bean class annotated with XDoclet attributes.

MyEclipse extends the workbench to ensure XDoclet is well supported and adds code-assist support to the editor for the embedded XDoclet tags. Execution of the XDoclet engine for a MyEclipse project is controlled by a project Ant build file named xdoclet-build.xml. The contents of this build file should not be edited directly. Instead, MyEclipse associates the XDoclet settings with the properties of the EJB project. These properties can be accessed by right-clicking on the project and selecting the Properties menu item. Figure 13-5 displays the various XDoclet properties dialog used for controlling code generation in the project.

Figure 13-5. Setting XDoclet properties with MyEclipse.

warning

The setting for the destDir attribute that specifies the location of generated source defaults to the same location as the Java source directory.

Accepting this configuration would see generated source mixed up with handwritten code. In line with code generation best practice, you should consider changing this setting to a directory dedicated to holding the generated source. Add this new directory as a source path to your Eclipse project.

Having established a suitable configuration, the XDoclet build script is run via a MyEclipse menu item, available by right-clicking on the project in the package explorer view.

To operate as a fully integrated environment, the IDE must have the capability to deploy J2EE applications. It should also offer the functionality to control the target J2EE server, allowing the developer to start and stop the server without the need to leave the IDE.

Eclipse relies on plug-in tools for incorporating this functionality into the workbench. For deployment, MyEclipse adds a deployment wizard to the workbench that enables J2EE modules to be deployed to a number of J2EE server types. Figure 13-6 shows the MyEclipse deployment dialog with a J2EE EAR project selected. The packaged application targets instances of the JBoss and WebLogic servers. For each server selected, you may specifying the deployment type. From the example deployment setup in Figure 13-6, an exploded deployment is specified for WLS, while for JBoss the application is deployed as an EAR file. The type of deployment selected depends on what the application server supports.

Figure 13-6. MyEclipse J2EE project deployment dialog.

MyEclipse allows J2EE servers to be configured within the IDE and adds toolbar items to enable each configured server to be started or stopped from within the Eclipse workbench. This level of integration between application server and IDE provides for the rapid transition of newly written code into a running state, where it can be tested and debugged.

Eclipse’s use of plug-in tools enables the integration of UML modeling tools into the workbench. A number of modeling tools are available as Eclipse plug-ins. Omondo offers Eclipse-UML, available from http://www.omondo.com. In addition, Borland produces an Eclipse modeling tool as part of its Together family of products; see http://www.borland.com.

Modeling tools generally add their own perspective to the Eclipse workbench. Switching between the modeling and Java perspectives offers a convenient means of moving from model to code, and vice versa. This approach ensures the model is closely associated with the code, thereby helping to prevent the model from being neglected as development progresses.

Few J2EE solutions are constructed without an underlying data repository; most enterprise systems use a relational database.

One area where many IDEs are still trailing the best-of-breed tools is in database support. Few. if any, IDEs offer the same level of functionality as specialized database tools such as DBArtisan, ERwin, or TOAD. These tools support such features as writing stored procedures and database triggers, generating database performance statistics, and in some cases modeling entity relationships for schema designs. Some IDE products offer limited support in this area. For example, Together ControlCenter can generate ER diagrams reverse-engineered from the database and can generate DDL scripts from an ER diagram.

Although they do not offer the same level of sophistication as the best-of-breed database tools, most IDEs offer some form of database access. A few open source database tools are available for Eclipse. One offering is Quantum DB, a useful query editor that allows the execution of SQL statements and the contents of database tables to be interrogated via a JDBC driver. MyEclipse also includes a tool with similar functionality. Although limited, this simple functionality comes in very useful and can be a great time saver when it comes to checking the results of test runs or preparing test data on the database.

Over time, mainstream database-management products may migrate to the Eclipse platform, making a fully integrated development environment possible.

The Java Platform Debugger Architecture (JPDA) was introduced as of JDK 1.3, enabling a debugging tool to attach to a JPDA-compliant JVM. The JPDA has the debugging tool execute in a separate JVM from that of the application being debugged. This architecture has significant advantages over running a debugging tool in the same JVM as that of the application being debugged. For optimal debugging, it is often necessary to suspend the JVM of the debugged application, a process that is not possible if both debugger and debuggee are collocated in the same JVM.

The JPDA defines two interfaces and a protocol:

Implementations of the JDI and JVMDI interfaces interoperate via two software components, which are imaginatively called the front end and back end in the JPDA documentation. Figure 13-7 illustrates the JPDA debugging model.

Figure 13-7. The Java platform debugger architecture.

A debugging tool submits requests to an attached JVM through the JDI. The front-end component forwards all JDI requests over the communications channel in accordance with the JDWP. The receiving end of the communications channel is the back-end component, which translates JDWP packets and submits them to the JVMDI of the JVM. The entire process is bidirectional because the JVM being debugged must be able to report events back to the debug tool, for example, when a breakpoint is triggered.

The function of the back-end and front-end components is similar to the approach used for marshaling RMI calls and so should be familiar.

JVM Debug Configuration

The details of configuring a JPDA-compliant JVM are mostly taken care of for us by Eclipse. However, to take advantage of remote debugging, you must understand how a JVM is configured to support debug tools attaching remotely to the JVM.

JVM configuration is proprietary to the target VM, and you should refer to the documentation for your specific implementation. The following instructions refer to the Sun Java HotSpot VM 1.4.2.

Debug support is enabled in the JVM by providing the arguments -Xdebug and -Xrunjdwp. The -Xdebug argument instructs the JVM to listen for debugging connections. The -Xrunjdwp argument is a little more complicated and is used to configure the transport for incoming debug connections. To start the JVM so that it can accept remote connections, this argument is set as follows:

-Xrunjdwp:server=y,transport=dt_socket,address=8000,suspend=n

The suboptions require some explanation:

• server—if set to y instructs the JVM to wait for connections rather than search for them.

• transport—specifies the transport mechanism.

Options are dt_socket for TCP/IP or st_shmem for shared memory.

• address—port address for the connection.

• suspend—if set to n, the JVM starts in a running state; otherwise, the JVM remains suspended, waiting for a connection.

These settings also need to be provided to the debugger so it can attach to the target VM. Under Eclipse, a remote debugging configuration is created for this purpose. Figure 13-8 shows the Eclipse dialog for configuring remote debugging for an application.

Figure 13-8. Eclipse configuration dialog for remote debugging.

The Eclipse dialog makes it easy to configure remote debugging once the target VM is set up correctly. The dialog shown offers a single connection type of socket for the transport. The connection properties specify the host machine name, and the port the target VM listens for incoming connections.

Now that we’ve covered the basics of the JPDA, let’s look at the features Eclipse, with some help from MyEclipse, provides for debugging J2EE solutions.

With JPDA support, Eclipse lets us set breakpoints in J2EE components that are under the control of the J2EE server. Thus, we can break in on the execution of components such as servlets and EJBs to observe their behavior in an executing state. Moreover, if the source is available, we can debug the implementation of the J2EE server itself.

JPDA-compliant debugging tools remove the need to scatter log messages, shotgun style, throughout the code, and provide a superior level of diagnostic reporting than is possible with the use of logging and console messages.

To debug a servlet under Eclipse involves setting a breakpoint in the editor, then starting the servlet engine and deploying the application. Deployment of the application and the startup of the server can all be performed from within the IDE using the services MyEclipse provides.

With the application deployed and the target server running, accessing the page associated with the servlet from a browser causes the breakpoint to be hit. This triggers Eclipse to switch to the debug perspective, displaying the debugger’s editor and views. Figure 13-9 shows the Eclipse debug perspective with an active breakpoint for a servlet running under Tomcat 5.0.

Figure 13-9. The Eclipse debug perspective.

The different views provided in the debug perspective allow the state of variables to be inspected and the current instruction pointer in the code to be advanced line by line. Figure 13-9 shows the debug, variables, code, and outline views. The debug view displays the processes, threads, and stack frames. The variables view allows the state of all object instances to be inspected. The source being debugged is displayed in the editor, while the outline view shows the code structure. Each represents the state of the code as at the current line of execution.

The inclusion of the Java code editor in the debug perspective allows us to take advantage of another JPDA feature—hot swapping.

The hot swapping feature was introduced with the release of JDK 1.4 and enables code to be modified from within a debugger while executing under a JVM.

Hot swapping technology makes it possible to apply changes quickly, bypassing the normal build-and-deployment cycle, and thereby allowing for a swift resolution to defects within the code.

There are limits, however, to the extent to which changes can be made. The main rule is that the structure of the method cannot be changed, so the method signature, including the return type, is immutable if hot swapping is to work. This type of functionality is also called fix-and-continue debugging.

Hot swapping is implicitly supported by Eclipse and can be used to fix-and-continue code running under a J2EE server that is executing under a JPDA-complaint JVM with dynamic class-loading support. Hot swapping is a feature of the JVM, not the J2EE server.

Following from the example shown in Figure 13-9, where a servlet running under Tomcat is being debugged, changes can be made to the servlet using the open code editor in the debug perspective.

Using the MyEclipse plug-in, the Tomcat server is launched as a remote Java application, and the debugger is attached. Having deployed a Web application containing a simple servlet, a breakpoint can be set in the Java editor. Note the breakpoint does not need to be set in the debug perspective. It can be set in any perspective with the source open in the Java editor. Eclipse automatically switches to the debug perspective when the breakpoint is triggered.

Figure 13-10 shows the presence of the breakpoint annotation in the code editor. The breakpoint can be set by double-clicking on the left edge of the editor, on the line where execution is to be interrupted. Note a mouse-over tool tip is visible in the screenshot to denote the location of the breakpoint.

Figure 13-10. Servlet code with breakpoint set.

With the Tomcat server started from the Eclipse workbench, the Web application deployed, and the breakpoint set, the page associated with the servlet can be accessed from a Web browser.

Loading the page in the browser triggers the breakpoint, and the Eclipse debugger is activated. Within the body of the method, any line of code under or ahead of the breakpoint can be changed. Once a modification has been made, the action of saving the file has Eclipse load the changed class into the target VM. Resuming the execution of the application from the debugger executes the changed code and the changes are immediately visible in the browser.

Earlier, we discussed the need for an IDE to support various file types in order to be suitable for J2EE development. The ability to work with a variety of file types applies equally to the debugger as to the code editors.

Under JDK 1.4, JPDA has been extended to support the debugging of languages other than Java. This ability is addressed by JSR-045, Debugging Support for Other Languages.

JSPs benefit greatly from this advancement, making it possible to set breakpoints and inspect the running state of a JSP as if it were Java code.

A plug-in such as MyEclipse is required to support this functionality on the Eclipse workbench. However, the process of running a JSP under the debugger is identical to that of debugging Java components such as servlets and Enterprise JavaBeans.

This section offers some suggestions to help you get the most out of the debugger. The techniques described all rely on standard JPDA features found in most debugging tools.

The MyEclipse plug-in was featured in this chapter. However, for anyone interested in open source alternatives, a tutorial on the use of the Lomboz equivalent is available from http://www.tusc.com.au/tutorial/html.

For information on IDEs other than Eclipse, see http://www.jetbrains.com for details on IntelliJ IDEA and http://www.borland.com for Borland’s JBuilder and Together range of products.

These are both commercial products. For an open source product, visit the Web site for the NetBeans IDE at http://www.netbeans.org.