Java applets are only as useful as the Web browsers that support them. Although Netscape Navigator is certainly a strong contender for the Java support crown, Sun has its own browser that is specifically designed with Java in mind: HotJava. The HotJava Web browser builds on the techniques established by NCSA Mosaic and Netscape Navigator, while adding the capability to add new behaviors dynamically. The tight link to the Java language is what enables HotJava to have this dynamic behavior.
In this chapter, you learn all about HotJava, including its major features and how to install and use it. Although HotJava as a software product is still in the development stages, it is readily available and quite usable in its current alpha form. This chapter explores the primary features of HotJava and how they impact Web navigation and the Java language.
Before getting into the specifics of how to install and use HotJava, it’s important to take a look at why HotJava is important. Actually, if you first want to literally take a look at HotJava, check out Figure 9.1.
FIGURE 9.1.
The HotJava Web browser.
Figure 9.1 shows what HotJava looks like. You’ll learn about how to use HotJava a little later in this chapter. For now, it’s important to understand why HotJava is significant as a Web browser. There are a variety of technical innovations in HotJava that promise to make it more extensible than other Web browsers. These innovations stem largely from the fact that HotJava is designed around supporting the Java language.
The primary innovation that sets HotJava apart from other browsers is its extensibility. Where other browsers have most or all of their components hardwired to the executable browser application, HotJava opts for a more distributed approach. This means that by itself, HotJava doesn’t really support any object types or Internet protocols. But its extensible design provides a very open path to add support without modifying the HotJava application itself. Furthermore, HotJava can be extended to provide new support automatically and on demand without the user even having to know.
Following is a list of the major features in HotJava:
Along with dynamic content within Web pages, HotJava also aims to be dynamic on a few other fronts. One of these fronts is the support for dynamic object types. An object type refers basically to a file format, such as the popular GIF (Graphics Interchange Format) graphics files. Although most Web browsers provide support for the most popular object types right now, who’s to say what new object types will appear in the future? Obviously no one knows what object types will become popular in the future. For this reason, HotJava takes an open-ended approach to supporting object types. HotJava is capable of dynamically linking to Java code for handling a particular object type on the fly. Rather than Sun having to create a new version of HotJava each time a new object type appears on the scene, HotJava can instead locate an object handler and deal with it dynamically. Incidentally, object handlers are also known as content handlers. Figure 9.2 shows the difference between HotJava’s dynamic connection to objects and a conventional Web browser’s built-in support for objects.
Notice in the figure that both approaches provide similar support for object types that are currently popular. The difference arises when new types are introduced; HotJava transparently attaches to the handlers for new object types, whereas other browsers must implement handlers internally.
You may be wondering where the object handlers come from, and how HotJava knows about them to begin with. Typically, the vendor that creates an object will also create a handler routine for interpreting the object. As long as the handler is present on a server with the objects in question, HotJava can link to the code and automatically upgrade itself to support the new object type. While other Web browser developers are busily hacking in patches to support new object types, HotJava users will be automatically and transparently upgrading each time they encounter a new object type.
FIGURE 9.2.
How HotJava and conventional Web browsers differ in their handling of objects .
Similar to its dynamic support for new object types, HotJava also takes a dynamic approach to handling new Internet protocols. The most important components of the Internet are the protocols used for each medium of communication, such as HTTP or FTP. Think back to the days before the HTTP protocol and you’ll realize what I mean! As with objects, there is no way to foresee what new Internet protocols will spring up in the future. The best way to handle this unknown is to anticipate a certain flux in protocol growth and write applications that can adapt to change. Sun did exactly this by designing HotJava so that it could dynamically link in support for new protocols.
You are probably familiar with Internet URLs, which define the location of Internet resources. An example URL follows:
http://www.javasoft.com/
This URL is for Sun’s Java home page. As you can see, the protocol type for this URL is specified at the beginning of the URL name. In this case, the protocol type is specified as http, which stands for hypertext transfer protocol. Most Web browsers have built-in functionality to handle protocols such as HTTP. HotJava, on the other hand, looks externally to handle different protocols. When HotJava encounters a URL, it uses the protocol name to determine which protocol handler to use to find a document. Like a handler for an object, a protocol handler is a separate piece of code that defines how to interpret information from a particular protocol. Figure 9.3 shows the difference between how HotJava and conventional browsers manage protocols.
FIGURE 9.3.
How HotJava and conventional Web browsers differ in their handling of protocols.
You may have noticed that Figure 9.3 looks very similar to Figure 9.2. Indeed, HotJava’s support for new protocols parallels its support for new object types. The same approach of forcing outside handlers to provide the specific implementations for new objects works equally well when dealing with new protocols.
When you start thinking about interactive content and what it means to the broad base of users it will affect, there is an unavoidable issue of security. To get an idea of how important the issue of security is, think back to how things were before the Web. Prior to the Web, online services, independent bulletin boards, and private networks served as the primary electronic communication mediums. Most of these mediums were and still are completely based on static content. Even so, the instances of viruses and other security-related problems have always been in relative abundance. In most of these cases, users would knowingly transfer a file to their computer that was assumed to be safe. The file would end up doing harm to their machine once it was transferred. Obviously, the users wouldn’t have transferred the file if they had known about the virus beforehand. The point is that even with users having complete control over which files are transferred, viruses have still flourished.
Now consider the possibilities for security breaches with interactive content in the global Internet environment. Given that users are able to interact with Web pages in an interactive environment, the software must be able to respond dynamically. You’ve probably guessed that this creates a potentially dangerous situation. This brings us to the next key issue in the design of HotJava: security.
In HotJava, you can specify security options relating to what access you want to allow incoming executable content to have to your machine. You can specify whether and how much you want to allow applets to be able to read, write, or change files on your machine. You can set up security regions in HotJava by creating firewalls. A firewall is typically a set of computers within a certain domain name. Usually these computers are assumed to be safe, so they are listed as being located behind the firewall. You’ll learn more about configuring firewalls later in this chapter.
The majority of the features implemented in HotJava stem from the fact that HotJava is designed around supporting Java. Before getting into more specifics regarding HotJava, it is important to clarify the relationship between Java and HotJava.
To recap prior chapters, Java is an object-oriented programming language derived in many ways from C++. Java enables you to write programs and applets that can be embedded in Web pages and executed interactively. HotJava is a Web browser written in Java that implements object and protocol handlers as external libraries. HotJava is akin to Netscape Navigator or NCSA Mosaic, with the primary difference being that it is written in the Java language and is far more extensible.
The Java language and HotJava browser are both very new technologies that are still in the developmental stages. The first released version of the Java language was known as the alpha release. A decent number of programs were written under the alpha release and are still around. However, Sun later released a beta version of Java with some major changes to the programming interface. This resulted in a rift between programs written using the alpha release of Java and programs written using the beta release. Add to this confusion the release of a final version of Java.
With the release of the beta version of Java, Sun declared the Java API frozen, meaning that none of the existing classes would be modified in the final release. However, this didn’t restrict Sun from adding new classes and methods to Java; it just meant they couldn’t change the old ones. This results in backward compatibility between the final and beta versions of Java; all beta programs should compile and run fine under the final release of Java.
The remaining problem then is what to do about the alpha programs still in existence? Most developers have already ported or begun porting their alpha programs to the beta, and now, final releases. All new Java development should be focused on the final release.
But there’s always a catch! The problem right now is that Sun has focused its efforts on polishing Java, and has kind of dropped the ball on bringing HotJava up to date. What this means is that the alpha release of HotJava, which is the latest, only supports alpha Java applets. You can’t program to the final Java API and incorporate the applets into the current version of HotJava. Hopefully, by the time you read this Sun will be closer to releasing a beta or even final version of HotJava, but it’s still too early to guess.
So, you may be wondering how to deal with this problem? Do you go ahead and write outdated alpha code so you can use HotJava, or do you blindly write final code and pray that a new version of HotJava that will run the final code will be released soon? The answer is neither. In light of this problem, Sun released an applet viewer program that supports the final release of Java. Additionally, Netscape Navigator 2.0 is supposed to fully support the Java final release. You’ll learn more about the applet viewer in Chapter 10, “The Java Developer’s Kit.” You can use either of these applications as a test bed for final release Java applets.
You’re probably wondering why bother discussing HotJava when it’s currently not even useful for working with the final release of Java? The answer is that HotJava is an important technology, and all release delays aside, it will still be an important application for Web users and Java programmers in the future. Furthermore, because it is itself written in Java, it will be without a doubt the most Java-compatible browser around. In the meantime, you can still have a lot of fun with HotJava by running the many alpha Java programs that are available.
Installing and configuring HotJava is pretty straightforward. Before you begin installing HotJava, you may want to check and see if there is a newer release than the one you have. At the time of this writing, the latest release of HatJava was alpha release 3. This version will run alpha Java applets fine, but you may want to check directly with Sun to find out the latest version of HotJava available. Sun maintains a Web site devoted entirely to Java and HotJava. You actually saw the Java URL earlier in this chapter, but here it is again:
http://www.javasoft.com/
This is the same place where you can download the latest release of the Java Developer’s Kit (JDK). You’ll learn more about the JDK in Chapter 10. This is also the primary location for learning the latest news and support issues surrounding Java and HotJava. Figure 7.1 in Chapter 7 shows what the Java Web site at Sun looks like.
HotJava usually comes compressed in a self-extracting archive. To install HotJava, you simply execute the archive file from the directory where you want HotJava installed. For example, if you want to install HotJava on a Windows 95 machine, you would execute the self-extracting archive file from the C:\ root directory. The archive will automatically create a HotJava directory below C:\ and build a directory structure within it to contain the rest of the support files. All the related files are automatically copied to the correct locations in the HotJava directory structure.
| NOTE |
|---|
| The current alpha release of HotJava only supports the Solaris and Windows 95/NT platforms. It is expected that a commercial release of HotJava will also support Macintosh and Windows 3.1, but at this point it is still speculation. |
Once HotJava is installed, you are ready to run it. You run HotJava by executing the program HotJava.exe, which is located in the HotJava\bin directory. You can specify a URL as a parameter to HotJava. If specified, HotJava will open the document specified by this URL rather than the default URL document. Assuming you don’t enter a URL when you start HotJava, you will be presented with the Welcome page shown in Figure 9.1 earlier. You’ll definitely want to try out some of the links on this page later. If this is the first time you’ve run HotJava, you’ll also be presented with the Security dialog box shown in Figure 9.4. Just click the Apply button for now and everything will be OK. You’ll learn more about the security options in this dialog box a little later in this chapter.
FIGURE 9.4.
The HotJava Security dialog box.
HotJava uses three system environment variables to determine various options for the browser. These environment variables follow:
The HOTJAVA_HOME variable specifies the path where HotJava looks for resources in order to run. HOTJAVA_HOME defaults to being set to the directory where HotJava was installed. The WWW_HOME variable specifies the default home page used in HotJava. This is the page HotJava attempts to load on startup. WWW_HOME defaults to being unset. If it is left unset, HotJava defaults to the URL doc:///index.html, which is the Welcome page.
The HOTJAVA_READ_PATH variable specifies a colon-separated list of files and directories to which Java applets have read access. The default setting for HOTJAVA_READ_PATH is <hotjava-install-dir>:$HOME/public_html/. You give read access to new files and directories by adding a colon and the file or directory onto the end of the list. For example, if you wanted to give the Docs directory read access, and it was located just off of the root directory, you would set HOTJAVA_READ_PATH to the following:
<hotjava-install-dir>:$HOME/public_html/:$HOME/Docs/
Similarly, HOTJAVA_WRITE_PATH specifies a list of files and directories that Java applets have write access to. Any files or directories not explicitly given read or write permission through these variables will be inaccessible to Java applets.
Now that you have HotJava up and running, you’re ready to learn some more about how to use it. The HotJava browser application is composed of five major parts, which follow:
To see where these parts are located in HotJava, refer back to Figure 9.1, which shows the HotJava application window. The HotJava menu bar is located just below the caption bar for the application, and consists of a series of pull-down menus. You’ll learn about the specific menu commands a little later in this chapter. The URL edit box is located just below the menu bar and is used to manually enter document URLs. You’ll learn how to enter URLs in HotJava in the next section of this chapter.
The client area of HotJava is located just below the URL edit box and extends down to the toolbar near the bottom of the application window. The client area takes up most of HotJava’s screen real estate, and is where documents are displayed. Because the client area is where documents are displayed, it is also the display area for Java applets.
The HotJava toolbar consists of five buttons and is located just below the client area. These buttons are used to navigate through Web pages. The Left and Right Arrow buttons are used to move forward and backward through documents that you have already viewed. The Home button takes you to the default home page for HotJava. If you recall, this page is specified by the WWW_HOME environment variable. The Reload button is used to reload the current document. And finally, the Stop button is used to stop the loading of a document.
The status bar is used to inform you of the status of operations. For example, while a document is being fetched, the status bar displays a message notifying you that it is fetching the document. The status bar also displays the names of links to documents when you drag the mouse over them.
Document URLs are specified by entering them into the URL edit box near the top of the HotJava application window. To open a new URL document, simply type the name into the edit box and press Return. HotJava will immediately start fetching the document, which will be evident by the message displayed in the status bar.
To stop fetching a document, just click on the Stop button. The Stop button only stops the loading of HTML pages; it does not stop or even affect any running Java applets.
The HotJava menu commands provide access to all the functionality in HotJava. These menu commands can be grouped into five categories, which correspond to the pull-down menu names shown in the menu bar. Following are the menu command categories:
The File menu commands consist of commands related to managing URL documents. Some commands are listed under the File menu but remain unsupported in the alpha release of HotJava. The following File menu commands are supported under the alpha 3 release of HotJava:
The Open command displays a dialog box where you can specify a document URL to open. This functionality is identical to typing a document URL in the URL edit box below the menu bar. The Reload command reloads the current document. Selecting the Reload command is exactly the same as clicking the Reload button on the toolbar. The View Source command opens up a window containing the HTML source code for the current Web page. Finally, the Quit command exits the HotJava application.
The Options menu commands are used to specify HotJava environment options. A few commands are listed under the Options menu but remain unsupported in the alpha release of HotJava. The following Options commands are supported under the alpha 3 release of HotJava:
The Security command opens a dialog box where you specify the level of security to be applied to incoming executable content. This is the same dialog shown in Figure 9.4 that is displayed the first time you run HotJava. The dialog box provides the following security modes to choose from: No access, Applet host, Firewall, or Unrestricted. The No access security mode specifies that HotJava cannot load any Java applets. This is the safest, but obviously most restricted security mode. The next safest mode is Applet host, which specifies that HotJava can only run Java applets residing on the local machine. Next comes the Firewall security mode, which specifies that HotJava can only run applets from behind the firewall. Finally, the Unrestricted mode allows HotJava to load any Java applets.
If you select the Firewall security mode, you’ll need to configure the firewall. You do this by clicking the Configure Firewall button. When you click this button, the dialog box shown in Figure 9.5 appears.
The purpose of this dialog box is to enable you to specify which systems are located behind the firewall; that is, which systems are considered safe. You specify systems within the firewall by entering the domain or host name of the system, selecting whether it is a domain or host in the drop-down list, and then clicking the Add button. You can change or delete firewall entries by using the Change and Delete buttons. Once you are happy with the firewall settings, click Apply to accept them.
The Properties menu command opens a dialog box which lets you change general HotJava properties. The Properties dialog box is shown in Figure 9.6.
FIGURE 9.5.
The HotJava Configure Firewall dialog box.
FIGURE 9.6.
The HotJava Properties dialog box.
The first few properties in this dialog box enable you to specify different proxies and their associated ports. The Firewall Proxy refers to the host name and port number of a local firewall proxy server. The FTP Proxy is the host name and port number of an HTTP proxy to use for all FTP URLs. Finally, the Caching Proxy refers to the host name and port number of a caching server. If you don’t want to use any of the proxies, just leave the check boxes next to each one unchecked.
The Properties dialog also enables you to view the read and write paths for HotJava. These are the same paths specified by the HOTJAVA_READ_PATH and HOTJAVA_WRITE_PATH environment variables. You cannot modify these variables from the Properties dialog box.
The Underline anchors property determines whether or not HTML anchors (links) are underlined when displayed. The Delay image loading and Delay applet loading properties determine how images and applets are loaded in HotJava. If you check these options, HotJava will only load images and applets when you click on them. This is sometimes useful when you have a slow connection. If you leave these options unchecked, HotJava will load all images and applets along with the rest of an HTML page.
The Flush Cache menu command flushes any images and audio that have been cached by HotJava. Typically HotJava will cache the most recently used images and audio to your hard drive in order to speed up loading time. You may want to use the Flush Cache command if you know a cached image or sound has changed and should be transferred again.
The Progress Monitor menu command brings up a window with a progress monitor for seeing how much of a document has been loaded. Figure 9.7 shows what the progress monitor looks like in action.
FIGURE 9.7.
The HotJava Progress Monitor window.
The progress monitor is considered an experimental tool, but is still interesting in its current form. You can watch and see the status of different objects as they are loaded.
The Navigate menu commands provide you with a means to navigate through documents. The commands listed under the Navigate pull-down menu that are supported under the alpha release of HotJava follow:
The Forward command moves to the document viewed prior to selecting the Back command or button. This means that the Forward command can only be used after you have used the Back command. The Back command moves back to the last document viewed. The Home command displays the default HotJava home page, which is specified in the WWW_HOME environment variable. All three of these commands perform the exact same functionality as their equivalent buttons on the toolbar.
HotJava automatically maintains a history list of documents that have been viewed. The Show History command displays the history list and enables you to revisit a document in the list. Figure 9.8 shows what the HotJava History List window looks like.
FIGURE 9.8.
The HotJava History List Window.
To open a document in the history list, simply click on the document and click the Visit button. The history list is cleared each time you start HotJava.
Along with the history list, HotJava also keeps up with a hotlist, which is a list of favorite documents. The Add Current to Hotlist command adds the currently viewed document to the hotlist. To see what documents are in the hotlist, use the Show Hotlist command. HotJava’s hotlist is very similar in function to Netscape’s bookmarks and Internet Explorer’s favorite places. When you select Show Hotlist, you’ll see the window shown in Figure 9.9.
FIGURE 9.9.
The HotJava Hotlist window.
You can visit a document in the hotlist by clicking on the document and clicking the Visit button. You can also delete documents from the list using the Delete button. There is one additional feature of the hotlist that you may be curious about: a check box labeled In Goto Menu. This check box enables you to choose documents in the hotlist that will also appear as menu selections under the Goto pull-down menu.
The Goto menu consists of a single command and multiple document links. The Goto menu is used as a list of links to the most important documents in the hotlist. You can quickly open documents in the Goto menu by selecting the document entry in the menu. The only command supported under the Goto menu is Add Current, which adds the current document to the hotlist and the Goto menu itself.
The Help menu consists of a variety of links to useful HTML documents, along with one command. Each document link is pretty self-explanatory, so you can explore them on your own. The only command on the Help menu is the Search HotJava Documentation command. This command enables you to search the HotJava documentation for a particular topic. Figure 9.10 shows what the documentation search dialog box looks like.
FIGURE 9.10.
The HotJava documentation search dialog box.
To search on a topic, just type the topic in the query edit box and click the Search button. Documents found matching the topic are listed in the list box. To go to one of the matching documents, just click on it in the list box.
HotJava provides visual status indicators when it is loading document information. These indicators, or icons, are displayed in place of the object they are loading until the object has been successfully loaded. The different status icons supported by HotJava follow:
The raised gray box means that an image or applet is still loading. The yellow box means that delayed image loading is in effect for an image. To load the image you must click on the icon. The yellow box with an arrow means that delayed image loading is in effect for an image and that the image is a link to another document. Clicking on the arrow opens the linked document, and clicking on any other part of the icon loads the image. The orange box is similar to the yellow box except it deals with Java applets rather than images; it specifies that delayed applet loading is in effect for an applet. To load the applet, just click on the icon.
Both red box icons mean that an error has occurred while attempting to load an image or applet. The difference between the two is that the icon with an arrow specifies that a document link has failed to load, rather than the image or applet itself.
In this chapter you learned all about the HotJava Web browser and how it relates to Java. It is not clear whether Sun intends for HotJava to be a serious competitor in the Web browser market. Nevertheless, it will be the browser to watch when it comes to providing complete Java support in the future. As a result of its support for Java, HotJava has the potential to be a technologically superior Web browser through its extensible support of dynamic content, objects, and Internet protocols.
The only downside to HotJava at this point is that it is still an unfinished product, and as a result has a versioning conflict with the latest version of Java. Nevertheless, it is only a matter of time before HotJava will be a crucial Internet technology, simply because of its tight link to the Java language.
Now that you have HotJava pretty well figured out, it92's time to press on and learn more about Java itself. The next chapter covers the Java Developer’s Kit, which is the standard toolkit for developing Java programs.