Learning Java

Web Browsers and Handlers

The content- and protocol-handler mechanisms we’ve introduced can be used by any application that accesses data via URLs. This mechanism is extremely flexible; to handle a URL, you need only the appropriate protocol and content handlers. One obvious application is for Java-based web browsers that can handle new and specialized kinds of URLs.

Furthermore, Java’s ability to load new classes over the Net means that, in theory, the handlers don’t even need to be owned by the browser. Content and protocol handlers could be downloaded over the Net from the same site that supplies the data, and used by the browser. If you wanted to supply some completely new data type, using a completely new protocol, you could make your data file plus a content handler and a protocol handler available on your web server; anyone using a Web browser supporting Java could automatically get the appropriate handlers whenever they access your data. In short, Java could allow you to build dynamically extensible web applications. Instead of gigantic do-everything software, you could build a lightweight scaffold that dynamically incorporates extensions as needed.

Figure 12.1 shows the conceptual operation of a downloadable content handler in a web browser; Figure 12.2 does the same for a protocol handler.

Figure 12-1. A content handler at work

Figure 12-2. A protocol handler at work

Unfortunately, a few nasty flies are stuck in this ointment. The schemes depicted in these figures have been part of the Java scene since it was an alpha product, but they are still hypothetical. There is no API for dynamically downloading new content and protocol handlers. In fact, there is no API for determining what content and protocol handlers exist on a given platform. Although content and protocol handlers are part of the Java API and an intrinsic part of the mechanism for working with URLs, specific content and protocol handlers aren’t defined. The standard Java classes don’t, for example, include content handlers for HTML, GIF, MPEG, or other common data types. Sun’s SDK and all of the other Java environments do come with these kinds of handlers, but these are installed on an application-level basis.

There are two real issues here:

• There isn’t a standard that says that certain types of handlers have to be provided in each environment along with the core Java API. Instead we have to rely on the application to decide what kinds of data types it needs. This makes sense but is frustrating when it should be reasonable to expect certain basic types to be covered in all environments.

• There isn’t any standard that tells you what kind of object the content handler should return. Maybe GIF data should be returned as an ImageProducer object, but at the moment, that’s an application-level decision. If you’re writing your own application and your own content handlers, that isn’t an issue: you can make any decision you want. But if you’re writing content handlers that are to be used by arbitrary applications (like HotJava), you need to know what they expect.

For the HotJava web browser, you can install handlers locally (as for all Java applications), but other web browsers such as Netscape and Internet Explorer do not directly support handlers at all. You can install them locally for use in your own (intranet) applets but you cannot use them to extend the capabilities of the browser. Netscape and Internet Explorer are currently classic monolithic applications: knowledge about certain kinds of objects, like HTML and GIF files, is built in. These browsers can be extended via a plug-in mechanism, which is a much less fine grained and less powerful approach than Java’s handler mechanism. If you’re writing applets for use in Netscape or Internet Explorer now, about all you can do is use the openStream( ) method to get a raw input stream from which to read data.

Other Handler Frameworks

The idea of dynamically downloadable handlers could also be applied to other kinds of handler-like components. For example, the XML community is fond of referring to XML as a way to apply semantics to documents and to Java as a portable way to supply the behavior that goes along with those semantics. It’s possible that an XML viewer could be built with downloadable handlers for displaying XML tags.

The JavaBeans APIs also touch upon this subject with the Java Activation Framework. The JAF provides a way to detect the type of a stream of data and “encapsulate access to it” in a Java Bean. If this sounds suspiciously like the content handler’s job, it is. Unfortunately, it looks like these APIs will not be merged in the future.

Writing Content and Protocol Handlers

If you’re adventurous and want to start leveraging content and protocol handlers in your own applications, you can find all the information you’ll need in Appendix A, which covers writing content and protocol handlers.