Java: The Good Parts

Preface

This is yet another book about the Java Programming Language and the Java Programming Environment. As one of the most popular programming languages in use today, Java has already been the subject of a lot of books. On the day this sentence was written, a search on Amazon for books about “Java programming” returned 11,978 results. So why does there need to be another?

The premise of this book is that Java, after some 15 years of development, has become a large and rather complex language and environment. The language itself has seen considerable growth since the time it was introduced. The libraries associated with the language have grown even more, and the requirements of upward compatibility have meant that while many things have been added, very little has been taken away. The curse of any major piece of software is that to survive, it must become popular, but in becoming popular, the software is required not to change in such a way that it would break things that depend upon it. This would be fine if software could be made perfect from the start, but it doesn’t work that way. All software is an attempt to get things right, and each attempt is more or less successful. Even if a piece of software were perfect when it was first released, users would find new ways to use that software (or the environment in which it was used would change) so that it would not remain perfect. So we (the programmers) try to make the software better, which means that we add things, which means that over time, all software is subject to a buildup of crud.

This book is an attempt to pick out some of the very best parts about Java (both the language and the environment) and talk about how to use those parts and why they are good. This isn’t to say that the parts of Java that won’t be talked about in this book aren’t good; it means that the parts I will be talking about differentiate Java from many other languages, and do so in a way that makes Java particularly valuable for the kind of work I and many software engineers do.

Java and Me

My own history with Java goes back to when I first joined Sun Labs^[1] in March of 1992. At that time, there was a secret project, part of which was a new programming language. The language, then called Oak, was a variant of C++ designed for work in embedded devices, but it seemed to have some promise as a general-purpose language. At that time, there were a lot of projects that were looking at alternative object-oriented system languages. The dominant language of that ilk was C++, but there was considerable dissatisfaction with the complexity that was beginning to accrue to that language (and this was before the addition of templates).

I looked at the Oak language, but at the time, it seemed too unstable to be a reasonable tool for the work I was starting to do in distributed systems. Adopting it for our work would have been an example of what was known in the lab as Error 33, the error of basing the success of one research project on the success of a different, as yet unfinished, research project. I filed away the documentation on the language, and my group moved on, doing our research in Modula-3.

I next saw Java about 18 months later, as part of an internal review exercise known as Language Day. By then, the Oak language was the only surviving part of the earlier, larger project on embedded systems, and had moved to Sun Labs as its organizational home. Burt Sutherland, the director of Sun Labs, realized that he had at least four language projects going on in his small lab, and so organized a day in which each of the projects could be presented. His hope was to give each project some exposure, and perhaps to get some cross-fertilization and consolidation among the projects. As the lead of a group that was using yet another language, I was invited to participate as well.

I’m not sure what the official result of Language Day was, but it did give me a second look at Oak, which had matured and stabilized considerably since I had last seen it. My group was looking for a new language at the time, since support for Modula-3 was becoming harder and harder to get. So we decided to switch our research language to Oak. At the time, it seemed like a minor (and only somewhat risky) instance of Error 33; I remember writing an email to the lab director arguing that it was acceptable for my group to be using Oak, because as a research group, it was all right for us to use a language that wasn’t commercially viable.

This was just a couple of months before Oak became Java, before applets were first seen in a browser, and before Java as a language and an environment exploded. I became part of a Sun-wide group (headed by Bill Joy) that tried to plot out the trajectory of the language. I was also asked to be part of a group doing the first formal review of the language, which led to some changes to the basic language design.

It is hard to remember those early days when Java went from an obscure programming language to a phenomenon seemingly overnight. For those who knew anything about the language, or even just wanted in on the excitement, it became an all-hands-on-deck experience. This was also the time that the World Wide Web was growing exponentially, and the growth of the Web and the growth of Java seemed to be somehow joined. Developments in the language became national news. I can’t remember anything like it before or since.

My group was soon pulled out of Sun Labs to become the core of the East Coast branch of the Java software organization, working on some of the distributed libraries for Java. While I’ve floated around various parts of Sun over the last 15 years (and am now back where I started, in Sun Labs), I’ve not switched my main language in that time. I’ve participated in internal discussions of what was to be added to the language and the libraries, saw the formation of the Java Community Process, and saw the platform split into Enterprise, Standard, and Micro editions. I’ve given more talks at JavaOne than there have been JavaOnes, and have also given talks on Java at conferences in Japan, Italy, and England.

During all of this, I’ve spent a lot of time thinking about what makes Java an interesting or enjoyable language and environment in which to work, and what parts of the language get in the way of that interest and enjoyment. I’ve argued, both successfully and not, for the inclusion or exclusion of certain features. And I’ve written a fair amount of code, and read far more, often written by engineers who are far more expressive with the language than I. Java is not the only language that I use, but when I turn to some other and then return, it is like coming home—I always feel comfortable, even if there are quirks and topics that need to be avoided.

You, the Audience

This book is not intended as a mechanism for teaching the reader Java. I assume that you are familiar with the syntax of the language and the basic concepts of object-oriented programming. I also assume that you have some background in the libraries that make up the Java language. The intent of this book is not to teach you completely new things, but to remind you of things that you already knew but may have forgotten, or to get you to see things that you had already thought about in a new light. For those who are just starting with Java, I hope that this book can show some features that you should learn first. For the experienced Java programmer, I hope that this book will serve as a focusing function. You may have different parts of the language that you think are the good parts, or you may think that some things I like are features that make the language worse. But if this book can get you to think about what is good and not so good in the language, then it serves its purpose.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.

Using Code Examples

This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Java: The Good Parts, by Jim Waldo. Copyright 2010 Jim Waldo, 978-0-596-80373-5.”

If you feel your use of code examples falls outside fair use or the permission given here, feel free to contact us at [e-mail].

How to Contact Us

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, 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:

http://oreilly.com/catalog/9780596803735

To comment or ask technical questions about this book, send email to:

[e-mail]

For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our website at:

http://oreilly.com

Safari® Books Online

Note

Safari Books Online is an on-demand digital library that lets you easily search over 7,500 technology and creative reference books and videos to find the answers you need quickly.

With a subscription, you can read any page and watch any video from our library online. Read books on your cell phone and mobile devices. Access new titles before they are available for print, and get exclusive access to manuscripts in development and post feedback for the authors. Copy and paste code samples, organize your favorites, download chapters, bookmark key sections, create notes, print out pages, and benefit from tons of other time-saving features.

O’Reilly Media has uploaded this book to the Safari Books Online service. To have full digital access to this book and others on similar topics from O’Reilly and other publishers, sign up for free at http://my.safaribooksonline.com.

Acknowledgments

One of the best things about participating in the last 15 years of Java development has been the cast of characters that it brought me into contact with. James Gosling built a beautiful language and attracted quite a varied group of engineers, managers, marketing people, and assorted others. There were many who were brilliant, some less so, but they were all interesting. There were heroes and villains, sinners and saints, and all sorts in between. Some became good friends, others became worthy adversaries, but all contributed to the language, the environment, and the experience.

Any acknowledgment that singles out one or more of them by name would be unfair, idiosyncratic, and incomplete, even if it is just those who I remember being particularly important to me. But I’ll do it anyway. The ones that I remember best and most fondly are those who I worked with most closely, and include John McClain, Peter Jones, and Ann Wollrath. Without them, my understanding of Java would be very different than it is now.

I must also acknowledge the support and forbearance of my wife, Susan Mitchell, whose encouragement and support (and willingness to allow me to disappear for long periods of time when I was supposedly not at work) made this book, and so much more, possible.

Any project of this size requires a cheerleader, scold, and sounding board; Mike Loukides, my editor at O’Reilly, filled all of these roles and others. I would also like to thank my technical reviewers who found numerous places that would have been embarrassing had they been committed to print. The book is better because of them; where it is not, the fault is mine.

Finally, I would like to dedicate this book to the memory of Sun Microsystems, Inc., the company that was the home of the original Java development. It was never clear in the progress of Java (and much else) what was intended and what happened in spite of the best efforts of the organization. But the results were sometimes spectacular, and it was one hell of a ride. I miss it already.

---

^[1] Officially, Sun Microsystems Laboratories, Inc.