OReilly java power tools apr 2008 ISBN 0596527934

No matter which development method your team chooses, whetherit's Agile, RUP, XP, SCRUM, or one of many others available, Java Power Tools provides practical techniques and tools to help

by John Ferguson Smart

Publisher: O'Reilly Pub Date: April 22, 2008 Print ISBN-13: 978-0-596-52793-8 Pages: 910

particular tool whether it's for build systems, version control,

or other aspects of the development process giving you theequivalent of 30 short reference books in one package No

matter which development method your team chooses, whetherit's Agile, RUP, XP, SCRUM, or one of many others available,

Java Power Tools provides practical techniques and tools to help

you optimize the process The book discusses key Java

development problem areas and best practices, and focuses onopen source tools that can help increase productivity in eacharea of the development cycle, including:

Unit Testing tools including JUnit 4, TestNG, and the open

source coverage tool Cobertura

Integration, Load and Performance Testing to integrate

performance tests into unit tests, load-test your application,and automatically test web services, Swing interfaces andweb interfaces

Issue management tools including Bugzilla and Trac

Continuous Integration tools such as Continuum, Cruise

Control, LuntBuild and Hudson

If you are a Java developer, these tools can help improve yourdevelopment practices, and make your life easier in the

process Lead developers, software architects and people

interested in the wider picture will be able to gather from thesepages some useful ideas about improving your project

infrastructure and best practices

Section 1.10 Bootstrapping Your Build Scripts

Section 1.11 Using Maven Dependencies in Ant with theMaven Tasks

Section 1.12 Using Ant in Eclipse

Section 1.13 Using Ant in NetBeans

Section 1.14 Manipulating XML with XMLTask

Section 1.15 Conclusion

Section 2.1 Maven and the Development Build ProcessSection 2.2 Maven and Ant

Section 2.3 Installing Maven

Section 2.4 Declarative Builds and the Maven ProjectObject Model

Section 2.5 Understanding the Maven 2 Lifecycle

Section 2.6 The Maven Directory Structure

Section 2.7 Configuring Maven to Your EnvironmentSection 2.8 Dependency Management in Maven 2

Section 2.17 Using Maven in NetBeans

Section 2.18 Using Plug-Ins to Customize the BuildProcess

Section 2.19 Setting Up an Enterprise Repository withArchiva

Section 2.20 Setting Up an Enterprise Repository UsingArtifactory

Section 3.3 Creating a New Project in CVS

Section 3.4 Checking Out a Project

Section 3.5 Working with Your Files—Updating andCommitting

Section 4.17 Using Properties

Section 4.18 Change History in Subversion: Logging andBlaming

Section 5.1 An Introduction to Continuum

Section 5.2 Installing a Continuum Server

Section 5.3 Manually Starting and Stopping the ServerSection 5.4 Checking the Status of the Server

Section 5.5 Running the Continuum Server in VerboseMode

Section 5.6 Adding a Project Group

Section 5.7 Adding a Maven Project

Section 5.8 Adding an Ant Project

Section 5.19 Conclusion

Chapter 6 Setting Up a Continuous Integration Server withCruiseControl

Section 9.3 Setting Up Users and Accounts on OpenfireSection 9.4 Authenticating Users in an External DatabaseSection 9.5 Authenticating Users Against a POP3 ServerSection 9.6 Virtual Team Meetings with the Group ChatSection 9.7 Extended Functionality with Openfire Plug-Ins

Section 10.1 JUnit 3.8 and JUnit 4

Section 10.2 Unit Testing with JUnit 4

Section 10.3 Setting Up and Optimizing Your Unit TestCases

Section 10.4 Simple Performance Testing Using TimeoutsSection 10.5 Checking for Exceptions the Easy Way

Section 10.6 Using Parameterized Tests

Section 10.7 Using assertThat and the Hamcrest LibrarySection 10.8 JUnit 4 Theories

Section 10.9 Using JUnit 4 with Maven 2

Section 10.10 Using JUnit 4 with Ant

Section 10.11 Selectively Running JUnit 4 Tests in AntSection 10.12 Integration Tests

Section 11.10 Parallel Testing

Section 11.11 Test Parameters and Data-Driven TestingSection 11.12 Checking for Exceptions

Section 12.4 Interpreting the Cobertura Report

Section 12.5 Enforcing High Code Coverage

Section 12.6 Generating Cobertura Reports in MavenSection 12.7 Integrating Coverage Tests into the MavenBuild Process

Section 12.8 Code Coverage in Eclipse

Section 12.9 Conclusion

Part 5: Integration, Functional, Load, and Performance TestingChapter 13 Testing a Struts Application with StrutsTestCaseSection 13.1 Introduction

Section 15.4 Load-Testing Tests That Are Not Thread-Section 15.5 Separating Performance Tests from UnitTests in Ant

Section 15.6 Separating Performance Tests from UnitTests in Maven

Chapter 16 Load and Performance Testing with JMeterSection 16.1 Introduction

Section 16.2 Installing JMeter

Section 16.3 Testing a Simple Web Application

Section 16.4 Structuring Your Test Case

Section 16.5 Recording and Displaying Test ResultsSection 16.6 Using the JMeter Proxy to Record a TestCase

Section 17.5 Testing Web Services with SoapUI

Section 17.6 Load-Testing with SoapUI

Section 17.7 Running SoapUI from the Command LineSection 17.8 Running SoapUI from Ant

Section 17.9 Running SoapUI from Maven

Section 17.10 Continuous Testing

Section 17.11 Conclusion

Chapter 18 Profiling and Monitoring Java Applications Usingthe Sun JDK Tools

Section 18.1 The Sun JDK Profiling and Monitoring ToolsSection 18.2 Connecting To and Monitoring a Java

Application with jConsole

Section 18.3 Monitoring a Remote Tomcat Applicationwith jConsole

Section 18.4 Detecting and Identifying Memory Leakswith the JDK Tools

Part 6: Quality Metrics Tools

Chapter 21 Detecting and Enforcing Coding Standards withCheckstyle

Section 21.1 Using Checkstyle to Enforce Coding

Standards

Section 21.2 Using Checkstyle in Eclipse

Section 21.3 Customizing Checkstyle Rules in EclipseSection 21.4 Customizing Checkstyle Rules Using theXML Configuration Files

Section 21.5 Customizing Checkstyle: Common RulesThat You Can Do Without, and Some That You Could UseSection 21.6 Defining Rules for Source Code Headerswith Checkstyle

Section 24.2 Installing Jupiter in Eclipse

Section 24.3 Understanding the Jupiter Code ReviewProcess

Section 24.4 Conducting Personal Code Reviews

Section 24.5 Configuration

Section 24.6 Setting Up Default Configuration ValuesSection 24.7 Individual Reviews

Section 25.7 Sharing Context with Other DevelopersSection 25.8 Conclusion

Chapter 26 Monitoring Build Statistics

Section 26.1 Introduction

Section 26.2 QALab

Section 26.3 Source Code Management Metrics withStatSCM

Section 27.5 Restricting Access Using User GroupsSection 27.6 Configuring a Product

Section 28.7 Administrating the Trac Site

Section 28.8 Managing User Accounts

Section 28.9 Tailoring the Trac Web Site: Using the WikiFunction

Section 28.10 Using the Trac Ticket Management SystemSection 28.11 Updating Trac Issues from SubversionSection 28.12 Customizing Trac Ticket Fields

Section 28.13 Setting Up Email Notifications

Section 28.14 Reporting Using Trac Queries and ReportsSection 28.15 Managing Progress with Trac Roadmapsand Timelines

Section 29.6 The Maven Site Generation ArchitectureSection 29.7 Using Snippets

Section 29.8 Customizing the Look and Feel of Your SiteSection 29.9 Distributing Your Site

Chapter 30 Automatically Generating Technical

Documentation

Section 30.1 Introduction

SchemaSpy

Section 30.3 Generating Source Code Documentationwith Doxygen

Section 30.4 Embedding UML Diagrams in Your Javadocwith UmlGraph

Section 30.5 Conclusion

Bibliography

Colophon

Index

Copyright © 2008, John Ferguson Smart All rights reserved.Printed in the United States of America

Published by O'Reilly Media, Inc., 1005 Gravenstein HighwayNorth, Sebastopol, CA 95472

O'Reilly books may be purchased for educational, business, orsales promotional use Online editions are also available for

most titles (http://safari.oreilly.com) For more information,contact our corporate/institutional sales department: (800)

While every precaution has been taken in the preparation of thisbook, the publisher and author assume no responsibility for

errors or omissions, or for damages resulting from the use ofthe information contained herein

This book is dedicated to my wonderful wife Chantal, and mytwo lovely boys, James and William, who are my constantsource of inspiration, wonder, and joy.

Andrew Glover, President, Stelligent Incorporated

Designing, coding, and deploying working Java applications isn'teasy Doing it in a predictable manner rapidly with an

acceptable level of quality is even harder In addition to having

to understand what stakeholders want or the varying skills ofteam members or even the myriad web, data access, and utilityframeworks one can choose from, you've got to actually

manage the development process itself!

The coding of requirements is challenging enough, but as

anyone who's ever delivered a working application knows, in thegrand scheme of things, that's one sliver of the developmentprocess—in fact, some may say that's the easiest part Thinkabout all the techniques and processes that aggregate up toproduce a software application

First, you've got to figure out how to deliver the working

application in a predictable manner At a high level, this meansthree things: tracking changes to source code assets, keeping

up with any uncovered issues, defects, or feature requests, andassembling the application in a reliable and repeatable manner.Next, you're going to want to actually ensure the application

under development actually works—ideally during development.

This means writing tests early Of course, this process is easiersaid than done Although arguably there are few standard

testing frameworks from which to chose, there is a cornucopia

of associated tools that accelerate writing developer tests byaddressing specific challenges

What's more, as the code base grows, you'll probably want tounderstand what's being coded and how well it's being

developed Although tests cancertainly verify code functionality,you may also want lighter-weight tools that can report on

various metrics, such as complexity, coding standards, or eventhe coverage of tests

Of course, if you've got a mechanism for assembling your

techniques that will help you meet each and everyone of thechallenges above In fact, John presents multiple choices in

some cases, giving you the opportunity to decide which toolworks best for you Whether you decide to use Ant or Maven fordelivering a working application in a predictable manner, TestNG

or JUnit for early developer testing, PMD or FindBugs for codeanalysis, or CruiseControl or Luntbuild for Continuous

Integration, this book addresses the fundamental techniques foreffectively employing these tools (and a multitude of others aswell)

Rapid development of Java applications (which have an

acceptable level of associated quality) is still hard as ever;

however, after reading John's magnum opus on the tools andtechniques that ultimately enable predictability, confident, andaccelerated delivery in a software development process, you'llfind that designing, coding, and deploying high-quality Javaapplications rapidly just got a whole lot easier

Here is Edward Bear[1] coming downstairs now, bump,

bump, bump, on the back of his head, behind ChristopherRobin It is, as far as he knows, the only way of coming

downstairs (we probably wouldn't be too far off if we were tospeak of "pain points")

Software development sometimes feels like this It is easy toget so bogged down in the details, under the pressure of tightdeadlines and changing requirements, that you forget that theremight just be a better way A high number of bugs, a difficultintegration process, long and painful builds, and poor projectvisibility become an accepted part of the developer's life

The good news is that there are in fact many easy ways to

improve your software development lifecycle

A judicious use of tools can go a long way in boosting developerproductivity For example, many distributed development teamsuse nothing more sophisticated than a CVS or Subversion

repository for storing application code and a mailing list for

discussion Imagine a system in which, whenever someone

commits a change, issues are automatically closed or updated

development platform to a new level of reactivity and

responsiveness

This is just a first step Soon you will be integrating

automatically running unit and possibly integration tests, codecoverage tools, style checking tools, and more to create a

highly reactive, informative, finely tuned project infrastructure.Tools are the key to making such an infrastructure work

efficiently Once you start to adopt a set of SDLC tools that suityour project and your organization, you will see a revolutionaryshift in a groups development practices Agile development

programmers who haven't experienced this shift are in danger

of missing the trend altogether

Now you shouldn't go thinking that SDLC tools are only for largeteams or big organizations They aren't In fact, most SDLC

tools are easy to setup, and almost all organizations can

benefit, even a small outfit with only two or three developers.Most of these tools and techniques are not particularly difficult

This book is part of the O'Reilly Power Tools series, which beganwith the illustrious Unix Power Tools back in 1993 It has norelation to the "Java Power Tools" library

(http://www.ccs.neu.edu/jpt/), which is a software researchproject in the Java GUI field, conducted by College of Computer

& Information Science at the Northeastern University, Boston,under the direction of Richard Rasala

P2.1 How This Book Is Organized

One of the most characteristic traits of the open source

(http://opensource.org) Java world is choice It seems that, forany given task, there are always at least two open source toolsthat can do the job To reflect this, I have tried to give a

representative survey of the available open source tools foreach area of software development that we cover The bookdoes not try to "sell" any one tool, or even any one tool in eachdomain On the contrary, we try to give readers enough

information so that they can decide for themselves which tool isthe most appropriate for their particular organization, and giveenough practical information to get them up and running

This book is organized into sections, with each section covering

a particular aspect of the software development lifecycle (orSDLC) With each section, we look at a number of available

tools that can be used to improve this aspect of the SDLC

P2.1.1 Build Tools

In the first section, we cover possibly the most fundamentaltool of all (after the compiler and the IDE, that is): the buildtool Indeed, when used well, the build tool becomes the

cornerstone of your SDLC process It is this tool that

coordinates, federates, and binds the other SDLC tools togetherinto a single, coherent process And the build tool helps to

In the Java world, two tools dominate this area The first is Ant,the traditional Java build tool, which uses a straightforward

procedural approach and benefits from a very large user baseand a rich set of extensions The second is Maven 2, which uses

a powerful, declarative approach to project build managementand, as we will see, goes much further than being a simple

build tool We will look at each of them in some detail in thissection

P2.1.2 Version Control Tools

The second section covers that other fundamental component ofany software development infrastructure: a version control

system not only provides critical backups of your source code, italso lets developers work together on the same project withoutgetting in each other's way Version control systems also allowyou to identify versions and coordinate releases and (if

necessary) rollbacks Finally, as we will see in Part VIII, it is acornerstone of any Continuous Integration environment

In this section, we will look at the two most prominent opensource version control tools on the market: CVS and

Subversion

P2.1.3 Unit Testing

Unit testing is another important best practice of modern

software development Although testing is certainly not new initself, unit testing, and practices such as Test-Driven

Development, have been gaining popularity over recent years.Not only does proper unit testing help ensure that your codeworks; it also fosters cleaner, more modular, and better

designed code Automated unit testing takes this a step further

By simply integrating your unit tests into your standard buildprocess, and running them automatically with every build, youcan go a long way toward increasing the quality and reliability

Writing tests is good, but it is even better to be sure of whatcode you are actually testing Test coverage tools help you

check how much of your application is actually being executedduring your unit tests This in turn helps you identify untestedcode and improve the overall quality of your tests

In this section, we will cover the latest tools in the unit testingdomain, including JUnit 4 and TestNG, and see how these testscan be integrated smoothly into the build process We also willlook at how to verify test coverage with Cobertura, a powerfulopen source coverage tool

P2.1.4 Integration, Load, and Performance

Testing

Unit testing is not the end of the story as far as testing goes.This section looks at other testing techniques such as

integration, load and performance, and user interface testing.All of these are important, and all can benefit from being

integrated into the build process

In this section, we will see how to integrate performance testsinto your unit tests, how to load-test your application, and how

to automatically test web services, Swing interfaces, and webinterfaces

P2.1.5 Quality Metrics Tools

It is important to be able to measure the quality of your code inobjective terms Code quality has a direct bearing on the

number of bugs and the ease of maintenance later on Codequality metrics can also be a good way to bring inexperienceddevelopers up to speed with coding conventions and best

practices This section looks at a range of automated tools thatmeasure different aspects of code quality, including CheckStyle,PMD, FindBugs, and Jupiter

P2.1.6 Technical Documentation Tools

significant part of this documentation can (and should) be

generated automatically, based on the source code and

to-date technical documentation This section describes toolsthat can help you generate good technical documentation

comments This is the most reliable way to get consistently up-without having to spend too much effort writing and

maintaining it

P2.1.7 Issue Management Tools

We will look at that vital communication tool in the SDLC, theissue tracking system Of course, issue tracking systems can beused by testers to raise bugs and by developers to documentbug fixes But they can also be used to help organize and

document releases, to plan iterations, and to assign work tasks

to team members

There are literally hundreds of issue tracking systems out there,both open source and commercial In this section, we will look

at two of the more interesting open source solutions seen in theJava world The first is Bugzilla, the original open source issuetracking system The second is Trac, which excels by its

In software development, it is a common observation that thelonger you wait to integrate your team's code, the harder itgets Continuous Integration is based on the idea that you cangreatly facilitate this process by committing small changes

regularly, and then running automatic builds whenever codechanges are committed Whenever a developper commits new

sure that the modifications compile correctly However, why

stop at simply checking that everything compiles? While you're

at it, you might as well check that all the unit tests still run notforgetting, of course, the integration, performance, and userinterface tests

Indeed, virtually all of the tools and techniques that we havediscussed above can benefit from being run automatically on aregular basis

tailored shell script and a cron job, nowadays there are a lot oftools that can save you a great deal of time and effort in thisarea In this section, we will be looking at some of the moreinteresting open source CI tools: Continuum, CruiseControl,LuntBuild, and Hudson

Although this sort of integration is certainly possible with a well-P2.2 Who Should Read This Book

This is, fundamentally, a techie book It is a hands on tour of awide range of tools, for people who like to get their hands dirty

If you are a Java developer, these tools can help to improveyour development practices, and make your life easier in theprocess Lead developers, architects, and people interested inthe wider picture will be able to glean from these pages someuseful ideas about improving your project infrastructure andbest practices You will learn about the different build tools ofthe Java world You will learn how to set up a version controlserver or a Continuous Integration server using open sourcetools You will find tools to support your coding standards anddesign recommendations, and automatically generate high-

quality technical documentation You will find out how to get themost out of your unit and integration tests

Readers are expected to have a basic knowledge of Java andXML Many build servers run on Linux boxes, so there will be a

systems issues are discussed No prior experience of any of thetools is required

P2.3 What This Book Doesn't Cover

This book cannot come close to covering all the good softwaretools on the market Some aren't here for lack of space, or

simply because I wasn't familiar enough with them to do themjustice

This book is limited to open source tools This is not becausethere are not commercial tools in the software developmentlifecycle field: there are Nor is it because these tools aren'tworth considering for your project or organization; again, theymay be No, commercial tools are off limits for a simple

question of scope (I did want to finish this book one day), and,

to be fair to everyone, it would be hard to include one tool

without including all the others

Having said this, there are a few excellent commercial tools onthe market which it would be a shame not to mention Thesecommercial tools are often of very high quality, with many

innovative features And, as in any field, competition is always

an excellent driver for innovation

Two organizations that deserve special mention in this area areAtlassian and JetBrains Atlassian is behind the very popularJIRA issue tracking system They also market Bamboo, an

innovative Continuous Integration server, as well as a set ofintegrated tools such as Clover, a test coverage tool; FishEye, atool that helps you to visualize the contents of your source coderepository; and Crucible, a code review tool

JetBrains is the author of the well-known and highly innovativeJava IDE IntelliJ Recently, JetBrains have also developed

TeamCity, a next-generation Continuous Integration server that

builds and tests code before it is committed to version control.

P2.4 Contributing Authors

This book was not written alone Indeed, it has been a

collaborative effort, with the direct and indirect participation ofmany people The following are those who generously

contributed their time and energy into providing valuable

material for this book:

Brian Agnew

Brian Agnew is the founder and principal consultant withOOPS Consultancy Ltd, located in London, U.K He holds aB.Eng in Electrical and Electronic Engineering from

Sheffield University He advises and works with major

financial houses and leading consultancies on a wide range

of projects, including trading systems, network

management infrastructures and grid-based architectures,working in Java mainly, C++ when he has to, and Perl whennothing else will do

Brian contributed material on XMLTask, an Ant task thatprovides sophisticated XML manipulation

Jettro Coenradie

Jettro Coenradie is a Java (enterprise) specialist living in theNetherlands Jettro has been working in the ICT for about

10 years now He likes to try out new frameworks that arefocused on quality and productivity, so he is interested intools like Luntbuild, Continuum and Maven In addition,

Jettro is a software architect focusing on the Spring

framework You can find more information about Jettro onhis blog, http://www.gridshore.nl/blog

Jettro contributed an article on integrating Maven with

Keith contributed material on Mylyn

John Hurst

John Hurst is an experienced Java developer an

independent software developer, and a systems integratorworking in the Wellington, New Zealand, area John is anactive member of the Java community, and plays a key role

enterprise framework, which is a service-oriented

framework based on Java EE 5 and other open standards.Masoud's area of expertise are SOA and web services inaddition to performance monitoring and management

Masoud is a contributor of several open source projects thatare utilized in the E-peyk framework

Masoud contributed material on SchemaSpy and on SoapUI

Avneet Mangat has six years' experience with Java/JEE He

is currently working as the Lead Developer at Active HealthPartners, U.K He is a Sun-certified programmer and webdeveloper and is also Prince2-certified He is also the leaddeveloper of DBBrowser open source database browsingtool (http://databasebrowser.sourceforge.net/) Outsideinterests are photography and traveling

Avneet contributed material on setting up a Maven

repository with Artifactory

Eric Redmond

Eric Redmond has been involved in the Maven communityfor over two years as a user, contributor, speaker, author,and patch provider, as well as a founder of two professionaleducation and consulting companies surrounding Maven andother aspects of large-scale application lifecycle

management He is currently enjoying some downtime,

meaning a simple life as a Ruby (and Rails) developer, yetkeeping a keen eye on JRuby He is the proprietor of

Dev2Dev, JavaWorld and Objective View Before joiningOracle, Alex was a consultant for ThoughtWorks Alex

maintains a blog at http://www.jroller.com/page/alexRuiz.Alex has contributed material on FEST

Tim O'Brien also helped out with ideas for the introduction

P2.5 Technical Reviewers

The following people were brave enough to accept the task offormally reviewing the finished manuscript:

Nigel Charman

Nigel is a Java consultant living in Wellington, New Zealand, with a special interest in developer testing and code quality In his spare time, he's currently working on the JiBX/WS web services framework and helping to organize the Wellington Java User Group.

Stuff Anthology (Pragmatic Programmers, 2007)

and the "UML 2 Toolkit" (Wiley, 2003) He actively blogs on TestEarly.com and IntegrateButton.com.

technical editor for Java Power Tools, he is currently

the President of the Denver Java User Group and did the technical editing for JBoss at Work, No Fluff

Just Anthologies (2006 and 2007), and GIS for Web Developers (2007) He also wrote reviews for

Pragmatic Unit Testing in Java with JUnit and

Pragmatic Project Automation, which can be found

on the Denver Java User Group and The Server Side web sites.

Many other people also reviewed individual chapters or

sections, including Cédric Beust, Keith Coughtrey, Richard

Hancock, Jimmy Kemp, Gregor Lawson, Andrew McDowell, BrettPorter, Bill Ross, and Martin White

P2.6 Conventions

explanatory Literal text such as file names, class names, and

Most of the conventions used in this book should be fairly self-so on, is represented using a fixed width font Commandsintended to be executed on the command line are written in

constant width italic Code listings are written like this:

<settings>

discussion Application windows such as IDEs are shown in full

or partially, depending on the context

P2.7 Source Code

There are a lot of practical examples throughout this book Youcan download the source code for these examples from the

publisher's web site, or from the Java Power Tools web site

(http://www.javapowertools.com) In general, the code is

designed to illustrate how to use the various tools, and to make

it possible for you to experiment with the tools As a rule, it isnot of production code quality, as production quality code tends

to be more complex and project-specific

P2.8 About the Title

This book is part of the O'Reilly Power Tools series, which beganwith the illustrious Unix Power Tools back in 1993 It has norelation with the "Java Power Tools" library

(http://www.ccs.neu.edu/jpt/), which is a software researchproject in the Java GUI field, conducted by College of Computer

& Information Science at the Northeastern University, Boston,under the direction of Richard Rasala

P2.9 Acknowledgments

First and foremost, I would like to deeply thank my wife,

Chantal, and my two boys, James and William, whose greatlove, patience, and support over the last two years have madethis book possible Writing this book involved a seemingly

unending stream of late night writing and grumpy mornings, aswell as frequently delegating important tasks such as playingwith the kids, putting them to bed and story-telling Chantal

I would also like to thank the team at Equinox, New Zealand.Equinox provided invaluable time and resources for this book,

as well as many challenging opportunities to research and workwith the tools and techniques described in the book First andforemost, a warm thanks to Roger Dalgleish and Paul Ramsay,without whose help this book would simply not have been

possible Also, thanks to all the Equinox staff members whotook the time to read the (sometimes very) rough draft

chapters and provide valued feedback, and to those who helped

in all sorts of other ways: Willy Bartholomeusz, Keith

Coughtrey, Candi Cunningham, Nev Flaws, Richard Hancock,Jimmy Kemp, Gregor Lawson, Brian Levy, Brendon Livingstone,Craig McLean, Andrew McDowell, Robin Newton, Bill Ross, PeteTanesey, Kenneth Wells, Martin White, Yolanda van Dorrestein,and everyone else at Equinox

A big thanks to all the contributors—Brian Agnew, Jettro

Coenradie, Keith Coughtrey, John Hurst, Masoud Kalali, AvneetMangat, Eric Redmond, and Alex Ruiz—without whose help thisbook would have been considerably poorer

Thanks also to the reviewers who spent uncounted time andenergy reading the draft manuscript and providing many

valuable comments and suggestions: Nigel Charman, Paul

Duvall, Greg Ostravich, and also Cédric Beust, Keith Coughtrey,Richard Hancock, Jimmy Kemp, Gregor Lawson, Andrew

—in particular Jenny McDonald and Paul Curtis—and the staff at

reading me Winnie the Pooh as a child.

And to Maryse and Emmanuel Consul, for their kindness andhospitality during all those years, and for letting their daughterdepart for a far-off foreign land

Thanks also to my "kiwi" family, Diana and Owen Lowe, andYvonne and Cornelius Van Veen, for their warm welcome,

permanent support, and for those many evenings during whichwine, beer, and friendship rejuvenated my mind between

chapters

A book like this would not be possile without the vibrant Javaopen source community in existance today Thanks to tool

authors and contributors the Wellington Java Users Group and

to other members of the Java community with whom I haveexchanged words, emails, and ideas over the last few years:Cédric Beust, Mandy Chung, Scott Davis, Mohamad Easawy,Jeremy Flowers, Rob Harwood, John Hurst, Mik Kersten,

Surjendu Kuila, Steve Loughran, Brett Porter, Cameron Purdy,Matt Raible, and Rob Williams

P2.10 Using Code Examples

This book is here to help you get your job done In general, youmay use the code in this book in your programs and

documentation You do not need to contact us for permissionunless you're reproducing a significant portion of the code Forexample, writing a program that uses several chunks of codefrom this book does not require permission Selling or

distributing a CD-ROM of examples from O'Reilly books doesrequire permission Answering a question by citing this bookand quoting example code does not require permission

Incorporating a significant amount of example code from this