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.

Important 

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 Chapter 7, 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.

IDEs

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 Chapter 4). Eclipse (http://www.eclipse.org), a free open source product, is particularly good in this respect. Eclipse provides automatic support for:

  • Renaming packages, classes, methods, and variables (including updating all dependencies)

  • Supporting common refactorings such as "extract method", and promoting a method to a superclass

  • Searching for references to a class or method throughout a project

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:

  • Compiling all source code

  • Compiling test code

  • Creating J2EE deployment units - WARs, EJB JARs, and EARs

  • Generating Javadoc for the entire application

  • Automatically detecting test cases and running tests in a single operation

More advanced tasks include:

  • Checking code out of a version control system

  • Tagging all files in the version control system with a specified build identifier

  • Putting a database in the required state before a test run and cleaning the database after a test run

  • Deploying onto an application server

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 http://jakarta.apache.org/ant/index.html.

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 can be used in conjunction with your favorite IDE (in this case, it's a good idea to have Ant compile classes to a location other than where the IDE compiles classes to, to ensure that the IDE doesn't become confused). Most developers will work on code (and compile it in the first instance) in an IDE, but build releases using Ant. Popular IDEs offer Ant integration, allowing Ant tasks to be run from within the IDE.

  • Ant provides standard "tasks" for many common requirements such as executing system commands, generating Javadocs, copying and moving files, validating XML documents, downloading files from a remote server, and running a SQL script against a database, in addition to compilation of Java source code (which is often considered to be Ant's main role).

  • Many products offer Ant tasks to simplify their use. For example, WebLogic 6.1 and above use Ant for certain tasks. Many third-party Ant tasks are available to perform a wide range of functionality including packaging and deploying J2EE applications on several application servers.

  • Ant provides an effective way of scripting deployment to an application server.

  • Like make, most Ant tasks check dependencies. Thus Ant will automatically recompile only source files that have changed, and skip tasks for which the results are still up to date.

  • Ant is parameterizable. Ant "properties" can be set to hold values that vary between operating systems and individual machines (such as the absolute location of the root of a classpath), ensuring that the rest of each build script is completely portable. Ant is also capable of performing different sets of tasks depending on criteria such as the operating system or the availability of certain classes.

  • Ant is extensible. It's relatively easy to define custom Ant "tasks" in Java. However, Ant comes with so many tasks to perform common operations-many of them J2EE-related-and so many third-party tasks are available that few developers will need to implement their own Ant tasks.

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

Important 

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 http://jakarta.apache.org/ant/ant_in_anger.html 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.

  • EJBGen
    http://www.beust.com/cedric/ejbgen/

    This tool, written by BEA developer Cedric Beust, is bundled with WebLogic 7.0.

  • XDoclet
    http://xdoclet.sourceforge.net/

    This similar, but more ambitious, tool, written by Rickard Oberg, is available in open source, and can be used to perform other tasks as well as EJB generation.

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 (http://www.tallsoftware.com/lowroad/index.html).

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 http://www.wincvs.org, 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.



Expert One-on-One J2EE Design and Development
Microsoft Office PowerPoint 2007 On Demand
ISBN: B0085SG5O4
EAN: 2147483647
Year: 2005
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net