An Excerpt From THE JAVA SOURCEBOOK by Ed Anuff, HotWired (ISBN 0-471-14859-8, John Wiley & Sons) The following is unedited text from the Introduction of The Java Sourcebook. Copyright 1996 John Wiley & Sons, Inc. All rights reserved. __________________________________________________ Introduction If you're reading this, you're probably excited about learning more about Java, which could be argued is one of the most important things to come to the World Wide Web since its inception. By now, you're probably familiar with the Web and have used a Web browser like Mosaic or Netscape to pull information from anywhere in the world by simply pointing and clicking on hot links. What makes this possible is that the Web defines a standard method of communication between Web servers and Web browsers called HTTP and a number of standard formats for information that most computers have a reasonable shot at displaying. This basic system has allowed many interesting and exciting Web pages to be built and enjoyed by thousands of net surfers, but as the web has started to grow, people have started to encounter limitations of this system. To understand why, you need to back up a bit and take a look at the elements that make up the Web itself. Java and the Future of the WWW The Web at its simplest consists of two programs, the browser (which runs on your computer) and the server (which usually runs on a remote system). Most browsers can really only do a few basic things. A browser can either request information from the server, or ask the server to run special programs called CGI scripts for it. While it would be unfair to call a browser "dumb", most of the interactivity you experience while using the Web beyond simply clicking on hotlinks is the result of CGI scripts being run on remote web servers which use the output of those scripts to decide what to show you or where to take you next. For example, many pages have clickable graphics images, called image maps, which can be clicked on in order to jump to another web page or cause some other action to occur. When you click on the image map, what happens is that the coordinates of where you clicked within the image are transferred to a CGI script running on the web server. The CGI script looks at these coordinates and decides what page to send back to the browser in response. Considering that often times the web server your browser is talking to can be half a world away, its understandable that the web might not be responsive enough to give you the type of real time feedback you'd experience using a CD-ROM or other interactive applications. If it was possible for your browser to handle more complex tasks itself without asking the server every time it needed something done, you could have truly dynamic, responsive, and complex interactivity as part of the web. After you've used the Web for a little while, you begin to notice that the every page consists of certain basic types of media. The main thing you see is text, with some simple formatting. The second thing you'll see is graphics, primarily in the form of GIF or JPEG images. If you don't recognize these formats, don't worry, its enough to know that they are special file formats which are often used because they can be viewed on a number of platforms and can be compressed so that they can be downloaded over the net as quickly as possible. Sometimes, you'll click on a link and a file will be downloaded to your computer, after which a separate application, called a helper application, will be launched which may play the downloaded file if its a sound or movie, or handle the file in some other special fashion. Helper applications are so named because they help the browser out in dealing with file types the browser doesn't know how to handle. You'll quickly notice the difference between how elegantly the browser deals with files it does know how to handle (text, GIF files, etc.) and the ones it needs helper apps for. The files the browser knows how to handle are inline, meaning their contents are displayed right on the web page. When you see a graphic on a Web page, its really a graphic file which the browser recognizes that it knows how to deal with and which is inlined on the page. Since the browser knows about these files, it can do cool things like starting to draw the file as it downloads rather than waiting until the whole file has been pulled down. Compare this to the clunky usage of helper applications, which need to have the whole file downloaded to your hard disk first, and then the application needs to be launched. Depending on the configuration of your computer, a number of things might go wrong. You might not have the appropriate helper app, there might not be enough memory to load, etc. The general point is that its usually better to have a browser which has support for a type of file built in than have to use a helper app. Its because of this that some of the more ambitious vendors of browser software (i.e. Netscape) have been teaming up with the makers of some of the more popular helper applications to build the code for their helper apps directly into their browsers. A good example of this is Netscape's alliance with Adobe to built support for Adobe's Acrobat page description files into Netscape, rather than requiring Netscape users to have the Acrobat Reader configured as a helper application. The problem here is that every day someone comes up with a great new application that can be used as a helper app. The browser makers are going to be extremely busy if they're going to be creating new versions of their products every time someone creates a new file format. The elegant solution would be if it were possible for the browser to automatically download the correct helper app when it encountered a file it didn't recognize and the ideal solution would be if the helper app was dynamically integrated into your browser after it had been downloaded. Early in 1995, Sun announced a solution to these problems in the form of Hot Java, and made early versions of the software available on the net. The name Hot Java actually refers to the Web browser built using the Java language, although it is sometimes incorrectly used to describe any Web-related usage of Java. Hot Java takes advantage of the properties of the Java language to enable the usage of Java applets within the browser. Applets are sometimes described as client-side scripting. What this means is that the script, rather than being run on the remote server, is run on your (the client's) machine. Applets are also often referred to as executable content. This means that it is content that knows the best way to present itself. If its a music file, it knows how to play itself. If its an animation, it knows how to draw itself, and what to do if its clicked on. Client-side scripting and executable content are both good ways of thinking about applications of Java applets, but that's not the whole story. The range of things made possible by Java is expanding every day as more and more people create new and amazing applications using this technology which is both extremely powerful, yet remarkably easy to use. Hot Java and Java Browsers As mentioned before, Hot Java properly describes Sun's Web browser which is written using the Java language and supports Hot Java applets. When most people refer to Hot Java, they actually mean Java applets, which are programs written in Java and are included in HTML pages. The Hot Java browser is similar to other popular browsers in the way it displays pages and allows you to navigate the Web. Most of your experience with Java applets will probably be when using Netscape 2.0. Netscape licensed Java from Sun and incorporated support for Java applets in Netscape 2.0, which went into public beta in October, 1995. Netscape intends to support Java across all the platforms that the Netscape Navigator will run on, and since Netscape owns the largest share of the browser market, their support for Java represents a significant endorsement of the technology. Java, the Language Java is a simple, object-oriented language which has many elements in common with C and C++, but has removed or streamlined the areas where many programmers have had difficulty or have been the most frequent sources of bugs. Java also is a secure language, which means that it is possible to restrict the access of Java programs to parts of the system such as files and memory address, without limiting the capabilities of the language. This is one of the most important reasons why it is so well suited for use on the web. Java has the benefits of an interpreted language, and the performance of compiled code. Users of rapid application development and scripting languages such as Visual Basic, Delphi, Perl, HyperCard, or AppleScript will be able to get started programming in Java in a very short time. Seasoned C and C++ programmers will find that they are able to easily translate their skills to this new language, and find that most of their code and algorithms are reusable as well. While Java is well suited to Internet related tasks, it is also a solid general purpose language which Sun intends to use in a variety of applications, and which will no doubt, through Sun's licensing efforts, turn up in a variety of products. Where to Go from Here The Java Sourcebook is organized into four parts. Part I covers how to get and install the Java Development Kit, run the Hot Java browser and Netscape, and visit any Java- enhanced site on the Web. Part II covers the nuts and bolts of the Java language. Part III covers building Applets in Hot Java, line by line. Part IV summarizes the reference material available on the SDK API Packages, the standard libraries for handling i/o, graphics, and net communications. The Java Sourcebook is written from the perspective that your goal is to ultimately be able to program your own Java applets. If you're new to Java and the Web, then you can focus on the chapters in Part I. If you're interested in learning how to program in Java, then you'll want to read through Part II. Experienced programmers will be able to skip many of the chapters in Part II, but may find that certain areas bear a closer look, especially objects, interfaces, packages, and threads. Part III is essential for understanding how to build Applets, and both novice and experienced programmers will want to study the chapters in this part. Part IV contains reference material which you'll need to have on hand when writing Applets and trying to understand example code. __________________________________________________ THE JAVA SOURCEBOOK by Ed Anuff, HotWired Table of Contents Introduction Chapter 1. GETTING READY FOR JAVA Chapter 2. WEB BROWSING AND JAVA Chapter 3. UNDERSTANDING JAVA Chapter 4. BUILDING JAVA APPLICATIONS Chapter 5. JAVA BASICS Chapter 6. FLOW OF CONTROL Chapter 7. OBJECTS AND CLASSES Chapter 8. INTERFACES Chapter 9. PACKAGES Chapter 10. MANAGING DATA WITH OBJECTS Chapter 11. HANDLING EXCEPTIONS Chapter 12. THREADS Chapter 13. APPLET OVERVIEW Chapter 14. APPLET BASICS Chapter 15. APPLET USER INTERFACES Chapter 16. GRAPHICS Chapter 17. MULTIMEDIA Appendix A: Package java.app Appendix B: Package java.awt Appendix C: Package java.awt.image __________________________________________________ THE JAVA SOURCEBOOK (ISBN 0-471-14859-8, $29.95) is available at your favorite bookstore, online or offline. You can also order the book directly from the publisher: John Wiley & Sons 605 Third Avenue New York, NY 10158-0012 Toll Free 1-800-225-5945 Web: Contents of this file are copyright 1996 by John Wiley & Sons. Please request permission from the publisher before transmitting or reproducing this file. Thank You