Distribution History
- As we noted earlier, for most of the
history of Java development, there was really no packaging. For the
most part, the developer was required to put each class file as a
separate file on the web server in the same hierarchy as the
packages defined in your Java files. For example, if you had a
com.test.utility package you would need a directory hierarchy of
com/test/utility under the directory with the main applet
class.
- Unfortunately, this meant that in order for
a web browser to get all of the supporting files it needed, it would
have to open up a separate HTTP connection for each file. Given the state
of web traffic, site overload, and any number of Internet gremlins,
this could add all sorts of delays to the download. What's more, the
files transferred were not compressed in any way.
Archiving Applets with Netscape's ZIP
Format
- Initially, Netscape came to the rescue by
allowing developers to put class files and supporting files like
images and data in a single uncompressed ZIP file. Although, files
were not compressed, this was certainly a valuable distribution
option. Any web surfer who used Netscape Navigator to view a Java
applet need only download a single ZIP file.
- Thus, most developers created an
uncompressed ZIP file and placed it along with the raw class files
on the server. That way, Navigator users could get the speedier ZIP
file and surfers using other Java-enabled browsers could still have
the separate class files available to them. The HTML now evolved to
something like this:
<HTML>
<HEAD>
<TITLE>My Applet</TITLE>
</HEAD>
<BODY>
<APPLET CODE = "myApplet.class" WIDTH = "200"
HEIGHT = "400" ARCHIVE = "myApplet.zip">
</APPLET>
</BODY>
</HTML>
Compressing Archives with Microsoft's CAB Format
- Nipping at the heels of Netscape, Microsoft
soon introduced the CAB format to even the score, and as usual, make
things even more complex for the developer. CAB files followed the
same logic as Netscape's ZIP archive format. The developer could
archive their entire applet into one file and use the CABBASE
parameter to direct Internet Explorer browsers where they could pick
up the code (this is discussed in Chapter Two). The HTML looked
something like this:
<HTML>
<HEAD>
<TITLE>My Applet</TITLE>
</HEAD>
<BODY>
<APPLET CODE = "myApplet.class" WIDTH = "200"
HEIGHT = "400">
<PARAM NAME = "cabbase" VALUE = "myApplet.cab">
</APPLET>
</BODY>
</HTML>
- However, CAB files had one extra goody.
Internet Explorer supported compressed CAB files. This made
transferring large Java applets much more efficient because large
files could be compressed into much smaller ones.
- But, as we mentioned, this only added
another level of complexity to the chores necessary for developers
wishing to distribute their applications. Specifically, a developer
now needed to have all the raw files available for non-big-two
browsers such as Hot Java, a ZIP file for Netscape Navigator users,
and a CAB file for Microsoft Internet Explorer users.
Signing Compressed Archives with Netscape's
JAR Format
- Not to be outdone, and already deeply
ensconced in the battle over web supremacy, Netscape and Sun joined
together to develop the JAR (Java ARchive) format. Distributed as
part of the JDK 1.1, JAR is a platform independent file format
(based on the ZIP file format) that allows a developer to bundle and
compress a Java applet and its requisite components (class files,
images and sounds) into a single file.
- Further, the JAR Format allowed applet
authors to digitally sign individual entries in a JAR file to
authenticate their origin. You create and manipulate JAR files using
the jar utility program that has command line arguments similar to
those of the popular UNIX tar program and then reference the archive
using HTML such as the following:
<HTML>
<HEAD>
<TITLE>My Applet</TITLE>
</HEAD>
<BODY>
<APPLET CODE = "myApplet.class" WIDTH = "200"
HEIGHT = "400" ARCHIVE = "myApplet.jar">
</APPLET>
</BODY>
</HTML>
Previous Page |
Next Page
|
