O'Reilly - Learning Java.pdf

Learning Java Pat Niemeyer Jonathan Knudsen Publisher: O'Reilly First Edition May 2000 ISBN: 1-56592-718-4, 722 pages For programmers either just migrating to Java or alrea...

Learning Java Pat Niemeyer Jonathan Knudsen Publisher: O'Reilly First Edition May 2000 ISBN: 1-56592-718-4, 722 pages For programmers either just migrating to Java or already working steadily in the forefront of Java development, Learning Java gives a clear, systematic overview of the Java 2 Standard Edition. It covers the essentials of hot topics like Swing and JFC; describes new tools for signing applets; and shows how to write networked clients and Copyright servers, servlets, and JavaBeans as state-of-the-art user interfaces. Table of Contents Includes a CD-ROM containing example code and JBuilder for Index Windows and Solaris. Full Description About the Author Reviews Examples Reader reviews Errata Learning Java Preface New Developments Audience Using This Book Getting Wired Conventions Used in This Book How to Contact Us Acknowledgments 1. Yet Another Language? 1.1 Enter Java 1.2 A Virtual Machine 1.3 Java Compared with Other Languages 1.4 Safety of Design 1.5 Safety of Implementation 1.6 Application and User-Level Security 1.7 Java and the World Wide Web 1.8 Java as a General Application Language 1.9 A Java Road Map 2. A First Application 2.1 HelloJava1 2.2 HelloJava2: The Sequel 2.3 HelloJava3: The Button Strikes! 2.4 HelloJava4: Netscape's Revenge 3. Tools of the Trade 3.1 The Java Interpreter 3.2 Policy Files 3.3 The Class Path 3.4 The Java Compiler 3.5 Java Archive (JAR) Files 4. The Java Language 4.1 Text Encoding 4.2 Comments 4.3 Types 4.4 Statements and Expressions 4.5 Exceptions 4.6 Arrays 5. Objects in Java 5.1 Classes 5.2 Methods 5.3 Object Creation 5.4 Object Destruction 6. Relationships Among Classes 6.1 Subclassing and Inheritance 6.2 Interfaces 6.3 Packages and Compilation Units 6.4 Visibility of Variables and Methods 6.5 Arrays and the Class Hierarchy 6.6 Inner Classes 7. Working with Objects and Classes 7.1 The Object Class 7.2 The Class Class 7.3 Reflection 8. Threads 8.1 Introducing Threads 8.2 Threads in Applets 8.3 Synchronization 8.4 Scheduling and Priority 8.5 Thread Groups 9. Basic Utility Classes 9.1 Strings 9.2 Math Utilities 9.3 Dates 9.4 Timers 9.5 Collections 9.6 Properties 9.7 The Security Manager 9.8 Internationalization 10. Input/Output Facilities  10.1 Streams 10.2 Files 10.3 Serialization 10.4 Data Compression 11. Network Programming with Sockets and RMI 11.1 Sockets 11.2 Datagram Sockets 11.3 Simple Serialized Object Protocols 11.4 Remote Method Invocation (RMI) 12. Programming for the Web 12.1 Uniform Resource Locators (URLs) 12.2 The URL Class 12.3 Web Browsers and Handlers 12.4 Talking to CGI Programs and Servlets 12.5 Implementing Servlets 13. Swing 13.1 Components 13.2 Containers 13.3 Events 13.4 Event Summary 13.5 Multithreading in Swing 14. Using Swing Components 14.1 Buttons and Labels 14.2 Checkboxes and Radio Buttons 14.3 Lists and Combo Boxes 14.4 Borders 14.5 Menus 14.6 The PopupMenu Class 14.7 The JScrollPane Class 14.8 The JSplitPane Class 14.9 The JTabbedPane Class 14.10 Scrollbars and Sliders 14.11 Dialogs 15. More Swing Components 15.1 Text Components 15.2 Trees 15.3 Tables 15.4 Desktops 15.5 Pluggable Look-and-Feel 15.6 Creating Custom Components 16. Layout Managers 16.1 FlowLayout 16.2 GridLayout 16.3 BorderLayout 16.4 BoxLayout 16.5 CardLayout 16.6 GridBagLayout  16.7 Nonstandard Layout Managers 16.8 Absolute Positioning 17. Drawing with the 2D API 17.1 The Big Picture 17.2 The Rendering Pipeline 17.3 A Quick Tour of Java 2D 17.4 Filling Shapes 17.5 Stroking Shape Outlines 17.6 Using Fonts 17.7 Displaying Images 17.8 Using Drawing Techniques 17.9 Printing 18. Working with Images and Other Media 18.1 Implementing an ImageObserver 18.2 Using a MediaTracker 18.3 Producing Image Data 18.4 Filtering Image Data 18.5 Working with Audio 18.6 Working with Movies 19. Java Beans 19.1 What's a Bean? 19.2 Building Beans 19.3 Hand-Coding with Beans 19.4 Putting Reflection to Work 19.5 BeanContext and BeanContextServices 19.6 The Java Activation Framework 19.7 Enterprise JavaBeans 20. Applets 20.1 The JApplet Class 20.2 The Tag 20.3 Using the Java Plug-in 20.4 Using Digital Signatures 21. Glossary A. Content and Protocol Handlers A.1 Writing a Content Handler A.2 Writing a Protocol Handler B. BeanShell: Simple Java Scripting B.1 Running BeanShell B.2 Java Statements and Expressions B.3 BeanShell Commands B.4 Scripted Methods and Objects B.5 Learning More... Colophon Preface This book is about the Java™ language and programming environment. If you've been at all active on the Internet in the past few years, you've heard a lot about Java. It's one of the most exciting developments in the history of the Internet, rivaling the creation of the World Wide Web. Java became the darling of the Internet programming community as soon as the alpha version was released. Immediately, thousands of people were writing Java applets to add to their web pages. Interest in Java only grew with time, and support for Java in Netscape Navigator guaranteed it would be a permanent part of the Net scene. What, then, is Java? Java is a network programming language that was developed by Sun Microsystems. It's already in widespread use for creating animated and interactive web pages. However, this is only the start. The Java language and environment are rich enough to support entirely new kinds of applications, like dynamically extensible browsers and mobile agents. There are entirely new kinds of computer platforms being developed around Java (handheld devices and network computers) that download all their software over the network. In the coming years, we'll see what Java is capable of doing; fancy web pages are fun and interesting, but they certainly aren't the end of the story. If Java is successful (and that isn't a foregone conclusion), it could change the way we think about computing in fundamental ways. This book gives you a head start on a lot of Java fundamentals. Learning Java attempts to live up to its name by mapping out the Java language, its class libraries, programming techniques, and idioms. We'll dig deep into interesting areas and at least scratch the surface of the rest. Other titles in the O'Reilly & Associates Java Series will pick up where we leave off and provide more comprehensive information on specific areas and applications of Java. Whenever possible, we'll provide meaningful, realistic examples and avoid cataloging features. The examples are simple but hint at what can be done. We won't be developing the next great "killer app" in these pages, but we hope to give you a starting point for many hours of experimentation and tinkering that will lead you to learn more on your own. New Developments This book, Learning Java, is actually the third edition—reworked and retitled—of O'Reilly's popular Exploring Java. We've de-emphasized web-page applets this time around, reflecting their diminishing role over the past couple of years in creating "smart" web pages. Other technologies have filled in the gap: JavaScript on the client side, and Java servlets and Active Server Pages on the server side. We cover the most interesting features of Sun's newest release of Java, officially called Java 2 SDK Version 1.3. (In the old days, it would have been called "JDK," for "Java development kit;" we use the newer, officially blessed "SDK," for "software development kit," throughout this book.) These features include servlets, the Java Media Framework ( JMF), timers, the collections, 2D graphics, and image-processing APIs, using the Java security manager, and using Java 2 signed applets. Another important change, though not as recent as SDK 1.3, is the ascendancy of Java Swing as the main API for graphical user interface programming. Much of the material relating to AWT, Java's original GUI programming interface, has been recast and updated to use Swing facilities. Audience This book is for computer professionals, students, technical people, and Finnish hackers. It's for everyone who has a need for hands-on experience with the Java language with an eye toward building real applications. This book could also be considered a crash course in object-oriented programming; as you learn about Java, you'll also learn a powerful and practical approach to object-oriented software development. Superficially, Java looks like C or C++, so you'll be in the best position to use this book if you've some experience with one of these languages. If you do not, you might want to refer to books like O'Reilly's Practical C Programming for a more thorough treatment of basic C syntax. However, don't make too much of the syntactic similarities between Java and C or C++. In many respects, Java acts like more dynamic languages such as Smalltalk and Lisp. Knowledge of another object- oriented programming language should certainly help, although you may have to change some ideas and unlearn a few habits. Java is considerably simpler than languages like C++ and Smalltalk. Although we encourage you to take a broad view, you would have every right to be disappointed if we ignored the Web. A substantial part of this book does discuss Java as a language for World Wide Web applications, so you should be familiar with the basic ideas behind web browsers, servers, and web documents. Using This Book This book is organized roughly as follows: Chapter 1 and Chapter 2 provide a basic introduction to Java concepts and a tutorial to give you a jump start on Java programming. Chapter 3 discusses tools for developing with Java (the compiler, the interpreter, the JAR file package). It also covers important concepts such as embedding Java code in HTML support and object signing. Chapter 4 through Chapter 8 describe the Java language itself. Chapter 8 covers the language's thread facilities, which should be of particular interest to advanced programmers. Chapter 9 and Chapter 10 cover much of the core API. Chapter 9 describes basic utilities, and Chapter 10 covers I/O facilities. Chapter 11 and Chapter 12 cover Java networking, including sockets, URLs, and remote method invocation (RMI). Chapter 13 through Chapter 18 cover the Abstract Window Toolkit (AWT) and Swing, which provide graphical user interface (GUI) and image support. Chapter 19 covers the JavaBeans™ component architecture. Chapter 20 covers applets, the area in which Java saw its initial success. If you're like us, you don't read books from front to back. If you're really like us, you usually don't read the preface at all. However, on the off chance that you will see this in time, here are a few suggestions. If you are an experienced programmer who has to learn Java in the next five minutes, you are probably looking for the examples. You might want to start by glancing at the tutorial in Chapter 2. If that doesn't float your boat, you should at least look at the information in Chapter 3, which tells you how to use the compiler and interpreter, and gives you the basics of a standalone Java application. This should get you started. Chapter 11 and Chapter 12 are essential if you are interested in writing advanced networked applications. This is probably the most interesting and important part of Java. Chapter 13 though Chapter 19 discuss Java's graphics features and component architecture. You should read this carefully if you are interested in Java applications for the Web. Getting Wired There are many online sources for information about Java. Sun Microsystem's official web site for Java topics is http://java.sun.com; look here for the latest news, updates, and Java releases. This is where you'll find the Java Software Development Kit (SDK), which includes the compiler, the interpreter, and other tools. Another good source of Java information, including free applets, utility classes, and applications, is the Gamelan site, run by EarthWeb; its URL is http://www.gamelan.com. You should also visit O'Reilly & Associates' Java site at http://java.oreilly.com. There you'll find information about other books in O'Reilly's Java Series, and a pointer to the home page for Learning Java, http://www.oreilly.com/catalog/learnjava/, where you'll find the source code examples for this book. The comp.lang.java newsgroup can be a good source of information and announcements, and a place to ask intelligent questions. Conventions Used in This Book The font conventions used in this book are quite simple. Italic is used for: Unix pathnames, filenames, and program names Internet addresses, such as domain names and URLs New terms where they are defined Boldface is used for: Names of GUI buttons and menus Constant width is used for: Anything that might appear in a Java program, including method names, variable names, and class names Command lines and options that should be typed verbatim on the screen Tags that might appear in an HTML document Constant width bold is used for: In code examples, text that is typed by the user In the main body of text, we always use a pair of empty parentheses after a method name to distinguish methods from variables and other creatures. In the Java source listings, we follow the coding conventions most frequently used in the Java community. Class names begin with capital letters; variable and method names begin with lowercase. All the letters in the names of constants are capitalized. We don't use underscores to separate words in a long name; following common practice, we capitalize individual words (after the first) and run the words together. For example: thisIsAVariable, thisIsAMethod( ), ThisIsAClass, and THISISACONSTANT. How to Contact Us We have tested and verified all the information in this book to the best of our abilities, but you may find that features have changed or that we have let errors slip through the production of the book. Please let us know of any errors that you find, as well as suggestions for future editions, by writing to: O'Reilly & Associates, Inc. 101 Morris St. Sebastopol, CA 95472 1-800-998-9938 (in the U.S. or Canada) 1-707-829-0515 (international/local) 1-707-829-0104 (fax) You can also send messages electronically. To be put on our mailing list or to request a catalog, send email to: [email protected] To ask technical questions or to comment on the book, send email to: [email protected] We have a web site for the book, where we'll list examples, errata, and any plans for future editions. You can access this page at: http://www.oreilly.com/catalog/learnjava/ For more information about this book and others, see the O'Reilly web site: http://www.oreilly.com Chapter 1. Yet Another Language? The greatest challenges and most exciting opportunities for software developers today lie in harnessing the power of networks. Applications created today, whatever their intended scope or audience, will almost certainly be run on machines linked by a global network of computing resources. The increasing importance of networks is placing new demands on existing tools and fueling the demand for a rapidly growing list of completely new kinds of applications. We want software that works—consistently, anywhere, on any platform—and that plays well with other applications. We want dynamic applications that take advantage of a connected world, capable of accessing disparate and distributed information sources. We want truly distributed software that can be extended and upgraded seamlessly. We want intelligent applications—like autonomous agents that can roam the Net for us, ferreting out information and serving as electronic emissaries. We know, to some extent, what we want. So why don't we have it? The problem has been that the tools for building these applications have fallen short. The requirements of speed and portability have been, for the most part, mutually exclusive, and security has been largely ignored or misunderstood. There are truly portable languages, but they are mostly bulky, interpreted, and slow. These languages are popular as much for their high-level functionality as for their portability. And there are fast languages, but they usually provide speed by binding themselves to particular platforms, so they can meet the portability issue only halfway. There are even a few recent safe languages, but they are primarily offshoots of the portable languages and suffer from the same problems. 1.1 Enter Java The Java™ programming language, developed at Sun Microsystems under the guidance of Net luminaries James Gosling and Bill Joy, is designed to be a machine-independent programming language that is both safe enough to traverse networks and powerful enough to replace native executable code. Java addresses the issues raised here and may help us start building the kinds of applications we want. Initially, most of the enthusiasm for Java centered around its capabilities for building embedded applications for the World Wide Web; these applications are called applets. Applets could be independent programs in themselves, or sophisticated frontends to programs running on a server. More recently, interest has shifted to other areas. With Java 2, Java has the most sophisticated toolkit for building graphical user interfaces; this development has allowed Java to become a popular platform for developing traditional application software. Java has also become an important platform for server-side applications, using the servlet interface, and for enterprise applications using technologies like Enterprise JavaBeans™. And Java is the platform of choice for modern distributed applications. This book shows you how to use Java to accomplish real programming tasks, such as building networked applications and creating functional user interfaces. There's still a chapter devoted to applets; they may become more important again when the Java 2 (and subsequent) versions of the Java platform are more widely distributed in web browsers. 1.1.1 Java's Origins The seeds of Java were planted in 1990 by Sun Microsystems patriarch and chief researcher, Bill Joy. Since Sun's inception in the early '80s, it has steadily pushed one idea: "The network is the computer." At the time though, Sun was competing in a relatively small workstation market, while Microsoft was beginning its domination of the more mainstream, Intel-based PC world. When Sun missed the boat on the PC revolution, Joy retreated to Aspen, Colorado, to work on advanced research. He was committed to accomplishing complex tasks with simple software, and founded the aptly named Sun Aspen Smallworks. Of the original members of the small team of programmers assembled in Aspen, James Gosling is the one who will be remembered as the father of Java. Gosling first made a name for himself in the early '80s as the author of Gosling Emacs, the first version of the popular Emacs editor that was written in C and ran under Unix. Gosling Emacs became popular, but was soon eclipsed by a free version, GNU Emacs, written by Emacs's original designer. By that time, Gosling had moved on to design Sun's NeWS window system, which briefly contended with the X Window System for control of the Unix graphical user interface (GUI) desktop in 1987. While some people would argue that NeWS was superior to X, NeWS lost out because Sun kept it proprietary and didn't publish source code, while the primary developers of X formed the X Consortium and took the opposite approach. Designing NeWS taught Gosling the power of integrating an expressive language with a network- aware windowing GUI. It also taught Sun that the Internet programming community will refuse to accept proprietary standards, no matter how good they may be. The seeds of Java's remarkably permissive licensing scheme were sown by NeWS's failure. Gosling brought what he had learned to Bill Joy's nascent Aspen project, and in 1992, work on the project led to the founding of the Sun subsidiary, FirstPerson, Inc. Its mission was to lead Sun into the world of consumer electronics. The FirstPerson team worked on developing software for information appliances, such as cellular phones and personal digital assistants (PDAs). The goal was to enable the transfer of information and real-time applications over cheap infrared and packet-based networks. Memory and bandwidth limitations dictated small and efficient code. The nature of the applications also demanded they be safe and robust. Gosling and his teammates began programming in C++, but they soon found themselves confounded by a language that was too complex, unwieldy, and insecure for the task. They decided to start from scratch, and Gosling began working on something he dubbed "C++ minus minus." With the foundering of the Apple Newton, it became apparent that the PDA's ship had not yet come in, so Sun shifted FirstPerson's efforts to interactive TV (ITV). The programming language of choice for ITV set-top boxes was the near ancestor of Java, a language called Oak. Even with its elegance and ability to provide safe interactivity, Oak could not salvage the lost cause of ITV. Customers didn't want it, and Sun soon abandoned the concept. At that time, Joy and Gosling got together to decide on a new strategy for their language. It was 1993, and the explosion of interest in the Internet, and the World Wide Web in particular, presented a new opportunity. Oak was small, robust, architecture-independent, and object- oriented. As it happens, these are also the requirements for a universal, network-savvy programming language. Sun quickly changed focus, and with a little retooling, Oak became Java. 1.1.2 Future Buzz? It would not be overdoing it to say that Java has caught on like wildfire. Even before its first official release, while Java was still a non-product, nearly every major industry player jumped on the Java bandwagon. Java licensees included Microsoft, Intel, IBM, and virtually all major hardware and software vendors. (That's not to say that everything has been coming up roses. Even with all of this support Java has taken a lot of knocks and had some growing pains during its first few years.) As we begin looking at the Java architecture, you'll see that much of what is exciting about Java comes from the self-contained, virtual machine environment in which Java applications run. Java has been carefully designed so that this supporting architecture can be implemented either in software, for existing computer platforms, or in customized hardware, for new kinds of devices. Sun and other industry giants are producing fast Java chips and microprocessors tailored to run media-rich Java applications. Hardware implementations of Java could power inexpensive network terminals, PDAs, and other information appliances, to take advantage of transportable Java applications. Software implementations of Java are available now for portable computing devices like the popular Palm™ PDA. Many people see Java as part of a trend toward cheap, Internet-based, "operating system-less" appliances that will weave the Net into more and more consumer-related areas. The first attempts at marketing "network computers" as alternatives to the standard PC have not gone very well. (The combination of Windows and cheap PC hardware form a formidable barrier.) But the desktop is only one corner of the network. Only time will tell what people will do with Java, but it's probably worth at least a passing thought that the applet you write today might well be running on someone's wristwatch tomorrow. If that seems too futuristic, remember that you can already get "smart cards" and "wearable" devices like rings and dog tags that have Java interpreters embedded in them. These devices are capable of doing everything from financial transactions (paying a hotel bill) to unlocking a door (the door to your hotel room) to rerouting phone calls (so your hotel room receives your business calls). The hardware is already here; it can't be long before the rest of the software infrastructure begins to take advantage of it. A Java wristwatch is not a silly notion. 1.2 A Virtual Machine Java is both a compiled and an interpreted language. Java source code is turned into simple binary instructions, much like ordinary microprocessor machine code. However, whereas C or C++ source is refined to native instructions for a particular model of processor, Java source is compiled into a universal format—instructions for a virtual machine. Compiled Java byte-code, also called J-code, is executed by a Java runtime interpreter. The runtime system performs all the normal activities of a real processor, but it does so in a safe, virtual environment. It executes the stack-based instruction set and manages a storage heap. It creates and manipulates primitive datatypes, and loads and invokes newly referenced blocks of code. Most importantly, it does all this in accordance with a strictly defined open specification that can be implemented by anyone who wants to produce a Java-compliant virtual machine. Together, the virtual machine and language definition provide a complete specification. There are no features of Java left undefined or implementation-dependent. For example, Java specifies the sizes of all its primitive data types, rather than leave it up to each implementation. The Java interpreter is relatively lightweight and small; it can be implemented in whatever form is desirable for a particular platform. On most systems, the interpreter is written in a fast, natively compiled language like C or C++. The interpreter can be run as a separate application, or it can be embedded in another piece of software, such as a web browser. All of this means that Java code is implicitly portable. The same Java application byte-code can run on any platform that provides a Java runtime environment, as shown in Figure 1.1. You don't have to produce alternative versions of your application for different platforms, and you don't have to distribute source code to end users. Figure 1.1. The Java runtime environment The fundamental unit of Java code is the class. As in other object-oriented languages, classes are application components that hold executable code and data. Compiled Java classes are distributed in a universal binary format that contains Java byte-code and other class information. Classes can be maintained discretely and stored in files or archives on a local system or on a network server. Classes are located and loaded dynamically at runtime, as they are needed by an application. In addition to the platform-specific runtime system, Java has a number of fundamental classes that contain architecture-dependent methods. These native methods serve as the gateway between the Java virtual machine and the real world. They are implemented in a natively compiled language on the host platform. They provide access to resources such as the network, the windowing system, and the host filesystem. The rest of Java is written entirely in Java, and is therefore portable. This includes fundamental Java utilities like the Java compiler and Sun's HotJava web browser, which are also Java applications and are therefore available on all Java platforms. Historically, interpreters have been considered slow, but because the Java interpreter runs compiled byte-code, Java is a relatively fast interpreted language. More importantly, Java has also been designed so that software implementations of the runtime system can optimize their performance by compiling byte-code to native machine code on the fly. This is called just-in-time compilation. Sun claims that with just-in-time compilation, Java code can execute nearly as fast as native compiled code and maintain its transportability and security. There is only one true performance hit that compiled Java code will always suffer for the sake of security — array bounds checking. But on the other hand, some of the basic design features of Java place more information in the hands of the compiler, which allows for certain kinds of optimizations not possible in C or C++. The latest twist in compilation techniques is a new virtual machine that Sun calls HotSpot. The problem with a traditional just-in-time compilation is that optimizing code takes time, and is extremely important for good performance on modern computer hardware. So a just-in-time compiler can produce decent results, but can never afford to take the time necessary to do a good job of optimization. HotSpot uses a trick called "adaptive compilation" to solve this problem. If you look at what programs actually spend their time doing, it turns out that they spend almost all of their time executing a relatively small part of the code again and again. The chunk of code that is executed repeatedly may only be a small percent of the total program, but its behavior determines the program's overall performance. To take advantage of this fact, HotSpot starts out as a normal Java byte code interpreter, but with a difference: it measures (profiles) the code as it is executing, to see what parts are being executed repeatedly. Once it knows which parts of the code are crucial to the performance, HotSpot compiles those sections—and only those sections—into true machine code. Since it only compiles a small portion of the program into machine code, it can afford to take the time necessary to optimize those portions. The rest of the program may not need to be compiled at all—just interpreted—saving memory and time. The technology for doing this is very complex, but the idea is essentially simple: optimize the parts of the program that need to go fast, and don't worry about the rest. Another advantage of using an adaptive compiler at runtime is that it can make novel kinds of optimizations that a static (compile time only) compiler cannot dream of. 1.3 Java Compared with Other Languages Java is a new language, but it draws on many years of programming experience with other languages in its choice of features. So a lot can be said in comparing and contrasting Java with other languages. There are at least three pillars necessary to support a universal language for network programming today: portability, speed, and security. Figure 1.2 shows how Java compares to other languages. Figure 1.2. Programming languages compared You may have heard that Java is a lot like C or C++, but that's really not true, except at a superficial level. When you first look at Java code, you'll see that the basic syntax looks a lot like C or C++. But that's where the similarities end. Java is by no means a direct descendant of C or a next-generation C++. If you compare language features, you'll see that Java actually has more in common with languages like Smalltalk and Lisp. In fact, Java's implementation is about as far from native C as you can imagine. The surface-level similarities to C and C++ are worth noting, however. Java borrows heavily from C and C++ syntax, so you'll see lots of familiar language constructs, including an abundance of curly braces and semicolons. Java also subscribes to the C philosophy that a good language should be compact; in other words, it should be sufficiently small and regular so a programmer can hold all the language's capabilities in his or her head at once. Just as C is extensible with libraries, packages of Java classes can be added to the core language components. C has been successful because it provides a reasonably featureful programming environment, with high performance and an acceptable degree of portability. Java also tries to balance functionality, speed, and portability, but it does so in a very different way. C trades functionality for portability; Java trades speed for portability. Java also addresses security issues, while C doesn't. Java is an interpreted language, so it won't be as fast as a compiled language like C. But Java is fast enough, especially for interactive, network-based applications, where the application is often idle, waiting for the user to do something or waiting for data from the network. For situations where speed is critical, a Java implementation can optimize performance with just-in-time compilation to byte-code, as previously discussed. Scripting languages, like Perl, Python, Tcl/Tk, and Wksh, are becoming very popular, and for good reason. There's no reason a scripting language could not be suitable for safe, networked applications (e.g., Safe Tcl), but most scripting languages are not designed for serious, large- scale programming. The attraction to scripting languages is that they are dynamic; they are powerful tools for rapid prototyping. Some scripting languages, like awk and Perl, also provide powerful tools for text-processing tasks that more general-purpose languages find unwieldy. Scripting languages are also highly portable. One problem with scripting languages, however, is that they are rather casual about program structure and data typing. Most scripting languages (with a hesitant exception for Perl 5.0 and Python) are not object-oriented. They also have vastly simplified type systems and generally don't provide for sophisticated scoping of variables and functions. These characteristics make them unsuitable for building large, modular applications. Speed is another problem with scripting languages; the high-level, fully interpreted nature of these languages often makes them quite slow. Java offers some of the essential advantages of a scripting language, along with the added benefits of a lower-level language. Incremental development with object-oriented components, combined with Java's simplicity, make it possible to develop applications rapidly and change them easily, with a short concept-to- implementation time. Java also comes with a large base of core classes for common tasks such as building GUIs and doing network communications. But along with these features, Java has the scalability and software-engineering advantages of more static languages. It provides a safe structure on which to build higher-level networked tools and languages. However, don't confuse Java with JavaScript! JavaScript is an object-based scripting language being developed by Netscape and others. It serves as a glue and an "in the document" language for dynamic, interactive HTML-based applications. JavaScript draws its name from its intended integration with Java. You can currently interact with Java applets embedded in HTML using JavaScript. There have been a few portable implementations of JavaScript that would promote it to the level of a general scripting language. For more information on JavaScript, check out Netscape's web site (http://home.netscape.com). As we've already said, Java is similar in design to languages like Smalltalk and Lisp. However, these languages are currently used mostly as research vehicles, rather than for developing large- scale systems. One reason is that they never developed a standard portable binding to operating- system services, like the C standard library or the Java core classes. Smalltalk is compiled to an interpreted byte-code format, and it can be dynamically compiled to native code on the fly, just like Java. But Java improves on the design by using a byte-code verifier to ensure the correctness of compiled Java code. This verifier gives Java a performance advantage over Smalltalk because Java code requires fewer runtime checks. Java's byte-code verifier also helps with security issues, something that Smalltalk doesn't address. Smalltalk is a mature language, though, and Java's designers took lessons from many of its features. Throughout the rest of this chapter, we'll present a bird's-eye view of the Java language. We'll explain what's new and what's not-so-new about Java, how it differs from other languages, and why. 1.4 Safety of Design You have no doubt heard a lot about the fact that Java is designed to be a safe language. But what do we mean by safe? Safe from what or whom? The security features that attract the most attention for Java are those features that make possible new types of dynamically portable software. Java provides several layers of protection from dangerously flawed code, as well as more mischievous things like viruses and Trojan horses. In the next section, we'll take a look at how the Java virtual machine architecture assesses the safety of code before it's run, and how the Java class loader (the byte-code loading mechanism of the Java interpreter) builds a wall around untrusted classes. These features provide the foundation for high-level security policies that allow or disallow various kinds of activities on an application-by-application basis. In this section, though, we'll look at some general features of the Java programming language. Perhaps more important than the specific security features, although often overlooked in the security din, is the safety that Java provides by addressing common design and programming problems. Java is intended to be as safe as possible from the simple mistakes we make ourselves, as well as those we inherit from contractors and third-party software vendors. The goal with Java has been to keep the language simple, provide tools that have demonstrated their usefulness, and let users build more complicated facilities on top of the language when needed. 1.4.1 Syntactic Sweet 'n' Low Java is parsimonious in its features; simplicity rules. Compared to C, Java uses few automatic type coercions, and the ones that remain are simple and well-defined. Unlike C++, Java doesn't allow programmer-defined operator overloading. The string concatenation operator + is the only system-defined, overloaded operator in Java. All methods in Java are like C++ virtual methods, so overridden methods are dynamically selected at runtime. Java doesn't have a preprocessor, so it doesn't have macros, #define statements, or conditional source compilation. These constructs exist in other languages primarily to support platform dependencies, so in that sense they should not be needed in Java. Conditional compilation is also commonly used for debugging purposes. Debugging code can be included directly in your Java source code by making it conditional on a constant (in Java, a variable declared to be static and final). The Java compiler is smart enough to remove this code when it determines that it won't be called. Java provides a well-defined package structure for organizing class files. The package system allows the compiler to handle most of the functionality of the make utility (a sophisticated tool for building executables from source code). The compiler also works with compiled Java classes, because all type information is preserved; there is no need for header files. All of this means that Java code requires little context to read. Indeed, you may sometimes find it faster to look at the Java source code than to refer to class documentation. Java replaces some features that have been troublesome in other languages. For example, Java supports only a single inheritance class hierarchy, but allows multiple inheritance of interfaces. An interface, like an abstract class in C++, specifies some of the behavior of an object without defining its implementation, a powerful mechanism borrowed from Objective C. It allows a class to implement the behavior of the interface, without needing to be a subclass of anything in particular. Interfaces in Java eliminate the need for multiple inheritance of classes, without causing the problems associated with multiple inheritance. As you'll see in Chapter 4, Java is a simple, yet elegant, programming language. 1.4.2 Type Safety and Method Binding One attribute of a language is the kind of type checking it uses. When we categorize a language as static or dynamic we are referring to the amount of information about variable types that is known at compile time versus what is determined while the application is running. In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. The compiler benefits from having enough information to enforce usage rules, so that it can catch many kinds of errors before the code is executed, such as storing a floating-point value in an integer variable. The code doesn't require runtime type checking, so it can be compiled to be small and fast. But statically typed languages are inflexible. They don't support high-level constructs like lists and collections as naturally as languages with dynamic type checking, and they make it impossible for an application to safely import new data types while it's running. In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug. The differences in languages have been likened to the differences among kinds of automobiles. Statically typed languages like C++ are analogous to a sports car—reasonably safe and fast—but useful only if you're driving on a nicely paved road. Highly dynamic languages like Smalltalk are more like an offroad vehicle: they afford you more freedom, but can be somewhat unwieldy. It can be fun (and sometimes faster) to go roaring through the back woods, but you might also get stuck in a ditch or mauled by bears. The credit for the car analogy goes to Marshall P. Cline, author of the C++ FAQ. Another attribute of a language is the way it binds method calls to their definitions. In an early- binding language like C or C++, the definitions of methods are normally bound at compile time, unless the programmer specifies otherwise. Smalltalk, on the other hand, is a late-binding language because it locates the definitions of methods dynamically at runtime. Early-binding is important for performance reasons; an application can run without the overhead incurred by searching method tables at runtime. But late-binding is more flexible. It's also necessary in an object-oriented language, where a subclass can override methods in its superclass, and only the runtime system can determine which method to run. Java provides some of the benefits of both C++ and Smalltalk; it's a statically typed, late-binding language. Every object in Java has a well-defined type that is known at compile time. This means the Java compiler can do the same kind of static type checking and usage analysis as C++. As a result, you can't assign an object to the wrong type of variable or call nonexistent methods on an object. The Java compiler goes even further and prevents you from messing up and trying to use uninitialized variables. However, Java is fully runtime typed as well. The Java runtime system keeps track of all objects and makes it possible to determine their types and relationships during execution. This means you can inspect an object at runtime to determine what it is. Unlike C or C++, casts from one type of object to another are checked by the runtime system, and it's even possible to use completely new kinds of dynamically loaded objects with a level of type safety. Since Java is a late-binding language, all methods are like virtual methods in C++. This makes it possible for a subclass to override methods in its superclass. But Java also allows you to gain the performance benefits of early-binding by explicitly declaring (with the final modifier) that certain methods can't be overridden by subclassing, removing the need for runtime lookup. (Adaptive runtime compilers like HotSpot may be able to eliminate the need for you to worry about this though, as they can detect usage patterns and improve performance automatically, where possible.) 1.4.3 Incremental Development Java carries all data-type and method-signature information with it from its source code to its compiled byte-code form. This means that Java classes can be developed incrementally. Your own Java classes can also be used safely with classes from other sources your compiler has never seen. In other words, you can write new code that references binary class files, without losing the type safety you gain from having the source code. The Java runtime system can load new classes while an application is running, thus providing the capabilities of a dynamic linker. A common irritation with C++ is the "fragile base class" problem. In C++, the implementation of a base class can be effectively frozen by the fact that it has many derived classes; changing the base class may require recompilation of the derived classes. This is an especially difficult problem for developers of class libraries. Java avoids this problem by dynamically locating fields within classes. As long as a class maintains a valid form of its original structure, it can evolve without breaking other classes that are derived from it or that make use of it. 1.4.4 Dynamic Memory Management Some of the most important differences between Java and C or C++ involve how Java manages memory. Java eliminates ad hoc pointers and adds garbage collection and true arrays to the language. These features eliminate many otherwise insurmountable problems with safety, portability, and optimization. Garbage collection alone should save countless programmers from the single largest source of programming errors in C or C++: explicit memory allocation and deallocation. In addition to maintaining objects in memory, the Java runtime system keeps track of all references to those objects. When an object is no longer in use, Java automatically removes it from memory. You can simply ignore objects you no longer use, with confidence that the interpreter will clean them up at an appropriate time. Sun's current implementation of Java uses a conservative mark-and-sweep garbage collector that runs intermittently in the background, which means that most garbage collecting takes place between I/O pauses, mouse clicks, and keyboard hits. Next generation runtime systems like HotSpot have more advanced garbage collection that can even differentiate the usage patterns of objects (such as short-lived versus long-lived) and optimize their collection. Once you get used to garbage collection, you won't go back. Being able to write air-tight C code that juggles memory without dropping any on the floor is an important skill, but once you become addicted to Java you can "realloc" some of those brain cells to new tasks. You may hear people say that Java doesn't have pointers. Strictly speaking, this statement is true, but it's also misleading. What Java provides are references—a safe kind of pointer—and Java is rife with them. A reference is a strongly typed handle for an object. All objects in Java, with the exception of primitive numeric types, are accessed through references. If necessary, you can use references to build all the normal kinds of data structures you're accustomed to building with pointers, such as linked lists, trees, and so forth. The only difference is that with references you have to do so in a type-safe way. Another important difference between a reference and a pointer is that you can't do pointer arithmetic with references (they can only point to specific objects or elements of an array). A reference is an atomic thing; you can't manipulate the value of a reference except by assigning it to an object. References are passed by value, and you can't reference an object through more than a single level of indirection. The protection of references is one of the most fundamental aspects of Java security. It means that Java code has to play by the rules; it can't peek into places it shouldn't. Unlike C or C++ pointers, Java references can point only to class types. There are no pointers to methods. People often complain about this missing feature, but you will find that most tasks that call for pointers to methods, such as callbacks, can be accomplished using interfaces and anonymous adapter classes instead. (We will discuss these in Chapter 6, and in the Swing- related chapters; they are heavily used in tying together graphical user interface components). As of Java 1.1, there is a Method class, which lets you have a reference to a method. This is part of the Java reflection API. You can use a Method object to construct a callback, but it's not the normal way of doing things. Finally, arrays in Java are true, first-class objects. They can be dynamically allocated and assigned like other objects. Arrays know their own size and type, and although you can't directly define or subclass array classes, they do have a well-defined inheritance relationship based on the relationship of their base types. Having true arrays in the language alleviates much of the need for pointer arithmetic like that in C or C++. 1.4.5 Error Handling Java's roots are in networked devices and embedded systems. For these applications, it's important to have robust and intelligent error management. Java has a powerful exception- handling mechanism, somewhat like that in newer implementations of C++. Exceptions provide a more natural and elegant way to handle errors. Exceptions allow you to separate error-handling code from normal code, which makes for cleaner, more readable applications. When an exception occurs, it causes the flow of program execution to be transferred to a predesignated "catcher" block of code. The exception carries with it an object that contains information about the situation that caused the exception. The Java compiler requires that a method either declare the exceptions it can generate or catch and deal with them itself. This promotes error information to the same level of importance as argument and return typing. As a Java programmer, you know precisely what exceptional conditions you must deal with, and you have help from the compiler in writing correct software that doesn't leave them unhandled. 1.4.6 Multithreading Applications today require a high degree of parallelism. Even a very single- minded application can have a complex user interface—which requires concurrent activities. As machines get faster, users become more sensitive to waiting for unrelated tasks that seize control of their time. Threads provide efficient multiprocessing and distribution of tasks for both client and server applications. Java makes threads easy to use because support for them is built into the language. Concurrency is nice, but there's more to programming with threads than just performing multiple tasks simultaneously. In many cases, threads need to be synchronized, which can be tricky without explicit language support. Java supports synchronization based on the monitor and condition model developed by C.A.R. Hoare—a sort of lock and key system for accessing resources. The keyword synchronized designates methods for safe, serialized access within an object. Only one synchronized method within the object may run at a given time. There are also simple, primitive methods for explicit waiting and signaling between threads interested in the same object. Learning to program with threads is an important part of learning to program in Java. See Chapter 8, for a discussion of this topic. For complete coverage of threads, refer to Java Threads, by Scott Oaks and Henry Wong (O'Reilly & Associates). 1.4.7 Scalability At the lowest level, Java programs consist of classes. Classes are intended to be small, modular components. They can be separated physically on different systems, retrieved dynamically, stored in a compressed format, and even cached in various distribution schemes. Over classes, Java provides packages, a layer of structure that groups classes into functional units. Packages provide a naming convention for organizing classes and a second level of organizational control over the visibility of variables and methods in Java applications. Within a package, a class is either publicly visible or protected from outside access. Packages form another type of scope that is closer to the application level. This lends itself to building reusable components that work together in a system. Packages also help in designing a scalable application that can grow without becoming a bird's nest of tightly coupled code dependency. 1.5 Safety of Implementation It's one thing to create a language that prevents you from shooting yourself in the foot; it's quite another to create one that prevents others from shooting you in the foot. Encapsulation is a technique for hiding data and behavior within a class; it's an important part of object-oriented design. It helps you write clean, modular software. In most languages, however, the visibility of data items is simply part of the relationship between the programmer and the compiler. It's a matter of semantics, not an assertion about the actual security of the data in the context of the running program's environment. When Bjarne Stroustrup chose the keyword private to designate hidden members of classes in C++, he was probably thinking about shielding you from the messy details of a class developer's code, not the issues of shielding that developer's classes and objects from the onslaught of someone else's viruses and Trojan horses. Arbitrary casting and pointer arithmetic in C or C++ make it trivial to violate access permissions on classes without breaking the rules of the language. Consider the following code: // C++ code class Finances { private: char creditCardNumber;... }; main( ) { Finances finances;  // Forge a pointer to peek inside the class char *cardno = (char *)&finances; printf("Card Number = %s\n", cardno); } In this little C++ drama, we have written some code that violates the encapsulation of the Finances class and pulls out some secret information. This sort of shenanigan—abusing an untyped pointer—is not possible in Java. If this example seems unrealistic, consider how important it is to protect the foundation (system) classes of the runtime environment from similar kinds of attacks. If untrusted code can corrupt the components that provide access to real resources, such as the filesystem, the network, or the windowing system, it certainly has a chance at stealing your credit card numbers. In Visual BASIC, it's also possible to compromise the system by peeking, poking, and, under DOS, installing interrupt handlers. Even some recent languages that have some commonalties with Java lack important security features. For example, the Apple Newton uses an object- oriented language called NewtonScript that is compiled into an interpreted byte-code format. However, NewtonScript has no concept of public and private members, so a Newton application has free reign to access any information it finds. General Magic's Telescript language is another example of a device-independent language that does not fully address security concerns. The list goes on... If a Java application is to dynamically download code from an untrusted source on the Internet and run it alongside applications that might contain confidential information, protection has to extend very deep. The Java security model wraps three layers of protection around imported classes, as shown in Figure 1.3. Figure 1.3. The Java security model At the outside, application-level security decisions are made by a security manager. A security manager controls access to system resources like the filesystem, network ports, and the windowing environment. A security manager relies on the ability of a class loader to protect basic system classes. A class loader handles loading classes from the network. At the inner level, all system security ultimately rests on the Java verifier, which guarantees the integrity of incoming classes. The Java byte-code verifier is a fixed part of the Java runtime system. Class loaders and the security managers (or security policies to be more precise), however, are components that may be implemented differently by different applications that load byte-code, such as applet viewers and web browsers. All three of these pieces need to be functioning properly to ensure security in the Java environment.  You may have seen reports about various security flaws in Java. While these weaknesses are real, it's important to realize that they have been found in the implementations of various components, namely Sun's byte-code verifier and Netscape's class loader and security manager, not in the basic security model itself. One of the reasons Sun has released the source code for Java is to encourage people to search for weaknesses, so they can be removed. 1.5.1 The Verifier Java's first line of defense is the byte-code verifier. The verifier reads byte-code modules before they are run and makes sure they are well-behaved and obey the basic rules of the Java language. A trusted Java compiler won't produce code that does otherwise. However, it's possible for a mischievous person to deliberately assemble bad code. It's the verifier's job to detect this. Once code has been verified, it's considered safe from certain inadvertent or malicious errors. For example, verified code can't forge references or violate access permissions on objects. It can't perform illegal casts or use objects in unintended ways. It can't even cause certain types of internal errors, such as overflowing or underflowing the operand stack. These fundamental guarantees underlie all of Java's security. You might be wondering, isn't this kind of safety implicit in lots of interpreted languages? Well, while it's true that you shouldn't be able to corrupt the interpreter with bogus BASIC code, remember that the protection in most interpreted languages happens at a higher level. Those languages are likely to have heavyweight interpreters that do a great deal of runtime work, so they are necessarily slower and more cumbersome. By comparison, Java byte-code is a relatively light, low-level instruction set. The ability to statically verify the Java byte-code before execution lets the Java interpreter run at full speed with full safety, without expensive runtime checks. Of course, you are always going to pay the price of running an interpreter, but that's not a serious problem with the speed of modern CPUs. Java byte-code can also be compiled on the fly to native machine code, which has even less runtime overhead. The verifier is a type of theorem prover. It steps through the Java byte-code and applies simple, inductive rules to determine certain aspects of how the byte-code will behave. This kind of analysis is possible because compiled Java byte-code contains a lot more type information than the object code of other languages of this kind. The byte-code also has to obey a few extra rules that simplify its behavior. First, most byte-code instructions operate only on individual data types. For example, with stack operations, there are separate instructions for object references and for each of the numeric types in Java. Similarly, there is a different instruction for moving each type of value into and out of a local variable. Second, the type of object resulting from any operation is always known in advance. There are no byte-code operations that consume values and produce more than one possible type of value as output. As a result, it's always possible to look at the next instruction and its operands, and know the type of value that will result. Because an operation always produces a known type, by looking at the starting state, it's possible to determine the types of all items on the stack and in local variables at any point in the future. The collection of all this type information at any given time is called the type state of the stack; this is what Java tries to analyze before it runs an application. Java doesn't know anything about the actual values of stack and variable items at this time, just what kind of items they are. However, this is enough information to enforce the security rules and to ensure that objects are not manipulated illegally. To make it feasible to analyze the type state of the stack, Java places an additional restriction on how Java byte-code instructions are executed: all paths to the same point in the code have to arrive with exactly the same type state. This restriction makes it possible for the verifier to trace each branch of the code just once and still know the type state at all points. Thus, the verifier can insure that instruction types and stack value types always correspond, without actually following the execution of the code. For a more thorough explanation of all of this, see The Java Virtual Machine, by Jon Meyer and Troy Downing (O'Reilly & Associates). The implications of this rule are of interest mainly to compiler writers. The rule means that Java byte- code can't perform certain types of iterative actions within a single frame of execution. A common example would be looping and pushing values onto the stack. This is not allowed because the path of execution would return to the top of the loop with a potentially different type state on each pass, and there is no way that a static analysis of the code can determine whether it obeys the security rules. 1.5.2 Class Loaders Java adds a second layer of security with a class loader. A class loader is responsible for bringing the byte-code for one or more Java classes into the interpreter. Every application that loads classes from the network must use a class loader to handle this task. After a class has been loaded and passed through the verifier, it remains associated with its class loader. As a result, classes are effectively partitioned into separate namespaces based on their origin. When a loaded class references another class name, the location of the new class is provided by the original class loader. This means that classes retrieved from a specific source can be restricted to interact only with other classes retrieved from that same location. For example, a Java-enabled web browser can use a class loader to build a separate space for all the classes loaded from a given uniform resource locator (URL). The search for classes always begins with the built-in Java system classes. These classes are loaded from the locations specified by the Java interpreter's class path (see Chapter 3). Classes in the class path are loaded by the system only once and can't be replaced. This means that it's impossible for an applet to replace fundamental system classes with its own versions that change their functionality. 1.5.3 Security Managers Finally, a security manager is responsible for making application-level security decisions. A security manager is an object that can be installed by an application to restrict access to system resources. The security manager is consulted every time the application tries to access items like the filesystem, network ports, external processes, and the windowing environment, so the security manager can allow or deny the request. A security manager is most useful for applications that run untrusted code as part of their normal operation. Since a Java-enabled web browser can run applets that may be retrieved from untrusted sources on the Net, such a browser needs to install a security manager as one of its first actions. This security manager then restricts the kinds of access allowed after that point. This lets the application impose an effective level of trust before running an arbitrary piece of code. And once a security manager is installed, it can't be replaced. In Java 2, the security manager works in conjunction with an access controller that lets you implement security policies by editing a file. Access policies can be as simple or complex as a particular application warrants. Sometimes it's sufficient simply to deny access to all resources or to general categories of services such as the filesystem or network. But it's also possible to make sophisticated decisions based on high-level information. For example, a Java-enabled web browser could use an access policy that lets users specify how much an applet is to be trusted or that allows or denies access to specific resources on a case-by-case basis. Of course, this assumes that the browser can determine which applets it ought to trust. We'll see how this problem is solved shortly. The integrity of a security manager is based on the protection afforded by the lower levels of the Java security model. Without the guarantees provided by the verifier and the class loader, high- level assertions about the safety of system resources are meaningless. The safety provided by the Java byte-code verifier means that the interpreter can't be corrupted or subverted, and that Java code has to use components as they are intended. This, in turn, means that a class loader can guarantee that an application is using the core Java system classes and that these classes are the only means of accessing basic system resources. With these restrictions in place, it's possible to centralize control over those resources with a security manager. 1.6 Application and User-Level Security There's a fine line between having enough power to do something useful and having all the power to do anything you want. Java provides the foundation for a secure environment in which untrusted code can be quarantined, managed, and safely executed. However, unless you are content with keeping that code in a little black box and running it just for its own benefit, you will have to grant it access to at least some system resources so that it can be useful. Every kind of access carries with it certain risks and benefits. The advantages of granting an untrusted applet access to your windowing system, for example, are that it can display information and let you interact in a useful way. The associated risks are that the applet may instead display something worthless, annoying, or offensive. Since most people can accept that level of risk, graphical applets and the World Wide Web in general are possible. At one extreme, the simple act of running an application gives it a resource, computation time, that it may put to good use or burn frivolously. It's difficult to prevent an untrusted application from wasting your time, or even attempting a "denial of service" attack. At the other extreme, a powerful, trusted application may justifiably deserve access to all sorts of system resources (e.g., the filesystem, process creation, network interfaces); a malicious application could wreak havoc with these resources. The message here is that important and sometimes complex security issues have to be addressed. In some situations, it may be acceptable to simply ask the user to "okay" requests. Sun's HotJava web browser can pop up a dialog box and ask the user's permission for an applet to access an otherwise restricted file. However, we can put only so much burden on our users. An experienced person will quickly grow tired of answering questions; an inexperienced user may not be able to answer the questions correctly. Is it okay for me to grant an applet access to something if I don't understand what that is? Making decisions about what is dangerous and what is not can be difficult. Even ostensibly harmless access, like displaying a window, can become a threat when paired with the ability for an untrusted application to communicate from your host. The Java Security Manager provides an option to flag windows created by an untrusted application with a special, recognizable border to prevent it from impersonating another application and perhaps tricking you into revealing your password or your secret recipe collection. There is also a grey area, in which an application can do devious things that aren't quite destructive. An applet that can mail a bug report can also mail- bomb your boss. The Java language provides the tools to implement whatever security policies you want. However, what these policies will be ultimately depends on who you are, what you are doing, and where you are doing it. 1.6.1 Signing Classes Web browsers such as HotJava start by defining a few rules and some coarse levels of security that restrict where applets may come from and what system resources they may access. These rules are sufficient to keep the waving Duke applet from clutching your password file, but they aren't sufficient for applications you'd like to trust with sensitive information. To fully exploit the power of Java, we need to have some nontechnical basis on which to make reasonable decisions about what a program can be allowed to do. This nontechnical basis is trust; basically, you trust certain entities not to do anything that's harmful to you. For a home user, this may mean that you trust the "Bank of Boofa" to distribute applets that let you transfer funds between your accounts, or you may trust L.L. Bean to distribute an applet that debits your Visa account. For a company, that may mean that you trust applets originating behind your firewall, or perhaps applets from a few high-priority customers, to modify internal databases. In all of these cases, you don't need to know in detail what the program is going to do and give it permission for each operation. You only need to know that you trust your local bank. This doesn't mean that there isn't a technical aspect to the problem of trust. Trusting your local bank when you walk up to the ATM means one thing; trusting some web page that claims to come from your local bank means something else entirely. It would be very difficult to impersonate the ATM two blocks down the street (though it has been known to happen), but, depending on your position on the Net, it's not all that difficult to impersonate a web site, or to intercept data coming from a legitimate web site and substitute your own. That's where cryptography comes in. Digital signatures, together with certificates, are techniques for verifying that data truly comes from the source it claims to have come from and hasn't been modified en route. If the Bank of Boofa signs its checkbook applet, your browser can verify that the applet actually came from the bank, not an imposter, and hasn't been modified. Therefore, you can tell your browser to trust applets that have the Bank of Boofa's signature. Java supports digital signatures; the details are covered in. 1.7 Java and the World Wide Web The application-level safety features of Java make it possible to develop new kinds of applications that were infeasible before now. A web browser that implements the Java runtime system can incorporate Java applets as executable content inside of documents. This means that web pages can contain not only static hypertext information but also full-fledged interactive applications. The added potential for use of the Web is enormous. A user can retrieve and use software simply by navigating with a web browser. Formerly static information can be paired with portable software for interpreting and using the information. Instead of just providing some data for a spreadsheet, for example, a web document might contain a fully functional spreadsheet application embedded within it that allows users to view and manipulate the information. 1.7.1 Applets The term "applet" is used to mean a small, subordinate, or embeddable application. By "embeddable," we mean it's designed to be run and used within the context of a larger system. In that sense, most programs are embedded within a computer's operating system. An operating system manages its native applications in a variety of ways: it starts, stops, suspends, and synchronizes applications; it provides them with certain standard resources; and it protects them from one another by partitioning their environments. As far as the web browser model is concerned, an applet is just another type of object to display; it's embedded into an HTML page with a special tag. Browsers make a distinction between items presented inline and items anchored via hypertext links and made available by external means, such as a viewer or helper application. If you download an MPEG video clip, for instance, and your browser doesn't natively understand MPEG, it will look for a helper application (an MPEG player) to pass the information to. Java-enabled web browsers generally execute applets inline, in the context of a particular document, as shown in Figure 1.4. However, less capable browsers could initially provide some support for Java applets through an external viewer. Figure 1.4. Applets in a web document A Java applet is a compiled Java program, composed of classes just like any Java program. While a simple applet may consist of only a single class, most large applets should be broken into many classes. Each class is stored in a separate class file. The class files for an applet are retrieved from the network as they are needed. A large applet doesn't need to retrieve all its parts or all its data before beginning to interact with the user. Well-designed applets can take advantage of multithreading to wait for certain resources in the background, while performing other activities. An applet has a four-part life cycle. When an applet is initially loaded by a web browser, it's asked to initialize itself. The applet is then informed each time it's displayed and each time it's no longer visible to the user. Finally, the applet is told when it's no longer needed, so that it can clean up after itself. During its lifetime, an applet may start and suspend itself, do work, communicate with other applications, and interact with the Web browser. Applets are autonomous programs, but they are confined within the walls of a web browser or applet viewer, and have to play by its rules. We'll be discussing the details of what applets can and can't do as we explore features of the Java language. However, under the most conservative security policies, an applet can interact only with the user and can communicate only over the network with the host from which it originated. Other types of activities, like accessing files or interacting directly with outside applications, are typically prevented by the security manager that is part of the web browser or applet viewer. But aside from these restrictions, there is no fundamental difference between a Java applet and a standalone Java application. 1.7.2 New Kinds of Media When it was first released, Java quickly achieved a reputation for multimedia capabilities. Frankly, this wasn't really deserved. At that point, Java provided facilities for doing simple animations and playing audio. You could animate and play audio simultaneously, though you couldn't synchronize the two. Still, this was a significant advance for the Web, and people thought it was pretty impressive. Java's multimedia capabilities have now taken shape. Java now has CD-quality sound, 3D animation, media players that synchronize audio and video, speech synthesis and recognition, and more. The Java Media Framework now supports most common audio and video file formats; The Java Sound API (part of the core classes) has the ability to record sound from a computer's microphone. 1.7.3 New Software Development Models For some time now, people have been using visual development environments to develop user interfaces. These environments let you generate applications by moving components around on the screen, connecting components to each other, and so on. In short, designing a user interface is a lot more like drawing a picture than like writing code. For visual development environments to work well, you need to be able to create reusable software components. That's what the JavaBeans architecture is all about: it defines a way to package software as reusable building blocks. A graphical development tool can figure out a component's capabilities, customize the component, and connect it to other components to build applications. JavaBeans takes the idea of graphical development a step further. JavaBeans components, called Beans, aren't limited to visible, user interface components: you can have Beans that are entirely invisible and whose job is purely computational. For example, you could have a Bean that does database access; you could connect this to a Bean that lets the user request information from the database; and you could use another Bean to display the result. Or you could have a set of Beans that implement the functions in a mathematical library; you could then do numerical analysis by connecting different functions to each other. In either case, you could "write" programs without writing a single line of code. Granted, someone would have to write the Beans in the first place; but that's a much smaller task, and we expect markets to develop for "off the shelf " Bean collections. Before it can use a Bean, an application builder must find out the Bean's capabilities. There are a few ways it can do this; the simplest is called reflection. To write a Bean that uses reflection, all you need to do is follow some well-defined conventions (design patterns) that let the graphical interface builder (or any other tool that wants to do the work) analyze the Bean. If they need to, Beans can provide additional information using a process called introspection. But even without introspection, a graphical development tool can analyze a Bean, figure out what it can do, and let a user change the Bean's properties without writing any code. Of course, once a development tool has customized a Bean and connected it to other Beans, it needs a way to save the result. A process called serialization lets a tool save the Bean's current state, along with any extra code it has written to stitch Beans together in an application. Visual development tools that support Java Beans include IBM's VisualAge, Inprise's JBuilder (http://www.inprise.com), WebGain's Visual Cafe (http://www.webgain.com), and Sun's Forte for Java. By using a "bridge," Java Beans can function inside ActiveX. 1.8 Java as a General Application Language The Java applet API is a framework that allows Java-enabled web browsers to manage and display embedded Java applications within web documents. However, Java is more than just a tool for building transportable multimedia applications. Java is a powerful, general-purpose programming language that just happens to be safe and architecture-independent. Standalone Java applications are not subject to the restrictions placed on applets; they can perform the same jobs as programs written in languages like C and C++ do. Any software that implements the Java runtime system can run Java applications. Applications written in Java can be large or small, standalone or component-like, as in other languages. Java applets are different from other Java applications only in that they expect to be managed by a larger application. They are normally considered untrusted code. In this book, we will build examples of both applets and standalone Java applications. With the exception of the few things untrusted applets can't do, such as access files, all of the tools we examine in this book apply to both applets and standalone Java applications. 1.9 A Java Road Map With everything that's going on, it's hard to keep track of what's available now, what's promised, and what has been around for some time. Here's a road map that imposes some order on Java's past, present, and future. 1.9.1 The Past: Java 1.0 and Java 1.1 Java 1.0 provided the basic framework for Java development: the language itself plus packages that let you write applets and simple applications. Although Java 1.0 is officially obsolete, it will be some time before vendors catch up with the newer releases. Java 1.1 superseded Java 1.0. It incorporated major improvements in the AWT package ( Java's original GUI facility) and many new features. Java 1.1 remains important, because it is supported natively by both the Netscape Navigator and Microsoft Internet Explorer browsers. For various political reasons, the future of the browser world is uncertain; to execute applets using any features of Java 2, you need to use the Java plug-in, which allows Netscape and IE to execute Java 2 code. 1.9.2 The Present: Java 2 Java 2 was released in December 1998, providing many improvements and additions. The most notable addition is Swing, which is a new user interface toolkit with capabilities far exceeding AWT's. (Swing, AWT, and some other packages are now called the JFC, or Java Foundation Classes.) Here's a brief overview of the most important features of the core Java 2 API: JDBC (Java Database Connectivity) A general facility for interacting with databases. (Introduced with Java 1.1.) RMI (Remote Method Invocation) Java's distributed objects system. RMI lets you call methods on objects hosted by a server running somewhere else on the network. (Introduced with Java 1.1.) Java Security A facility for controlling access to system resources, combined with a uniform interface to cryptography. Java Security is the basis for signed classes, which were discussed earlier. JFC (Java Foundation Classes) A catch-all for a number of new features, including the Swing user interface components; "pluggable look-and-feel," which means the ability of the user interface to adapt itself to the "look-and-feel" of the platform you're using; drag and drop; and accessibility, which means the ability to integrate with special software and hardware for people with disabilities. Java 2D Part of JFC; enables high-quality graphics, font manipulation, and printing. Internationalization The ability to write programs that adapt themselves to the language the user wants to use; the program automatically displays text in the appropriate language. (Introduced with Java 1.1.) The following features aren't part of the core Java 2 definition; you may have to download them separately. Most of them are what Sun calls "standard extensions": JNDI (Java Naming and Directory Interface) A very general service for looking up resources. JNDI unifies access to directory services like LDAP, Novell's NDS, and others. JavaMail A uniform API for writing email software. Java 3D A facility for developing applications with 3D graphics. Java Media Another catch-all that includes Java 2D, Java 3D, the Java Media Framework (a framework for coordinating the display of many different kinds of media), Java Speech (for speech recognition and synthesis), Java Sound (high-quality audio), Java TV (for interactive television and similar applications), and others. Java Servlets A facility that lets you write custom Internet servers. It is most frequently used to write web server applications, but it's much more general. Java Cryptography Actual implementations of cryptographic algorithms. (This package was separated from Java Security for legal reasons.) JavaHelp  A facility for writing help systems and incorporating them in Java programs. Enterprise JavaBeans A component architecture for building distributed server-side applications. Jini An extremely interesting catch-all that is designed to enable massively distributed computing, including computing on common household appliances. In a few years, your stereo may be able to execute Java programs. Java Card A version of Java for very small (i.e., credit card-sized) devices, which have severe limitations on speed and memory. In this book, we'll try to give you a taste of as many features as possible; unfortunately for us (but fortunately for Java software developers), the Java environment has become so rich that it's impossible to cover everything in a single book. 1.9.3 The Future You can think of the first four years of Java development as a "big bang," followed by an "inflationary" phase as Sun added new features, and improved old features, at an incredible rate. Things seem to be slowing down now: new APIs aren't being announced as often, and those that are announced tend to be more specialized. At least for the moment, the Java world is stabilizing. But it's important to look into the new areas into which Java is headed. The most interesting of these is consumer devices. An interesting game to play is thinking of what an everyday appliance might be able to do if it had a Java processor in it. A common bread maker could download "breadlets" (applets that implement bread recipes) from the Internet; your stereo wouldn't just play CDs—it could find music sources on the Internet and perhaps even facilitate live, distributed jam sessions using technologies like Java Sound. These devices could probably be built without Java, but that's not saying much: after all, no software has yet been written that couldn't (in theory) be hand-coded in assembly language. More to the point, Java (and especially Jini) make it much easier to develop these kinds of applications in reliable, safe ways. Until now, discussion of Java on consumer devices has been limited to visionary, hypothetical talk. However, this is changing. There is already a version of the Java Virtual Machine that runs on 3Com's Palm devices; JVMs for cell phones, pagers, and other personal communication devices are on the way. While this book can't go into the details of development for such devices, it's important to realize that the vision is becoming reality. The step from a Palm hand-held computer to a cell phone to your VCR or television is extremely small—much smaller than the leap from a personal computer to the Palm. 1.9.4 Availability By the time you read this book, you should have several choices for Java development environments and runtime systems. Sun's Java 2 SDK is available for Solaris, Linux, and Windows. Visit Sun's Java web site at http://java.sun.com for more information about the Java 2 SDK. There are also Java ports for other platforms, including NetWare, HP-UX, OSF/1 (including Digital Unix), Silicon Graphics' IRIX, and various IBM operating systems (including AIX and OS2). For more information, see the web pages maintained by the vendor you're interested in. Sun maintains a web page summarizing porting efforts at http://java.sun.com/cgi- bin/java-ports.cgi. Another good source for current information is the Java FAQ from the comp.lang.java newsgroup. The Java 2 SDK used to be called the JDK. Sun's marketing group has an unfortunate tendency to change terminology for reasons that are no doubt clear to them, but only introduce confusion for everyone else. In this book, we'll use SDK, even for older versions of Java that were distributed as the JDK. There are efforts under way to produce a free clone of Java, redistributable in source form. The Java Open Language Toolkit ( JOLT) Project is working to assemble a high-quality Java implementation that will pass Sun's validation tests and earn a Java stamp. The JOLT Project web page is accessible from http://www.redhat.com. Netscape Navigator and Microsoft Internet Explorer both come with their own Java runtime system that runs Java applets and supports SDK 1.1. Neither supports Java 2 at present, although the newest release of Navigator (6.0) is supposed to support Java 2 and future versions through a new "open Java" API. To ameliorate the problem in general, Sun has released a Java plug-in that supports Java 2; it is distributed with the Java SDK for Windows. Chapter 2. A First Application Before getting into the details of the Java language, let's jump right into some working code. In this chapter, we'll build a friendly little application that illustrates a number of techniques we use throughout the book. We'll take this opportunity to introduce general features of the Java language and of Java applications. However, many details won't be fleshed out here, but in subsequent chapters. This chapter also serves as a brief introduction to the object-oriented and multithreaded features of Java. If these concepts are new to you, you can take comfort in the knowledge that encountering them for the first time in Java should be a straightforward and pleasant experience. If you have worked with another object-oriented or multithreaded programming environment, clear your mind; you will especially appreciate Java's simplicity and elegance. We can't stress enough the importance of experimentation as you learn new concepts. Don't just examine the examples—run them. Copy the source code from the accompanying CD-ROM, or from our web site at http://www.oreilly.com/catalog/learnjava. Compile the programs on your machine, and run them. If you follow along with the online examples, be sure to take some time and compile them locally. Then, turn our examples into your example: play with them; change their behavior, break them, fix them, and, as Java architect Arthur van Hoff would say: "Have fun!" 2.1 HelloJava1 In the tradition of introductory programming texts, we begin with Java's equivalent of the archetypal "Hello World" application. In the spirit of our new world, we'll call it HelloJava. We'll take four passes at this example (HelloJava1, HelloJava2, etc.), adding features and introducing new concepts along the way. Here's a minimalist version: All of the ready-to-run examples in this book are included on the accompanying CD-ROM. The comment line //file:... indicates the name of the source file. //file: HelloJava1.java public class HelloJava1 extends javax.swing.JComponent { public static void main(String[] args) { javax.swing.JFrame f = new javax.swing.JFrame("HelloJava1"); f.setSize(300, 300); f.getContentPane().add(new HelloJava1( )); f.setVisible(true); } public void paintComponent(java.awt.Graphics g) { g.drawString("Hello, Java!", 125, 95); } } Place this text in a file called HelloJava1.java. Now compile this source: % javac HelloJava1.java This produces the Java byte-code binary class file HelloJava1.class. You can run the application by starting the Java runtime system, specifying the class name (not the filename) as an argument: % java HelloJava1 (The name of the Java interpreter varies among implementations. Microsoft's is named jview, not java.) You should see the proclamation shown in Figure 2.1. Now congratulate yourself: you have written your first application! Take a moment to bask in the glow of your monitor. Figure 2.1. The HelloJava1 application When you click on the window's close box, the window goes away, but your program will still be running. To stop the runtime system and return control to your command-line interpreter, type Ctrl-C or whatever key sequence stops a running application on your platform. We'll remedy this shortcoming in a later version of the example. HelloJava1 may be a small program, but there is actually quite a bit going on behind the scenes. Those few lines represent the tip of an iceberg. What lies under the surface are layers of functionality provided by the Java language and its foundation class libraries. In this chapter, we'll cover a lot of ground quickly in an effort to show you the big picture. We'll try to offer enough detail for a firm understanding of what is happening in each example, deferring full explanations until the appropriate chapters. This holds for both elements of the Java language and the object- oriented concepts that apply to them. Later chapters will provide more detailed cataloging of Java's syntax, components, and object-oriented features. Salutations, Java! There are many ways to say "Hello, Java!" The simplest command-line version of HelloJava looks like this: public class HelloJavaCommandLine { public static void main(String[] args) { System.out.println("Hello, Java!"); } } Weighing in at just five lines, this program uses the System class to write some text to the console. The HelloJava examples in this chapter are a little lengthier; they are structured to show off Java's user interface toolkit, Swing, and to provide a quick fly- through of the Java language and libraries. If we weren't concerned about the tutorial, we could create a graphic example that's just as pithy as the command-line version, using the JOptionPane class: public class HelloJavaSimple { public static void main(String[] args) { javax.swing.JOptionPane.showMessageDialog(null, "Hello, Java!"); } } 2.1.1 Classes The previous example defines a class named HelloJava1. Classes are the fundamental building blocks of most object-oriented languages. A class in Java is very much like a class in C++, and somewhat like a struct in C. It's a group of data items, with associated functions that perform operations on this data. The data items in a class are called fields or variables; the functions are called methods. A class might represent something concrete, like a button on a screen or the information in a spreadsheet, or it could be something more abstract, such as a sorting algorithm or possibly the sense of ennui in your MUD character. A hypothetical spreadsheet class might, for example, have variables that represent the values of its individual cells and methods that perform operations on those cells, such as "clear a row" or "compute values." We'll talk more about this in a little while. Our HelloJava1 class contains an entire Java application. It holds two general types of variables and methods: those we need for our specific application's tasks and some special predesignated ones we provide to interact with the outside world. The Java runtime system, in this case the java command-line tool, calls methods in HelloJava1 to pass us information and prod us to perform actions. Our simple HelloJava1 class implements two important methods. The first, main( ), is called when the application is first started. We'll talk more about it in the next section. The second method, paintComponent( ), is called by Java when it's time for our application to draw itself on the screen. 2.1.2 The main( ) Method When you run our example, what really happens? The java command looks in the HelloJava1 class to see if it contains a special method called main( ). If it does, this method is run. The main( ) method is simply an entry point for an application. It's a piece of code that you want to be run when the application first starts. The main( ) method sets up a window (a JFrame) that will contain the visual output of the HelloJava1 class. What really interests us here is not the main( ) method but the rest of the class. We'll go through several incarnations of this class, adding features and methods. But the main( ) method will remain largely unchanged, keeping its basic function of creating a window that holds the HelloJava example. Let's quickly walk through the main( ) method, just so you know what it does. First, main( ) creates a JFrame, a window that will hold our example: javax.swing.JFrame f = new javax.swing.JFrame("HelloJava1"); The new word in this line of code is tremendously important: javax.swing.JFrame ( just JFrame for short) is the name of a class that represents a window you can see on your screen. The class itself is just a template, like a building plan. The new keyword tells Java to allocate memory and initialize a new JFrame object. When frame windows are first created, they are very small. Our next task is to set the size to something reasonable: f.setSize(300, 300); Then we create our actual example and put it inside the frame window: f.getContentPane().add(new HelloJava1( )); Here, we're actually creating a new HelloJava1 object and placing it inside the JFrame we just created. main( )'s final task is to show the frame window and its contents, which otherwise would be invisible. An invisible window makes for a pretty boring application. f.setVisible(true); That's the whole main( ) method. As we progress through the examples in this chapter, it will remain mostly unchanged as the HelloJava class evolves around it. Let's get started! 2.1.3 Classes and Objects A class is a blueprint for a part of an application; it lists methods and variables that go into making up that part. Many individual working copies of a given class can exist while an application is active. These individual incarnations are called instances of the class, or objects. Two instances of a given class may contain different data, but they always have the same methods. As an example, consider a Button class. There is only one Button class, but an application can create many different Button objects, each one an instance of the same class. Furthermore, two Button instances might contain different data, perhaps giving each a different appearance and performing a different action. In this sense, a class can be considered a mold for making the object it represents: something like a cookie cutter stamping out working instances of itself in the memory of the computer. As you'll see later, there's a bit more to it than that—a class can in fact share information among its instances—but this explanation suffices for now. Chapter 5, has the whole story on classes and objects. The term object is very general and in some other contexts is used almost interchangeably with class. Objects are the abstract entities all object-oriented languages refer to in one form or another. We will use object as a generic term for an instance of a class. We might, therefore, refer to an instance of the Button class as a Button, a Button object, or, indiscriminately, as an object. The main( ) method in the previous example creates a single instance of the HelloJava1 class and shows it in an instance of the JFrame class. You could modify main( ) to create many instances of HelloJava1, perhaps each in a separate window. 2.1.4 Variables and Class Types In Java, every class defines a new type (data type). A variable can be of this type and then hold instances of that class. A variable could, for example, be of type Button and hold an instance of the Button class, or of type SpreadSheetCell and hold a SpreadSheetCell object, just as it could be any of the more familiar types such as int or float. Ignoring the main( ) method for the moment, there is only one variable in our simple HelloJava example. It's found in the declaration of the paintComponent( ) method: public void paintComponent(java.awt.Graphics g) {...} Just like functions in C (and many other languages), a method in Java declares a list of variables that hold its arguments, and it specifies the types of those arguments. Our paintComponent(