Is NetBeans for you? The algorithm for answering this question is:
Determine what NetBeans does.
Decide if that functionality is for you.
Sometimes it is incorrectly thought that integrated development environments are intended to make Java™ programming easier. You know already, though, that advanced tools don’t save work so much as they make the same amount of work yield more effective results. That’s what NetBeans does; it allows you to trade one set of practices for another. The practices that NetBeans imposes are fully as intricate as your current development practices. More intricate, perhaps, because if you are a real programmer, you will want to supplement your work style with NetBeans rather than attempting to use NetBeans to completely replace your current work style. The practice of NetBeans development is not easier. It’s just more effective than what you were doing before NetBeans. You get more done with NetBeans.
Well, for a start, NetBeans: The Definitive Guide is a book written by a select team of NetBeans enthusiasts and experts, all of whom are talented and experienced programmers. Some have used NetBeans almost since the beginning. Each has had his theories about programming using NetBeans tested in real world software engineering.
Also, members of the NetBeans development team watched over the evolution of this book, making suggestions, correcting misapprehensions, sometimes disagreeing with the authors’ conclusions in the course of a long-distance group authorship project conducted over the Internet, a project that took almost two years to complete.
What’s more, during the period in which the authors were preparing this book, NetBeans was changing. Features came and went. Visual layout changed, thus rendering carefully arranged screenshots out of date. Whole components appeared in and disappeared from the NetBeans core. If you’ve ever studied the computer science heuristic of “simulated annealing,” you’ll recognize the process that this book underwent: like a seven-folded samurai sword, our work has been melted and hammered out flat over and over again.
NetBeans: The Definitive Guide presumes that you are a NetBeans beginner, not a beginner programmer. We are not going to teach you programming; we’re going to teach you how to use NetBeans to enhance your programming productivity.
Sun Microsystems’ Java programming environment has transformed the software development model of many programming teams. Designed not only for portability and rapid prototyping, Java is as much a prefabricated software development methodology as a programming language. Life isn’t always as simple as the Java approach tries to make it, but it is that simple often enough that Java is a good bet for many projects.
If you have no extraordinary requirements, the basic Java model of development is handy to use. If you happen to have special requirements, the power and flexibility of Java combined with access to other code bodies via language resources such as the Java Native Interface (JNI) and runtime protocols such as Transport Control Protocol /Internet Protocol (TCP/IP) and Java’s Remote Method Invocation (RMI) layer tend to assure that some Java-based solution is within practical reach.
Java is huge, yet still hugely consistent. The core Java development tools sprang from the same collective brow as did the language itself. For documentation, there’s Javadoc. For client-server communication, there’s RMI. Even the IDE, or rather, any number of IDEs from any number of vendors, were anticipated.
Java was intended from its earliest days to cater to the integrated development model of drag-and-drop program composition. Apropos this requirement, among the core methodologies designed into Java development you will find the http://java.sun.com/beans/docs/spec.html, JavaBeans specification.
JavaBeans is an instance of the general design pattern of mapping a single fundamental entity onto a multiple-class implementation. As handy as the metaphor of object orientation has proven, real programming goes well beyond “just objects” in complexity of structure. Performing design decomposition on modern programs reveals that they tend to consist of fundamental entities that cannot conveniently be mapped just to single classes in any practical programming language. JavaBeans is one possible multiple-class mapping of a design concept.
If you think objects should communicate and cooperate reflexively, JavaBeans agrees with you. JavaBeans represents the object’s ability to communicate with other entities, usually beyond runtime to design, compile, and configuration times.
Sun engineers identified early on in the life of Java one particularly interesting category of entity requiring a multiple-class implementation, that of the reusable visual component. Such a component has both a runtime and a design-time persona. Components of this sort are used in an integrated development environment such as NetBeans. Each drag-and-drop component used in an IDE to design programs needs both a runtime class that embodies the component functionality and a design-time class that the IDE employs for the visual representation and manipulation of the class.
The JavaBeans framework, although widely applicable beyond the creation of visual design components, has received its broadest exposure in that domain. Visual JavaBeans allows a component author to map the design persona of the component onto a separate Java class—the BeanInfo class—from the component’s runtime class in a fashion portable between different IDEs. This design-time persona is critical to establishing a visual representation of the component to the user and to establishing a properties metaphor for configuring the component in the design tool. On the other hand, the design-time persona is excess baggage at runtime. The packaging of the design-time persona of a reusable visual entity into a secondary class allows superfluous information to be discarded at runtime.
Java as an object-oriented programming environment possesses a more complete object model than does, say, C++. Java objects are capable of reflection. This means that objects and methods exist within Java to allow examination (often called reflection, sometimes called introspection) of an object’s methods and data.
The JavaBeans framework takes advantage of Java reflection by creating classes whose main purpose is to be a repository of information about another class. These Bean classes each typically bear the name of the first-order class they shadow with “BeanInfo” appended to the name. A BeanInfo class can itself be composed algorithmically in software, either by automated examination of the source code for the first-order class or by using reflection to examine the compiled form of the first-order class. Additional information about the first-order class may be contained within the BeanInfo class; for example, in the case of a visual widget, the BeanInfo class contains information about the default size, title, colors, and orientation of the first-order class and often an embedded icon to be used to represent the first-order class on the toolbar. Additionally, the Bean may possess methods that communicate application-specific information to tools aware of the significance of that information.
The basic JavaBeans design pattern was conceived primarily to ensure that factoring and component reuse would become the norm in Java programming. The core concept of NetBeans visual development is the design pattern of composing program components packaged as JavaBeans out of subcomponents also packaged as JavaBeans.
This might be called the “matryoshka doll pattern” of software design, after the Russian folk art of nested dolls, each of which is structurally complete in itself yet whose “semantic” resides in its recursively containing other structurally complete dolls.
NetBeans makes use of JavaBeans and the generation of new JavaBeans so automatic that it’s almost always easier to generate a simple component, “bean” it, and drag it into the next-higher-level component you wish to compose than to do things any other way.
The architects of Java were largely successful in achieving this goal of providing a usable and compelling model for component packaging. And in the vanguard of this success we find NetBeans, the subject of our book.
NetBeans is an IDE. As such, it resembles other IDEs used in modern software engineering for authoring programs in languages such as C/C++, Forth, Ada, FORTRAN, COBOL, and RPG. NetBeans, however, is integrated with the code that is developed under NetBeans in a way that is impossible in many other languages (though Forth, Smalltalk, and LISP foreshadowed this sort of introspective language structure). It is as if NetBeans were itself the visual manifestation of the Java Development Kit (JDK) and of the Java Foundation Classes (Swing).
Per the core concept of NetBeans, the essential model of visual programming is as follows:
Use JavaBeans from the NetBeans component palette to create a visual component.
Wrap that component as a JavaBean.
Add that component to the NetBeans component palette, either to an extant palette or to a user- or application-specific palette.
Use the new component in the creation of more complex enclosing visual components.
The process is repeated as many times as necessary, both forming many components out of the same selection of JavaBeans and continually enhancing the palette by the more deeply nested JavaBean composition. Thus a simple visual program is composed of a small selection of top-level JavaBeans and any wrapper or nonvisual helper classes that are required.
NetBeans offers all the usual and expected features of an IDE:
Integrated source control support for
In addition to its own internal build system and compiler, NetBeans offers integration with external compilers and an external build system, http://jakarta.apache.org/ant/index.html, Jakarta Ant, one that is rapidly becoming the dominant build tool in the Java/XML world and beyond
“Wizard” dialogs to assist the user at choice points
NetBeans itself is written wholly in Java, which is why it runs on any platform that supports the JDK. Furthermore, the runtime configuration of NetBeans is described in XML. When the core of NetBeans loads, it configures and launches the rest of the system. The core reads the XML description and loads the appropriate modules, that is, components written in Java against the NetBeans API.
It is this modules concept that allows extension of NetBeans. Many or most of the important features of NetBeans are modules that can be detached from the system and upgraded as needed. And because NetBeans is open source software, you are free to modify and recompile any modules whose behavior you wish to change. Thus, NetBeans has a close relationship with the programs it is developing that most other IDEs do not possess. NetBeans itself is developed in NetBeans, and any NetBeans user who wishes to join in may be part of that process.
In fact, NetBeans is so attractive a platform for tool architects that over 80 organizations have specifically ported their tool applications to NetBeans modules to make it more convenient for developers to use their tools. Visit the http://www.netbeans.org/third-party.html, Who is building on top of NetBeans, page to browse the eclectic mix of target applications from business and industry that use NetBeans as their development front end or as glue to hold their application presentation together.
Beyond the usefulness of adding features by adding modules to NetBeans, understanding how the individual tools that make up the NetBeans experience interoperate is a beneficial exercise for understanding the integration of component-based software. Whatever applications you wish to develop using NetBeans, if you work diligently and are lucky, over time the programs you write will come to be as well architected as NetBeans itself.
Many “real programmers” are not well-disposed toward IDEs. An IDE is no substitute for knowing the fine details of a programming language and its toolchain. Some IDEs surreptitiously introduce into a program de jure dependencies on a vendor’s libraries or de facto human dependency on the IDE for program maintenance. Worse, many IDEs obstruct the flow of creativity and impose their theories of software engineering upon the work flow in a fashion likely to clash with the programmer’s creative muse.
NetBeans has none of these flaws to any great extent. It neither ties the user to proprietary libraries nor renders source unmaintainable to an ordinary editor. NetBeans is an IDE for the expert programmer, yet gentle and easy for the novice. It achieves this by being the product of a community of expert Java programmers who have labored to render their own Java practice more enjoyable and more productive. Such individuals have no doctrine to impose other than the doctrine of mutual assistance, free software, and coding that must bear the scrutiny of the public eye.
NetBeans is open. Modules may be added and, perhaps more importantly, subtracted from the NetBeans installation. NetBeans source can also be modified under NetBeans and then recompiled to the tastes of the user. The usefulness of NetBeans is that there is as little of NetBeans between the programmer and his or her program as the programmer wills.
One easily anticipated result of this flexibility of NetBeans is that the various authors of this book are each working on different platforms and at different levels of this open source project. Therefore, illustrations in this book will be somewhat inconsistent because they are drawn from screenshots of NetBeans running in the Java environments for Linux, Solaris, Windows, and possibly other operating systems.
We could have standardized on one platform to present the illustrations, but why play favorites? You, our readers, will be running NetBeans on a variety of platforms. The model of NetBeans behavior is consistent and pervasive even if the shape and color of its scroll bars change from platform to platform.
It is in the nature of open source projects such as NetBeans to change rapidly. The authors of this book are working with NetBeans 3.3.1 and are trying in this book to be as general as possible in describing the functionality and operation of NetBeans because by the time you read this, some bright idea unknown to us at the time of writing may have worked its way into the latest release. Please remember this point, especially when viewing the illustrations, and do not be surprised if the layout of some or many windows has changed. It’s almost certain that this will have occurred, but generally in the direction of augmented functionality. Rarely does a feature disappear, but this too has been known to happen from release to release, when one feature is replaced by a more advanced feature or set of features. In such cases, reading through the release notes may help point the way to finding the desired feature in its new location or its replacement.
The source code to all of the examples in the book.
Any libraries or other code required by the examples in this book.
NetBeans Module files for complete NetBeans modules demonstrated in the half of the book on writing your own extensions modules for NetBeans. These files can be easily loaded into NetBeans to install the modules: just select Tools → Update Center and choose Install Manually Downloaded Modules when prompted.
The accompanying sources can be downloaded from http://www.oreilly.com/catalog/netbeans.
The structure of NetBeans, both internally and to the user, is very hierarchical. Very often you will open a dialog from a menu, which will then display a tree structure that you will need to navigate. In the procedures in this book, these containers are named inline—for example, “select Tools → Options → IDE Configuration → Look and Feel → Menu Bar → File" refers to both menu items and entities within the tree in the dialog that appears. Literally this translates to: Click the Options item on the Tools menu. Expand the folder IDE Configuration, its subfolder Look and Feel, and that folder’s subfolder Menu Bar in the resulting dialog, and select the tree node labeled File. This convention is also followed in the NetBeans documentation.
We use the term
$NB_HOME to denote the base
directory for an installed copy of NetBeans. A similar convention of
using Unix-style environment variables is used to denote other
information that varies between systems, such as
For brevity, most code examples omit import statements and such—we want this book to be readable. All of the code examples in the book are included in full source form on the accompanying downloadable sources.
Code listed in the book is generally formatted for readability and so may differ in indentation and line breaks from the downloadable sources.
Please address comments and questions concerning this book to the publisher:
|O’Reilly & Associates, Inc.|
|1005 Gravenstein Highway North|
|Sebastopol, CA 95472|
|(800) 998-9938 (in the United States or Canada)|
|(707) 829-0515 (international or local)|
|(707) 829-0104 (fax)|
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at
To comment or ask technical questions about this book, send email to
For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our web site at
This book could not have been created without the guidance, encouragement, and deadlines from our O’Reilly editors. Mike Loukides has been with us from the start, keeping us on track and moving forward. Brett McLaughlin joined later to give the project its final push and polish.
All of the authors are grateful to the NetBeans open source community for giving us the motivation to create this book, and especially to the community members who provided crucial feedback while the book evolved from early drafts to, we hope, a much finer finished product. They include Kevin Anderson, Wendy Blatt, Baerrach bonDierne, Joseph Bowbeer, Vincent Brabant, Mike Braden, Steve Brown, Dan Byers, James W. Y. F. Chan, Maarten Coene, Nicolai Czempin, Joan Friedman, Meg Garrison, Richard Gregor, Tim Halloran, Jirka Hana, Kristen Howe, Mike Hulse, Ben Hutchison, Jan Chalupa, Allan Jacobs, Kyley Jex, Thomas Kellerer, Petr Kuzel, Michael Lam, Louis Luangkesorn, Fiona MacGill, Cal McPherson, Karsten Meier, Francis Perreault, Ignacio Moran Pozzi, John Pramod, Patil Prashant, John Richardson, Georg Riker, Rochelle Roccah, Roxie Rochat, Adrian Romanelli, Phil Sager, Brian Sanders, Scott Schram, Jack Schuster, Bill Seddon, Julian Sinai, Andrew Stevens, Ray Tayek, Josef Templ, Jaroslav Tulach, Bryan Vold, Christopher Webster, and Michael Wever.
There were others whose comments did not go through the email feedback channel or whose names could not be discerned from their email addresses. Please be assured that we greatly appreciated your contributions, even though your name may not be included in this list.
Firstly, I would like to thank my wife, Nikki, who continually supported me through many late nights working on the book. She was there every step of the way, and this accomplishment would not have been possible without her being at my side.
I would also like to thank Tim Boudreau for coming up with the idea for this book and being a real driving force behind the idea becoming a reality.
While contributing to this book, I had the pleasure of meeting some wonderful people who have encouraged and inspired me in many ways. Of these, Vaughn Spurlin and Michael Loukides deserve special mention. They both have kept me writing.
Finally, I would like to thank my family, especially my mother, and friends, especially Eric Staudt, for their never-ending support of me and all my endeavors. Thanks also to God for the talents that he gave me.
Thanks first to my wife, Myrna, whose support and encouragement made the difference between wishing I had time to take on a significant project and actually sitting down and making it happen.
Coauthor Tim Boudreau deserves special notice for getting the project off the ground with the original outline and has my sincere gratitude for inviting me to join.
Finally, thanks to my colleagues at Sun Microsystems for their patience and assistance while I learned about NetBeans and to Sun’s management from Scott McNealy on down for their vision in making the NetBeans phenomenon possible.
Thanks to the ladies and gentlemen of Pure Matrix, Inc., (http://www.purematrix.com/), who were unstinting in their generous loan of network bandwidth, an important consideration for an author constantly downloading new subrevisions of the Java Development Kit and of NetBeans itself.
Thanks also to Jon Erickson, Editor in Chief of Dr. Dobb’s Journal, (http://www.ddj.com/), who has offered guidance and support to my writing projects over the past 12 years.
And thanks to my mom and dad, Mindell S., and Dr. Harry J. Woehr, for their encouragement and support. Born in the Roaring ‘Twenties, they understand not a line of my technical writing, but they always buy a copy anyway.
Thanks go to Sun Microsystems for tolerating my peregrinations during the writing of this book, and to Michael Loukides and Brett McLaughlin among other staff at O’Reilly for their amazing patience, competence, and all-around cheer.
I was tickled pink by the number of detailed and helpful comments we received during the public review cycle for this book. Several people sent lengthy and well-thought-out reviews of many consecutive chapters—quite a lot of work, and completely volunteer. We can only hope that whatever wisdom lives in this book in tandem with the NetBeans community will pay them back threefold for their time.
Thank you to the tireless creators of Emacs, DocBook XSL, Xalan, the GIMP, CVS, Ant, and the many other free tools whose quiet reliability helped give this book a tangible form.
Nothing would have been written had it not been for the support of friends to distract me during fits of writer’s block. You know who you are, but I will thank Kristy anyway.
I would finally like to thank my parents for paying my way through college and all that stuff. It wasn’t wasted.
First and foremost, I thank my coauthor, colleague, and dear friend Jesse Glick, the accidental linguist. He has definitely been guru and I apprentice through the arduous process of writing this book. How could one not enjoy working with a colleague who wrote a Java method, the name of which was a single character in Sanskrit, just to see if he could? And for educating me in the dangers of indoor acid rain. Also thanks to Danese Cooper, without whom this project would never been started, Mike Loukides and Brett from O’Reilly, my coauthors, and the many reviewers named above, whose feedback helped make this book what it is.
Further, in no particular order:
Jon Locke—for introducing me to TRS-80 Basic in 1982, being my partner in crime as 13 year olds with a pre-Internet startup, with fond memories of selling 5 1/4-inch floppies in sandwich baggies, discovering 1K digital audio sampling through the cassette port, and arguing over printing the documentation in letter quality mode because it would take three days on the dot-matrix printer.
Kami Pazderniková—for giving me the extra excuse I needed to move to a country I love.
Jarda Tulach—for nearly killing me with drunken bicycling in the mountains—or was it when I stole your swimming cap? Regardless, it’s rare and wonderful to have such friends.
Doug Finn and Todd Hebert and all the others in Western Mass—for actually supporting my crazy decision to give up life as a well-compensated contractor and go pursue the crazy idea of working for a startup in the Czech Republic for almost no money. Maybe now we’ll have some time to record some music...
Evan Adams—for being a mentor and friend and providing a roadmap and sometimes unwelcome advice for an independent-minded and often unruly former contractor, on how to survive and thrive in Dilbert-land.
Ian Formánek—for being a friend, fellow musician, and manager extraordinaire. You have a surfeit of taste! That is, however, curable with medication...
Harold Wolfe and the others at Helios Custom Training—who gave me my first taste of the joys and horrors of doing jobs for huge corporations. The debt is mine; I learned more than I thought I was learning, and in return was far more of a pain in the ass than you deserved.
And all of the other people who have been part of my life over the course of getting the book done: Mike Boyer, George Dvôrák, Mike Gisondi, Monika Mayová, Bill Moffitt, Dan Roberts, Katka Rychtariková, and my tolerant roommates Jan Kratochvil and Karel Zatloukal. Special thanks to Don Bruce and Tracy Feldstein for letting me squat in their home and be “office gnome” for most of April 2002! And finally, thanks to the NetBeans community and Sun Microsystems for making NetBeans a project worth participating in and writing about. And last, but certainly not least, to my parents, for everything.