Java: The Good Parts
Jim Waldo
Beijing Cambridge Farnham Kln Sebastopol Tokyo
Special Upgrade Offer
If you purchased this ebook directly from oreilly.com, you have the following benefits:
DRM-free ebooksuse your ebooks across devices without restrictions or limitations
Multiple formatsuse on your laptop, tablet, or phone
Lifetime access, with free updates
Dropbox syncingyour files, anywhere
If you purchased this ebook from another retailer, you can upgrade your ebook to take advantage of all these benefits for just $4.99. to access your ebook upgrade.
Please note that upgrade offers are not available from sample content.
A Note Regarding Supplemental Files
Supplemental files and examples for this book can be found at http://examples.oreilly.com/9780596803742/. Please use a standard desktop web browser to access these files, as they may not be accessible from all ereader devices.
All code files or examples referenced in the book will be available online. For physical books that ship with an accompanying disc, whenever possible, weve posted all CD/DVD content. Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to .
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 doesnt 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 isnt to say that the parts of Java that wont be talked about in this book arent 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
] 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.
Im 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 wasnt 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 cant 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 Ive floated around various parts of Sun over the last 15 years (and am now back where I started, in Sun Labs), Ive not switched my main language in that time. Ive 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. Ive 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, Ive 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. Ive argued, both successfully and not, for the inclusion or exclusion of certain features. And Ive 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 homeI always feel comfortable, even if there are quirks and topics that need to be avoided.