Chapter 13. The Integrated Development Environment

The best craftsmen insist on the best tools. Craftsmen know producing quality work requires having the right tools and the expertise to use them effectively.

The software engineer has the same needs as the craftsman, and the right tools, coupled with the knowledge and skill necessary to use them, are essential ingredients for the rapid development of quality software. This chapter focuses on the importance of integrated development tools and covers the features a tool should offer to assist the software engineer in the task of developing J2EE solutions. It introduces the Eclipse platform as an example of an integrated development environment (IDE) and discusses the features a tool should provide to assist in the development of enterprise-level software for the J2EE platform.

Eclipse is covered because it fits the criteria of being open source. There are many other effective development tools available, such as JBuilder, IntelliJ IDEA, and NetBeans. Each offers a range of powerful features for software development. The concepts described using Eclipse are representative of the functionality you should look for in similar tools.

In addition to examining the benefits of IDEs for rapid development, we discuss how an IDE makes it possible to debug J2EE applications with the Java Platform Debugging Architecture (JPDA) and how this architecture supports the use of advanced techniques such as remote debugging and hot swapping.

Why Use an IDE?

A fully integrated development environment is the ultimate toolbox for the software engineer. It combines all the tools necessary for producing software applications into a single, self-contained environment.

Having all tools under one roof provides a workbench for development; integration between tools such as the editor, compiler, and debugger enable code to be quickly assembled, syntax-checked, and debugged. This close integration of toolsets makes for a rapid development environment and avoids the need to work with different and disjointed development tools.

Despite the advantages of toolset integration, an IDE is not mandatory for software development. You can produce applications with a good code editor like emacs from GNU and an Ant build file. In the past, a valid alternative to the services of an IDE was to take a best-of-breed approach to development tool selection and create your own toolbox of top-of-the-line development tools.

The best-of-breed approach has merit, but as IDEs have matured, the tools provided in an IDE now match many of the features of these standalone tools. Moreover, the synergy afforded by having the tools integrated makes them far more effective than when used in isolation.

In the upcoming sections, we examine what features we should expect our chosen IDE to provide for effective J2EE development.

IDE Core Features

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:

  • Use of multiparadigm development languages such as Jess, Jython, and AspectJ

  • The importance of frameworks

  • Modeling techniques with UML diagrams

  • Active and passive code generation with tools such as Velocity, XDoclet, and Middlegen

  • Transparent data access with O/R mapping products

  • Model-Driven Architecture using AndroMDA

  • Incremental build processes with Apache Ant

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.

  • Language-aware editors.

    Support for syntax coloring for different languages in code editors was seen as a major step forward in editor functionality when it first appeared. Now syntax coloring is an expected feature. A good editor should intrinsically understand the language it supports, offering such features as code assistance, instant error detection, source formatting, and essential refactoring capabilities.

  • Code wizards.

    Passive code generators can remove much of the drudgery from development tasks. The IDE should provide wizards and code templates for standard tasks such as creating Java classes and Enterprise JavaBeans. Code wizards that allow code for common design patterns to be laid down are a powerful feature in any IDE. In addition, an IDE should support customized wizards implemented by the development team.

  • Debuggers.

    The ability to inspect code in a running state is an effective means of investigating defects and understanding the behavior of the executing code. For a J2EE project, debugging support is also required for languages other than Java, with JSP being toward the top of the list. Support for debugging—and remote debugging particularly for J2EE servers—is an important feature of an IDE supporting a J2EE development.

  • Deployment.

    To test and debug a J2EE application, it must be packaged and deployed to a J2EE server. The IDE should support this package-and-deploy phase and allow the execution of the target server to be controlled from within the IDE. Control of the server involves not just startup and shutdown, but also having the server executing in a state whereby the deployed application can be tested and debugged.

  • Integrated help.

    Quick access to the help on any of the various APIs that make up the J2SE and J2EE specifications removes the need to go hunting through the documentation for the semantics of a particular API call. This feature is an immense time saver and assists the software engineer in selecting the most appropriate features from the API for the current task.

  • Refactoring support.

    Refactoring code has become a watchword for agile development. Refactoring patterns must be applied consistently across the entire code base. An IDE should support a number of refactoring options, allowing the sweeping changes refactoring calls for to be applied consistently and accurately.

  • Source control integration.

    The use of a source control system, such as CVS, is fundamental to any software development project. An IDE must be able to work seamlessly with your choice of source control repository.

  • Testing.

    A fully integrated development environment should support the unit testing of components. The ability of an IDE to autogenerate unit tests, run test suites, and report on the success of test runs has gained significant attention since the rise of the XP-style test-driven approach to development.

    Note

    The use of an IDE for unit testing is covered in Chapter 14.

  • Reliability and accuracy.

    Finally, no matter how long the feature list of an IDE, it must provide a robust platform for development. Few things are more frustrating than losing work due to an unreliable editor.

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.

Introducing Eclipse

The argument as to which is the best IDE for Java development can reach religious fervor, and most software engineers have their own particular favorite. This chapter features Eclipse because it meets the criteria of being open source and offers most of the features necessary for a productive development platform.

It is also very popular with the Java development community and one of the slickest-looking Java development tools around—a factor which, in combination with its free status, may account for its huge popularity.

What Is Eclipse?

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.

Installing and Running Eclipse

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.

note

Because Eclipse is a Java application, you must have a suitable JVM installed. Eclipse works with multiple versions, but check the site for details.

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.

tip

You can specify several parameters on the command line for optimizing the JVM to squeeze out extra performance from Eclipse. You may find the following settings result in Eclipse starting up considerably quicker on your system: - vmargs -Xverify:none -XX:+UseParallelGC -XX:PermSize=20M -XX:MaxNew-Size=32M -XX:NewSize=32M -Xmx256m -Xms256m.

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.

The Eclipse Workspace

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.

warning

The build constraints imposed by an IDE may prevent the implementation of your desired project structure. It is necessary to ascertain how an IDE organizes its directory structure and determine if the structure will scale to enable large project teams to work effectively.

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.

The Eclipse Workbench Paradigm

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

  • Editors allow the opening, modifying, and saving of files.

  • Views present additional information on the object being worked on within the workbench.

  • Perspectives are an arrangement of editors and views.

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.

The Eclipse workbench.

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.

Extending the Workbench with Plug-in Tools

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.

Table 13-1. Eclipse Plug-in Tools

Name

Description

Reference

MyEclipse

MyEclipse is a collection of tools for J2EE development that transforms the Eclipse platform into a full J2EE workbench.

http://www.myeclipse.com

Lomboz

Lomboz is a comprehensive suite of tools for J2EE development, including EJB wizards and a JSP editor.

http://www.objectlearn.com/products/lomboz.jsp

Exadel Struts and JSF studio

The Exadel tools support the development of Web applications using either the Struts or Java Server Faces MVC frameworks. The tools offer an excellent graphical representation of page flows. This considerably simplifies page navigation configuration.

http://www.exadel.com

Quantum DB

A lightweight but effective database access tool for querying databases and executing SQL statements. Supports syntax highlighting of SQL scripts.

http://quantum.sourceforge.net

Sysdeo

Popular plug-in for controlling the Tomcat servlet engine.

http://www.sysdeo.com/eclipse/tomcatPlugin.html

Veloedit

Velocity template editor with syntax highlighting and code assist.

http://veloedit.sourceforge.net

Hibernate Synchronizer

This plug-in supports the Hibernate O/R mapping tool, and automatically generates Java source when the Hibernate mapping files are changed.

http://www.binamics.com/hibernatesynch

JadClipse

Brings JAD support to the workbench, allowing Java classes to be decompiled from bytecode and viewed as source.

http://sourceforge.net/projects/jadclipse

XMen

XML editor.

http://sourceforge.net/projects/xmen

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

IDE Features for Enterprise Development

The tools of the JDT provide a comprehensive range of features for supporting the development of Java applications. In a nutshell, the JDT supports the following:

  • Organization of Java projects, with each project containing standard Java build artifacts

  • Browsing of Java projects and Java package hierarchies

  • Code wizards and templates for creating Java artifacts such as classes and interfaces

  • A Java-aware editor

  • Refactoring of Java source and packages

  • Full text-based searching capabilities

  • Incremental Java compilation

  • Automated unit testing

  • Integration with Ant files

  • Debugging of Java applications

These features for supporting the construction of Java applications are only a subset of those required for effectively developing J2EE systems. The tools of the Eclipse JDT do not accommodate J2EE components. For this task, the Eclipse workbench requires the installation of plug-in tools that supplement the Java development capabilities of the JDT. Fortunately, a range of Eclipse tools is available for this very purpose.

Two J2EE toolsets that consistently rank toward the top of the active plug-ins lists on various Eclipse Web sites are Lomboz from Object Learn, and MyEclipse from Genuitec. Each product transforms the Eclipse workbench into a J2EE development platform, adding all the wizards, editors, and views necessary for producing J2EE applications.

Lomboz is available as open source. Full details of this tool, including documentation and installation instructions, can be found at http://www.objectlearn.com/products/lomboz.jsp.

MyEclipse is a commercial product, with licenses available on a yearly subscription basis. Surprisingly, for a product aimed at enterprise-level development, MyEclipse does not carry an enterprise-sized price, being relatively low-cost per developer seat. A fully featured version of the software is available for download on a 30-day trial from the MyEclipse Web site. See http://www.myeclipse.com for download details and licensing information.

For our discussion on IDE enterprise development features, the functionality shown uses Eclipse 3.0 with the MyEclipse 3.7 tools installed. The discussion covers the following:

  • Code wizards for generating J2EE program artifacts

  • Working with multiple file types

  • Integration with the build process

  • Using code generators as part of the IDE

  • Integration with the J2EE server

  • Including modeling tool support

  • Accessing the database

Collectively, these features provide a highly productive J2EE development environment.

Code Wizards

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.

Note

Passive code generation is described in Chapter 6.

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:

  • Session, entity, and message-driven beans using XDoclet

  • Hibernate mapping files

  • Web components for the Apache Struts framework

  • Standard Web components such as JSP files, HTML pages, and servlets

  • XML documents and schemas

Note

Chapter 6 covers XDoclet, and Chapter 7 introduces Hibernate.

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

MyEclipse EJB Wizard.

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.

Note

Design options for working with EJB technology are discussed in Chapter 4.

Editor Support for Multiple File Types

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.

  • Organize imports.

    This operation neatly orders all import statements and removes all redundant import declarations.

  • Add import.

    Automatically creates an import declaration for the referenced type.

  • Format.

    Arranges, or beautifies, the code based on a specified layout configuration. Using a common source formatter is a way to ensure compliance with company coding standards.

  • Override/implement methods.

    Code wizard for selecting the methods of a superclass or interface to override or implement. This feature both saves time and increases accuracy by removing the opportunity for inadvertently creating a new method in a deriving class with a typing error.

  • Generate getters and setters.

    This operation removes the tedium of implementing getters and setters for class attributes.

  • Surround with try/catch block.

    Wraps a code selection with a try/catch block and explicitly catches all exceptions types. It also adds import declarations for the necessary exception types.

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

tip

Learning the keyboard mappings for invoking these features without having to resort to pointing and clicking with the mouse makes coding a faster process.

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

  • JSPs, HTML pages, and style sheets

  • SQL scripts

  • Deployment descriptors

  • Property files

  • Velocity templates

  • Ant build files

  • XML documents and schemas

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).

Note

The Apache Velocity template engine is covered in Chapter 6.

note

Code assist, or code completion, is the ability of the editor to display context-sensitive information relating to a particular element in the editor. For example, in the Java editor, a code assist feature would prompt the developer with a list of the available methods for an instance variable of a given type. This functionality is given various names by various IDE vendors. This chapter uses the Eclipse term code assist.

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.

Ant Integration

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.

Note

The Apache Ant build utility is described in Chapter 12.

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.

Note

The MDA tool AndroMDA is covered in Chapter 8.

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.

Eclipse Ant build file view.

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.

Working with Code Generators

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.

Editing a Velocity template with Veloedit.

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.

Setting XDoclet properties with MyEclipse.

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.

Server Control and Application Deployment

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.

note

These integration features require the IDE to keep pace with new versions of the different application servers. You must also check that your chosen IDE or Eclipse plug-in supports your particular application server.

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.

MyEclipse J2EE project deployment dialog.

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.

Modeling Support

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.

Note

Chapter 5 provides an overview of the main UML diagrams and discusses modeling tools.

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.

Database Access

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.

Debugging J2EE Applications with Eclipse

A debugger is one of the most powerful tools available to the developer and can assist immensely for both tracking down defects and helping to understand an application’s core behavior. Despite the benefits debugging tools offer, my experience is that few developers take advantage of these tools and so miss out on one of the biggest productivity gains an IDE can offer. In many cases, the common debugging practice is to adorn the application with strategically placed log messages and examine the output at the console as the application executes.

This method of fault-finding and discovery is workable but is a slow and ponderous means of analyzing code. With a suitable debugging tool, you can set breakpoints within the application and then step through the code from that point on, line by line. With the debugger invoked, a wealth of information is available, the state of threads can be viewed, the contents of variables observed, and the call stack of the application monitored. The ability to replicate this level of information through log messages at the console is highly unlikely. Armed with a full array of information, it is possible to get to the root of a problem quickly and easily.

To understand the full benefits a debugger can offer, this section walks through how this useful tool can be put to best effect on a J2EE solution. First, let’s look at the technology in the JVM that makes debugging tools possible.

Java Platform Debugger Architecture

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:

  • Java Debugging Interface (JDI).

    This interface is used by the debugging tool to make requests and receive notification events from the application being debugged in the target JVM.

  • Java Virtual Machine Debug Interface (JVMDI).

    The JVMDI interface is implemented by a JVM in order to allow the debugging of an application under its control.

  • Java Debug Wire Protocol (JDWP).

    The JDWP ties the two debugging interfaces of JDI and JVMDI together and allows the two interfaces to communicate over a given transport mechanism.

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.

The Java platform debugger architecture.

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.

Note

RMI is discussed in Chapter 4.

Local and Remote Debugging

JDWP is independent of the underlying transport mechanism used to move requests between both ends of the conversation. This independence allows a JVM to be debugged on a machine separate from the JVM running the debugger. This process is known as remote debugging and is achieved by specifying a suitable transport mechanism, known as a transport in JPDA terminology, for carrying traffic between the two machines.

Sun Microsystems’ reference implementation for JDPA provides two transport types: a socket transport and a shared memory transport. The socket transport uses TCP/IP for supporting remote debugging between machines. The shared memory transport supports interprocess communication between JVMs running on the same box.

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.

Eclipse configuration dialog for remote debugging.

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.

Debugging a J2EE Application

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.

note

Logging messages still have their uses, as it is highly unlikely you’ll get the opportunity to use a debugger for tracing faults in a production environment.

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.

The Eclipse debug perspective.

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.

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.

Servlet code with breakpoint set.

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.

note

Hot swapping should not be confused with hot deployment. Hot deployment refers to the ability of a J2EE server to reload updated parts of an application dynamically, without the need to shutdown or interrupt the running application. Hot swapping is a feature of a JPDA-compliant JVM, not the J2EE server.

JSP Debugging

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.

Debugging Guidelines

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.

Check All New Code with the Debugger

A debugger isn’t just a diagnostic tool for locating defects; it can also help improve the quality of your software. In his book Code Complete [McConnell, 2004], Steve McConnell recommends the approach of debugging all new code before it is placed under source control.

This practice allows the developer to confirm the code is operating as designed, rather than passing tests on pure luck. For example, a common code error is to have a loop statement either perform an extra iteration or skip a final iteration. You can verify the correct termination of the loop by using the debugger to step through the loop construct while monitoring the state of the count variable.

Set Conditional Breakpoints

A conditional breakpoint is triggered when an expression associated with the breakpoint evaluates to true. This is a common feature of most debuggers and is especially useful when tracking down problems that do not occur on the first run through of the code.

In the example of an error you suspect is occurring on exiting a loop, rather than stepping through every iteration of the loop, have the breakpoint triggered by providing an expression for the breakpoint that sees the debugger interrupt execution when the loop’s exit condition is reached.

Conditional breakpoints are set in Eclipse by right-clicking on the breakpoint and selecting its properties from the context menu. You can set a condition for the breakpoint in the resulting properties window.

Use the Watch Functionality to Monitor Specific Variables

The debugger can display so much information about the state of the executing program, it becomes difficult to monitor those variables that are of interest. In this situation, using the watch functionality enables the placing of specific variables in a separate view where they are easily observed.

To do this in Eclipse, with execution of the program suspended in the debugger, highlight the variable and right-click to bring up its context menu. Selecting Watch from the menu adds the variable to the Expressions View.

Modify the State of Variables for Testing Purposes

With execution of the program suspended at a breakpoint, you can use the debugger to change the value of a variable. You can use this feature to turn the debugger into a testing tool by setting a breakpoint on entry into a method and then populating the method’s parameters with test data.

Modifying the program’s internal state at runtime is useful for test scenarios for which test data is not readily available.

To modify a variable in the Eclipse debugger, double-click on the variable in the Variables View. This displays a dialog box from which you can enter a new value.

Explore the Code by Stepping Into and Out of Methods

In addition to stepping through code line by line, you can step into a method. This approach allows you to burrow down into the depths of the application to determine its inner workings. The approach is particularly useful when exploring other people’s code, as would be the case on an XP project where code ownership is discouraged.

When you have gone deep enough into the code base, to step back out, use the Step Return debug menu command. This returns you to the calling method and places you at the line of code immediately following the call into which you initially stepped. This is a handy feature when you don’t want to step through to the end of a method before returning.

Summary

An IDE provides an integrated suite of tools for improving team productivity and software quality. It can also help simplify the task of developing systems for the J2EE platform with code wizards and online help for API reference material. You will likely use an IDE more than any other tool, so selecting an IDE that meets all your development needs is a critical decision.

When making that decision, ensure the tool supports the full development lifecycle of a J2EE application. The IDE should provide code wizards for generating J2EE program artifacts and powerful editors for all the main Java and J2EE file types, and it should integrate seamlessly with your choice of application server.

Regardless of the cost of the tool, an IDE represents a substantial investment in terms of time and effort. You must determine how the IDE can complement your development practices and what impact it will have on existing build processes.

To get maximum benefit from the tool, set time aside for training. Like any craftsman, you need to be skilled in the use of a tool to get the most from it. Gaining the expertise and knowledge to use a tool effectively is an important part of establishing a firm foundation for conducting rapid development.

The next chapter covers the benefits of test-driven development for RAD and explains how this approach promotes both agility and accuracy in the software development process. We also return to Eclipse to examine the important role the IDE plays in supporting a test-centric approach.

Additional Information

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.12.124