| In summary, what follows is a list of some common misconceptions about Java, along with commentary. Java is an extension of HTML. Java is a programming language; HTML is a way to describe the structure of a Web page. They have nothing in common except that there are HTML extensions for placing Java applets on a Web page. I use XML, so I don't need Java. Java is a programming language; XML is a way to describe data. You can process XML data with any programming language, but the Java API contains excellent support for XML processing. In addition, many important third-party XML tools are implemented in Java. See Volume 2 for more information. Java is an easy programming language to learn. No programming language as powerful as Java is easy. You always have to distinguish between how easy it is to write toy programs and how hard it is to do serious work. Also, consider that only four chapters in this book discuss the Java language. The remaining chapters of both volumes show how to put the language to work, using the Java libraries. The Java libraries contain thousands of classes and interfaces, and tens of thousands of functions. Luckily, you do not need to know every one of them, but you do need to know surprisingly many to use Java for anything realistic. Java is an easy environment in which to program. The Java SDK is not an easy environment to use except for people who are accustomed to command-line tools. There are integrated development environments that feature integrated editors, compilers, drag-and-drop form designers combined with decent debugging facilities, but they can be somewhat complex and daunting for the newcomer. They also work by generating what is often hundreds of lines of code. We don't think you are well served when first learning Java by starting with hundreds of lines of computer-generated UI code filled with comments that say DO NOT MODIFY or the equivalent. We have found in teaching Java that using your favorite text editor is still the best way to learn Java, and that is what we will do. Java will become a universal programming language for all platforms. This is possible, in theory, and it is certainly the case that every vendor but Microsoft seems to want this to happen. However, there are many applications, already working perfectly well on desktops, that would not work well on other devices or inside a browser. Also, these applications have been written to take advantage of the speed of the processor and the native user-interface library and have been ported to all of the important platforms anyway. Among these kinds of applications are word processors, photo editors, and web browsers. They are typically written in C or C++, and we see no benefit to the end user in rewriting them in Java. And, at least in the short run, there would be significant disadvantages since the Java version is likely to be slower and less powerful. Java is just another programming language. Java is a nice programming language; most programmers prefer it over C or C++. But there have been hundreds of nice programming languages that never gained widespread popularity, whereas languages with obvious flaws, such as C++ and Visual Basic, have been wildly successful. Why? The success of a programming language is determined far more by the utility of the support system surrounding it than by the elegance of its syntax. Are there useful, convenient, and standard libraries for the features that you need to implement? Are there tool vendors that build great programming and debugging environments? Does the language and the tool set integrate with the rest of the computing infrastructure? Java is successful because its class libraries let you easily do things that were hard before, such as networking and multithreading. The fact that Java reduces pointer errors is a bonus and so programmers seem to be more productive with Java, but these are not the source of its success. Java is interpreted, so it is too slow for serious applications. Many programs spend most of their time on things like user-interface interactions or waiting for data from a network connection. All programs, no matter what language they are written in, will detect a mouse click in adequate time. It is true that we would not do CPU-intensive tasks with the interpreter supplied with the Java SDK. However, on platforms where a just-in-time compiler is available, most performance issues simply go away. Finally, Java is great for network-bound programs. Experience has shown that Java can comfortably keep up with the data rate of a network connection, even when doing computationally intensive work such as encryption. As long as Java is faster than the data that it processes, it does not matter that C++ might be faster still. Java is easier to program, and it is portable. All Java programs run inside a Web page. All Java applets run inside a Web browser. That is the definition of an applet a Java program running inside a browser. But it is entirely possible, and quite useful, to write stand-alone Java programs that run independently of a Web browser. These programs (usually called applications) are completely portable. Just take the code and run it on another machine! And because Java is more convenient and less error-prone than raw C++, it is a good choice for writing programs. It is an even more compelling choice when it is combined with database access tools like Java Database Connectivity (see Volume 2). It is certainly the obvious choice for a first language in which to learn programming. Most of the programs in this book are stand-alone programs. Sure, applets are fun. But stand-alone Java programs are more important and more useful in practice. Java applets are a major security risk. In the early days of Java, there have been some well-publicized reports of failures in the Java security system. Most have been in the implementation of Java in a specific browser. Researchers viewed it as a challenge to try to find chinks in the Java armor and to defy the strength and sophistication of the applet security model. The technical failures that they found have all been quickly corrected, and to our knowledge, no actual systems were ever compromised. To keep this in perspective, consider the literally millions of virus attacks in Windows executable files and Word macros that cause real grief but surprisingly little criticism of the weaknesses of the attacked platform. Also, the ActiveX mechanism in Internet Explorer would be a fertile ground for abuse, but it is so boringly obvious how to circumvent it that few have bothered to publicize their findings. Some system administrators have even deactivated Java in company browsers, while continuing to permit their users to download executable files, ActiveX controls, and Word documents. That is pretty ridiculous currently, the risk of being attacked by hostile Java applets is perhaps comparable to the risk of dying from a plane crash; the risk of being infected by opening Word documents is comparable to the risk of dying while crossing a busy freeway on foot. JavaScript is a simpler version of Java. JavaScript, a scripting language that can be used inside Web pages, was invented by Netscape and originally called LiveScript. JavaScript has a syntax that is reminiscent of Java, but otherwise there are no relationships (except for the name, of course). A subset of JavaScript is standardized as ECMA-262, but the extensions that you need for real work have not been standardized, and as a result, writing JavaScript code that runs both in Netscape and Internet Explorer is an exercise in frustration. You should use Java instead of Perl for CGI scripting. This is half right. Not only should you no longer use Perl, you should also not use CGI scripts for server-side processing. Java servlets and Java Server Pages (JSP) are superior solutions. Servlets and JSPs execute much more efficiently than CGI scripts, and you can use Java a real programming language to implement them. Java will revolutionize client-server computing. This is possible and it is where much of the best work in Java is being done. There are quite a few application servers such as BEA Weblogic that are built entirely in Java. Java will allow the component-based model of computing to take off. No two people mean the same thing when they talk about components. Regarding visual controls, like ActiveX components that can be dropped into a GUI program, Java 1.1 includes the JavaBeans initiative (see Volume 2). Java beans can do the same sorts of things as ActiveX components except they are automatically cross-platform. On the server side, reusable enterprise beans can potentially be deployed in a wide variety of application servers. It is possible that a market for these components will materialize, similar to the market of ActiveX components in the Windows world. With Java, I can replace my computer with a $500 "Internet appliance." Some people are betting big that this is going to happen. We believe it is pretty absurd to think that home users are going to give up a powerful and convenient desktop for a limited machine with no local storage. However, a Java-powered network computer may be a viable option for a "zero administration initiative" to cut the costs of computer ownership in a business. We also see an Internet appliance as a portable adjunct to a desktop. Provided the price is right, wouldn't you rather have an Internet-enabled device with a screen on which to read your e-mail or see the news? Because the Java kernel is so small, Java is the obvious choice for mobile telephones and other Internet "appliances."  A good, general source of information on Java can be found via the links on the Java frequently asked questions (FAQ) page: http://java.sun.com/people/linden/intro.html. |
| 
