Bug Patterns in Java

Bug Patterns in Java

Eric Allen


Copyright © 2002 by Eric Allen

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.

ISBN (pbk): 1-59059-061-9

Printed and bound in the United States of American 12345678910

Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

Technical Reviewer: Corky Cartwright

Editorial Directors: Dan Appleman, Gary Cornell, Jason Gilmore, Simon Hayes, Karen Watterson, John Zukowski

Managing Editor: Grace Wong

Project Manager: Sofia Marchant

Development Editor: Kane Scarlett

Copy Editor: John Fruhlinger

Compositor: Impressions Book and Journal Services

Indexer: Ron Strauss

Cover Designer: Kurt Krames

Production Manager: Kari Brooks

Manufacturing Manager: Tom Debolski

Marketing Manger: Stephanie Rodriguez

Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 175 Fifth Avenue, New York, NY 10010 and outside the United States by Springer-Verlag GmbH & Co. KG, Tiergartenstr. 17, 69112 Heidelberg, Germany. In the United States, phone 1-8900-SPRINGER, email <orders@springer-ny.com>, or visit http://www.springer-ny.com Outside the Untied States, fax +49 6221 345229, email <orders@springer.de>, or visit http://www.springer.de.

For information on translations, please contact Apress directly at 2560 9th Street, Suite 219, Berkeley, CA 94710. Phone 510-549-5930, fax: 510-549-5939, email <info@apress.com>, or visit http://www.apress.com.

For Kori

About the Author

ERIC ALLEN sports a broad range of hands-on knowledge of technology and the computer industry. Starting with a bachelor's degree in computer science and mathematics from Cornell University and a master's degree in computer science from Rice University, and culminating in proven experience as the lead Java software developer at Cycorp, Inc., Eric is currently a PhD candidate in the Java programming languages team at Rice University Eric is a project manager for and a founding member of the DrJava project, and open-source Java IDE designed for beginners. He has moderated several Java forums for the online magazine JavaWorld, and is the author if Diagnosing Java, a regular column for the IBM developerWorks Web site.

At Rice University, under the advisement of Professor Robert "Corky" Cartwright, Eric's research concerns the development of semantic models and static analysis tools for the Java language, both at the source and bytecode levels. He is also concerned with the verification of security protocols through semantic formalisms and type checking. Eric is the lead developer of Rice University's experimental compiler for the NextGen programming language, an extension of the Java language with added experimental features. In his spare time, he assists with teaching software engineering to Rice University's computer science undergraduates. You can contact Eric at <eallen@cs.rice.edu>.

About the Technical Reviewer

PROFESSOR ROBERT "CORKY" CARTWRIGHT has devoted his career to elevating programming from a black art to a systematic discipline. Professor Cartwright earned a bachelor's degree magna cum laude in applied mathematics from Harvard College in 1971 and a doctoral degree in computer science from Stanford University in 1977. In 1980, he joined the faculty of Rice University, where he helped found the computer science department and subsequently served as department chair.

Professor Cartwright's principal research interests are programming language design and implementation, program specification, program testing and analysis, and software engineering. He is currently engaged in three major research projects: NextGen, to compatibly extend the Java programming language to support first class genericity; Soft Typing, to develop program analysis tools for Java that use precise type inference to help programmers debug and optimize programs; and DrJava, to develop production quality pedagogic programming environments for Java using extreme programming.


MY ADVISOR AND MENTOR, Robert "Corky" Cartwright, has taught me much of what I know about effective software development, specification, and debugging. Corky was also the technical reviewer of this book, and it is a much better book because of his efforts. I also owe a great deal of gratitude to Matthias Felleisen for teaching me the nature of precise software specification and what it means to analyze software rigorously. My undergraduate research advisor, Claire Cardie, first introduced me to the nature of academic research, as well as programming in the large.

I've also been quite privileged to work alongside Brian Stoler, the former Rice M.S. student, lead developer of DrJava, and an extremely able developer. Our many enlightening conversations about the nature of software development have often influenced my own views. His successor, Charlie Reis, is an extremely capable developer, and I am quite optimistic that DrJava will continue to live up to its reputation for being an extremely robust and well-designed IDE. Other students who have served as developers of that tool are Jonathan Bonnet, Erik Burns, Peter Centigram, Stephan Elmer, John Garvin, James Hsiao, Chris McGraw, Alan Miscode, Robby Morgan, Aura Oberon, James Assistor, Jim Van Fleet, Ben Vernon, Christian Westbrook, Mike Yantosca, and Theo Yaung.

Many of the original articles on which this work is based were written while I was at Cycorp, and all of my co-workers and friends at that institution provided a rich and lively atmosphere for software development. In particular, discussions and work conducted with Stefano Bertolo, Steve DeVoy, Keith Goolsbey, Daniel Mahler, Steven Reed, and Mike Reimers (who first suggested the name for the Saboteur Bug Pattern) were directly pivotal to some of the ideas expressed in this work. Other influences, if less direct, were no less significant: Bjorn Aldag, David Crabbe, Charles Klein, Fritz Lehmann, Cindy Matuszek, Nancy Salay, Paul Strominger, and Ming Xu. Many minds at that institution have influenced my thoughts; my apologies to any I have forgotten to list.

The lead editor of the IBM developerWorks Java Zone, Jenni Aloi, has helped me many times with her constructive criticism and continuing support for my Diagnosing Java column. And I have my editor, Kane Scarlett, to thank for making those articles look so good. Kane is also the developmental editor of this work, and he has done an extraordinary job, above and beyond the call of duty, in helping to structure the text and design new chapters where appropriate. Josh Fruhlinger, my copy editor, a part-time editor, and a longtime friend, was also instrumental in my writing this book. I've known Josh since second grade. He encouraged me to write my first online article, and he encouraged me to write for developerWorks. Without his encouragement in my early stages of article writing, this book surely would never have been written. He has also done a great job in improving the text and in catching a lot of mistakes.

Gary Cornell first approached me with the idea of writing this book. He, John Zukowski Sofia Merchant, and the rest of the Apress staff have been quite helpful in actually getting the book finished.

I would also like to thank my parents and family for all of their guidance. Most of all, I would like to thank my wife, Kori, for her loving encouragement and support even when I worked completely unreasonable hours, for making sure that I always kept a healthy perspective on my work, and for always offering sincere and insightful feedback when I needed it.

My copyeditor has informed me that it is considered de rigueur to add the following sentence at the end of the acknowledgements section:

All errors in this work are, of course, my own.

Although I believe that this sentence is true, it wouldn't be very informative; as far as anyone else knows, it might be an error itself. In fact, if it were an error, it would be the copy editor's error, not my own. Furthermore, how could we ever know that this sentence is not the only error in the entire book that isn't my own? To do so, we'd first have to know whether the sentence itself was in error, but that begs the very question we are trying to answer! In short, including this sentence in the work is very dangerous; it's better reserved as paradoxical ammunition against evil computers on Star Trek whose circuits we are trying to overload. So I've decided to blame all errors in this work on the copy editor instead.