This chapter addresses the three questions implied by this book's title:
The first question is answered by considering the tremendous growth of all activity that surrounds the Internet and the World Wide Web. The second question is answered by examining the capability of Java to address the shortcomings of existing Web technologies and through the consideration of the general purpose strengths of the language. The question of why you should use Visual J++ is answered with a brief overview of the product's many features.
The tremendous growth in the popularity of the Internet, and of the World Wide Web in particular, has created entire new worlds of programming possibilities. The Internet and corporate intranets have been posed as both the death of client/server programming and as the next logical step in client/server programming. At the center of all of this is the Java language, a language originally designed for use in video-on-demand systems but which found a more natural fit in the World Wide Web.
Of course, as exciting and important as Web programming is, it is not without its problems. In particular, there are two problems that have traditionally plagued World Wide Web development:
Although these problems are related, each warrants independent consideration.
Current Web pages are very good at conveying some types of information but are inadequate for conveying other types. In particular, Web pages excel at conveying passive, static information. This type of information changes infrequently (static) and doesn't change in response to user interactions with it (passive).
For example, there are many Web pages that let you enter a company's name or stock ticker symbol and receive current price quotes. One of the best is the APL Quote Server located at http://qs.secapl.com/cgi-bin/qs and shown in Figure 1.1. This page is static because it isn't automatically updated with new quotes while the page is being browsed. It is passive because the user cannot interact with the page, other than to request to see a similar page.
Figure 1.1 : Retrieving passive, static stock prices.
Older Web development technologies excelled at displaying this type of page. Much of human communication is passive, static, or both. A highway billboard is a perfect example of a conventional means of communication that is both passive and static. Television is an example of nonstatic, but passive, communication.
Just as not all billboards will go the way of Burma Shave, not all passive, static Web content needs to become active and dynamic (the opposites of passive and static). However, there is a tremendous demand for technologies that enable the creation of active, dynamic World Wide Web content.
In the pre-Java world of the Web, as a developer of Web content and pages, you could not count on your users having a specific browser configuration. You could create a Web page with leading edge graphics, sound, and real-time multimedia. Unfortunately, if any of the visitors to your Web site did not configure a browser add-on to handle the latest whiz-bang features, these users wouldn't get the full impact of your site.
The inability to know what features will be supported by the visitors to your Web site has traditionally led many sites to be developed to a lowest common denominator. These problems are compounded by the differences in a user's browser, his hardware, and his operating system.
Much of the excitement over Java comes from the capability of Java to solve the problems of passive content and browser dependence. Java is a nearly ideal language for programming the World Wide Web. However, applications for Java programs go beyond the Web and reach far into the domain of traditional programming languages.
By using Java, you can take your Web pages beyond the world of passive, static content and into a world of active, dynamic content. This is more than just an esthetic difference. It is a difference that affects the types of problems that can be solved on the World Wide Web. Because of this, Java is an enabling technology. With Java you are able to solve entire classes of problems that you would not be able to solve without Java.
Take a moment to look back again at Figure 1.1. This static, passive Web page shows the price of a stock at a specific moment in time. There is so much more that could be, should be, on this page. This is where Java comes in. With Java, you could create a page that shows a graph of the stock's price over time and have that graph continue to update in real time while you browse the page. Because Java is a full-featured programming language, Web pages like this become much more feasible. Sun Microsystems has created a page that does exactly this. It is located at http://java.sun.com/java.sun.com/applets/applets/StockDemo/index.html and is shown in Figure 1.2.
Figure 1.2 : A Java version of a stock price Web page.
On the Java Web page shown in Figure 1.2, there is a line of stock ticker symbols and prices that scrolls across the top of the screen. Below that are graphs for the stock of three different companies. Each of these graphs is updated every five seconds based on the latest trades. (As described in Figure 1.2, this page is just an illustration, and the prices of the NEATO company are randomly generated.)
In addition to being an enabling technology that enables your Web pages to become active and dynamic, Java again serves as an enabling technology by freeing you from concerns about how each user has configured his browser. Java enables you, as a Web developer, to create Web pages that will be delivered consistently to all users with a Java-enabled browser.
Not only does Java free you from concerns about how users have configured their Web browsers, but it also frees you from concerns about which hardware and operating system platform they are using. Because Java source code is interpreted, if a Java interpreter exists for a specific hardware and operating system platform, you can write programs with the knowledge that they will be usable on that platform.
Of course, the use of Java extends beyond the Web, and there is much to recommend Java as a general purpose development language. The same hardware and operating system independence that Java brings to the Web is a benefit to other programming tasks as well.
Because Java borrows much of its syntax and many of its concepts from C and C++, there is a pre-existing pool of programmers who could quickly learn Java. However, Java goes far beyond being a mere derivative of C++. It adds to C++ in the areas of automatic memory management and language-level support for multithreaded applications. On the other hand, Java remains easier to learn and simpler to use than C++ because of those C++ features that were left out of Java: multiple inheritance, pointers, and the goto statement, among others.
Because implementations of the Java Virtual Machine can be very
efficient, it is possible for Java programs to run almost as quickly
as C++ programs. This is a key feature in convincing developers
that Java is a viable language for non-Internet development. Because
of Java's strengths as an Internet language, many of these same
strengths apply when Java is used as a language for client/server
development. It is very likely that as corporations do more and
more Internet development in Java, they will begin to apply these
same Java developers to their client/server projects. Java's strengths
in terms of network-awareness, security, portability, and performance
make it ideally suited for corporate client/server development,
as well as Internet development.
| NOTE |
In discussing Java programs, it has become standard to refer to Java programs that are embedded in another language as applets and to stand-alone programs as applications. For example, when using Java to augment a World Wide Web page, the Java code is embedded within HTML code. Therefore, this is referred to as an applet. On the other hand, a Java program that is not embedded within HTML, or any other language, and can stand on its own is referred to as an application Of course, there is a subtle implication here that applications are larger (and, therefore, presumably more complex) than applets. However, this is not necessarily true. Applications and applets alike can range from simple one class programs to programs with hundreds of classes. The implication that an applet is somehow less than an application is unfortunately a connotation it is necessary to live with in an otherwise valid distinction. |
Having seen that Java is equally suited as a language for development both on and off the Internet, it's time to look more closely at the Java language itself. The creators of Java at Sun Microsystems have defined the Java language as "A simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, and dynamic language." Well, they managed to fit all of the important 1990s buzzwords into one sentence, but we need to look more closely at Java to determine whether they managed to fit all these concepts into one language.
If you have experience with any object-oriented language, especially C++, you will probably find Java to be easier than your high school prom date. Because Java started out as C++ but has had certain features removed, it is certainly a simpler language than C++. Some of the most difficult aspects of C++ programming are related to memory management and the use of pointers. Many, if not most, C++ programs contain memory leaks that will eventually cause the system to run out of memory.
Java prevents this by not allowing a program to directly manipulate memory addresses through the use of pointers. Additionally, Java performs automatic memory management, sometimes called garbage collection. With garbage collection you do not need to remember to free every memory resource you allocate. The system keeps track of allocated resources for you and automatically releases each when you are finished with it.
Of course, Java is object-oriented. In fact, in the mid-1990s it's hard to imagine someone developing a new language and declaring it the greatest new thing without it being object-oriented. In its approach to object-orientation Java follows most closely along the lines of languages such as SmallTalk than C++. Except for its primitive data types, everything in Java is an object. In contrast, C++ is much more lax in that you are entirely free to mix and match object-oriented code (classes) and procedural code (functions). In Java, this is not the case. There are no global functions in Java: All functions are invoked through an object.
Java's support for object orientation does not include multiple inheritance. The designers of the language felt that the complexity introduced by multiple inheritance was not justified by its benefits. Multiple inheritance has been replaced in Java with the concept of interface inheritance. While a Java class can only be a subclass of one other class, it can implement multiple interfaces.
Java classes are comprised of methods and variables. Class methods are the functions to which an object of the class can respond. Class variables are the data that define the state of an object. In Java, methods and variables can be declared as private, protected, or public. Private methods and variables are not accessible outside of the class. Protected members are accessible to subclasses of the class, but not to other classes. Finally, public methods and variables are accessible to any class.
Java facilitates the building of distributed applications by a collection of classes for use in networked applications. By using Java's URL (Uniform Resource Locator) class, an application can easily access a remote server. Classes are also provided for establishing socket-level connections.
Because Java is interpreted, once the Java interpreter has been ported to a specific machine, that machine can instantly run the growing body of Java applications. As the body of existing Java source code increases, this becomes an increasingly important advantage. This means that by porting a single application-the Java virtual machine-all existing Java programs become available for use on that machine.
Also, when using an interpreter, programmers are freed from some of the concerns of intermodule dependencies. You no longer have to maintain a make file that is sometimes as complicated as the hardest part of your program.
Another advantage to using an interpreter is that the time-consuming, edit-compile-link-test cycle is broken. Without the compile and link steps, working in an interpreted environment is a much simpler edit-test cycle. Even with today's quick C++ compilers, it is not uncommon for a complete recompile and relink of a large program to be measured in hours and take the better part of a day. Without having to wait for lengthy compiles and links, Java promotes prototyping and easier debugging.
The designers of Java anticipated that Java would be used to solve some very complex programming problems. Writing a distributed, multithreaded program that can run on a variety of operating systems with a variety of processors is not a simple task. To do it successfully, you need all the help your programming language can offer you. With this in mind, Java was created as a strongly typed language. Data type issues and problems are resolved at compile-time and implicit casts of a variable from one type to another are not allowed.
Memory management has been simplified in Java in two ways. First, Java does not support direct pointer manipulation or arithmetic. This makes it impossible for a Java program to overwrite memory or corrupt data. Second, Java uses runtime garbage collection instead of explicit freeing of memory. In languages like C++ it is necessary to delete or free memory once a program has finished with it. Java follows the lead of languages such as Lisp and SmallTalk by providing automatic support for freeing memory that has been allocated but is no longer used.
Closely related to Java's robustness is its focus on security. Because Java does not use pointers to directly reference memory locations, as is prevalent in C and C++, Java has a great deal of control over the code that exists within the Java environment.
It was anticipated that Java applications would run on the Internet and that they could dynamically incorporate or execute code found at remote locations on the Internet. Because of this, the developers of Java have hypothesized the existence of a hostile Java compiler that would generate Java byte codes with the intent of bypassing Java's runtime security. This led to the concept of a byte code verifier. The byte code verifier examines all incoming code to ensure that the code plays by the rules and is safe to execute.
Back in the dark ages of the early 1980s there was tremendous variety in desktop personal computers. You could buy computers from Apple, Commodore, Radio Shack, Atari, and eventually even from IBM. Because developing software is such a time-consuming task, very little of the software developed for use on one machine was ever ported and then released for use on a different machine.
In many regards this situation has improved with the acceptance of Windows, the Apple Macintosh, and UNIX variations as the only valid personal computer options. However, it is still not easy to write an application that can be used on Windows NT, UNIX, or a Macintosh. And it's getting more complicated with the move of Windows NT to non-Intel CPU architectures.
There are a number of commercially available source code libraries (for example, Zinc, ZApp, and XVT) that attempt to achieve application portability. These libraries attempt this by focusing on either on a lowest common denominator among the operating systems or by creating a common core API (Application Programming Interface).
Java takes a different approach. Because the Java compiler creates byte code instructions that are subsequently interpreted by the Java interpreter, architecture neutrality is achieved in the implementation of the Java interpreter for each new architecture.
In addition to being architecture-neutral, Java code is also portable. It was an important design goal of Java that it be portable so that as new architectures (either due to hardware, operating system, or both) are developed, the Java environment could be ported to them.
In Java, all primitive types (integers, longs, floats, doubles, and so on) are of defined sizes, regardless of the machine or operating system on which the program is run. This is in direct contrast to languages like C and C++ that leave the sizes of primitive types up to the compiler developer.
Additionally, Java is portable because the compiler itself is written in Java and the runtime environment is written in POSIX-compliant C.
For all but the simplest or most infrequently used applications, performance is always a consideration. It is no surprise then to discover that achieving high performance was one of the initial design goals of the Java developers. A Java application will not achieve the performance of a fully compiled language such as C or C++. However, for most applications, including graphics-intensive ones such as are commonly found on the World Wide Web, the performance of Java is more than adequate. For some applications, there may be no discernible difference in performance between C++ and Java.
Many of the early adopters of C++ were concerned about the possibility of performance degradation as they converted their programs from C to C++. However, many C++ early adopters discovered that while in some cases a C program will outperform a C++ program, the additional development time and effort doesn't justify the minimal performance gains. Of course, since we're not all programming in assembly language, there must be some amount of performance we're willing to trade for faster development.
It is very likely that early experiences with Java will follow these same lines. While a Java application may not be able to keep up with a C++ application, it will normally be fast enough, and Java may enable you to do things you couldn't do with C++.
Writing a computer program that only does a single thing at a time is an artificial constraint that we've lived with in most programming languages. With Java, we no longer have to live with this limitation. Support for multiple, synchronized threads is built directly into the Java language and runtime environment.
Synchronized threads are extremely useful in creating distributed, network-aware applications. Such an application may be communicating with a remote server in one thread while interacting with a user in a different thread.
Because it is interpreted, Java is an extremely dynamic language. At runtime, the Java environment can extend itself by linking in classes that may be located on remote servers on a network (for example, the Internet). This is a tremendous advantage over a language like C++ that links classes prior to runtime.
In C++, every time member variables or functions are added to a class, it is necessary to recompile that class and then all additional code that references that class. Of course, the problem is exacerbated by the fact that you need to remember to recompile the files that reference the changed class. Using make files reduces the problem but for large, complex systems doesn't eliminate it.
Java addresses this problem by deferring it to runtime. At runtime, the Java interpreter performs name resolution while linking in the necessary classes. The Java interpreter is also responsible for determining the placement of objects in memory. These two features of the Java interpreter solve the problem of changing the definition of a class used by other classes. Because name lookup and resolution is performed only the first time a name is encountered, only minimal performance overhead is added.
This section answers the question of why Visual J++ is the best choice for Web programming with Java. The most compelling reason to select Visual J++ as your Java development environment is the strength of the product itself. Visual J++ features a proven IDE (Integrated Development Environment) in its Developer Studio. The Visual J++ Developer Studio is essentially the same IDE as is provided with Microsoft's Visual C++. In addition to providing an established IDE, Visual J++ offers a number of Java-specific features. Included among these are the Java Applet Wizard, the Resource Wizard, and a debugger that lets you debug a Java applet running in a browser.
The Developer Studio serves as the focal point for the tools and features of Visual J++. While in the Developer Studio you can edit source code, create new projects, compile projects, start a debugging session, and use visual tools to design dialogs and menus. For example, Figure 1.3 shows the Developer Studio while being used to simultaneously edit a Java source code file, view help information, and design a new dialog.
Figure 1.3 : The Visual J++ Developer Studio.
The Developer Studio features a Project Workspace window that enables you to view your project. From the Project Workspace you can view a project in the old-fashioned, file-oriented view. You can see a list of files included in the project, double-click a file, and then edit that file. Alternatively, you can use what is called the ClassView. The ClassView presents a more natural, and more useful, view of a project's components. Instead of selecting an item to edit from a list of files, you select the class or method within that class you want to edit. A source code editing window is automatically opened and the cursor positioned to the correct place. The ClassView is also shown in Figure 1.3, along the left side of that figure.
The Java Applet Wizard is a very useful little tool that helps you quickly get an applet started and running. The Applet Wizard is a one-way tool that asks you questions on a series of five screens and then generates skeleton Java files and a project. Although the Applet Wizard does not contain any earth-shattering technology, it is a very convenient and time-saving tool. The Applet Wizard can be used to generate significant applets, including applets using animation, event handling, applet parameters, and multiple threads. As an example of the type of questions asked by the Applet Wizard, see Figure 1.4, which shows the first screen of this wizard.
Figure 1.4 : The first screen of the Java Applet Wizard.
The JView stand-alone Java interpreter can be used to run any Java application, including those not written with Visual J++. JView includes a very fast implementation of the Java Virtual Machine. Using JView to run Java applications provides a viable alternative to Web-based applets, in many cases. Because the main subject of this book is the creation of Web-based Java applets, JView will be used very infrequently. However, it is still a useful tool in your collection.
Visual J++ facilitates applet development by providing visual tools for designing dialogs, menus, and images.
The Dialog Editor, which is shown in Figure 1.5, can be used to visually place components such as edit fields, list boxes, radio buttons, and check boxes. As components are placed on the screen, you can set various properties about the components, such as its name and how it will be displayed.
Figure 1.5 : The Visual J++ Dialog Editor.
Despite its name, the Dialog Editor is useful for editing more than just dialogs. The Dialog Editor can be used to design the placement of the components on Java dialogs, frames, panels, and applets themselves.
The Menu Editor, which is shown in Figure 1.6, enables you to visually design a program's menus. Using the Menu Editor, you can easily create one or more menus for use in your program.
Figure 1.6 : The Visual J++ Menu Editor.
The Graphics Editor, which is shown in Figure 1.7, can be used to create and edit the graphic images you may use in your Java programs. The Graphics Editor is a relatively simple image editing program, similar to numerous other programs, including, of course, the Microsoft Paint program.
Figure 1.7 : The Visual J++ Graphics Editor.
If you are familiar with Microsoft Windows programming, you are used to creating dialog and menu resources in a special resource file that is linked into your final program. In Java, dialogs and menus are, instead, created at runtime by code. The Resource Wizard converts the dialogs and menus stored in Windows-style resource files into Java source code that can be added to your project.
Visual J++ includes a very powerful and easy-to-use debugger. Through the debugger Visual J++ can control an applet running in the Internet Explorer. All the features you'd expect to be present are there. You can step through an applet in a variety of ways to step, set breakpoints, and inspect variables. The Visual J++ Debugger is shown in Figure 1.8.
Figure 1.8 : The Debug and Variable Watch windows of the Visual J++ Debugger.
This chapter presented some of the reasons why Web programming with Java, and with Visual J++ in particular, will be an important part of the World Wide Web's future. Java takes the Web into a new world of active and dynamic content. You learned the reasons that support the claim that Java is "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, and dynamic language." Finally, you learned about some of the Visual J++ features that make Java development easier. Among these are the Developer Studio, the Applet Wizard, the Dialog, Menu, and Graphic Editors, the Resource Wizard, and the debugger. In the next two chapters you will learn more about the Applet Wizard and the Developer Studio.