Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

The combination of a public key, identifying information, and a certification authority’s signature is called a certificate. The current generation of the standard for certificates is X.509v3. For more information about certificates and public-key encryption, see the section, “Signing Your JARs,” later in this chapter.

Version 1.2 of the JDK includes new APIs for parsing certificates and maintaining local databases of X.509v3 certificates.

New Security Tools

Version 1.2 of the JDK also includes tools to help you manage X.509v3 certificates. Within your company, for example, you may decide to issue certificates to any employee. The Java keytool, new in version 1.2, enables each user to generate a public/private keypair. The user can also use keytool to generate his or her own certificate (although the certificate is to a slightly older standard—X.509v1).

	ON THE WEB
	http://home.netscape.com/comprod/server_central/product/certificate/index.html If you plan to issue your own certificates, you’ll need a Certificate Server. Visit the Netscape site and learn about Netscape’s Certificate Server, part of the SuiteSpot family of servers.

You use jarsigner in combination with your certificate to digitally sign Java archives (JARs).

	If you’ve been using javakey from JDK 1.1 or earlier, replace it with keytool and jarsigner. The older tool, javakey, is now obsolete.

You can write an external security configuration file that specifies your machine’s security policy. The easiest way to write such a file is to use Sun’s policytool, also new in JDK 1.2.

Making a JAR

In the earliest versions of Java, it was common to write simple applets that had only a single class file. More sophisticated applets may have dozens of class files as well as supporting files such as images and sounds. It became common to use the popular DOS archive format, .zip, to bundle class files together. The Java Virtual Machine can read the .zip format, so it’s not necessary to unzip these files.

Unfortunately, many users automatically unzip any arriving .zip file, breaking the applet. In JDK 1.2 Sun provides tools for working with the Java archive format, JAR. A JAR file is still a .zip file, but includes a special manifest file to identify its contents. By using a suffix that is more clearly Java related, Sun has decreased the likelihood that end users will open the archive.

You can place all the files associated with an applet into a JAR file and write

<APPLET CODE=“TMyApplet.class”
  ARCHIVE=“;MyArchive.jar, AnotherArchive.jar”
  WIDTH=“200” HEIGHT=“200”>
</APPLET>

This bit of code tells the browser to download the two JARs named. The browser can expect that the components of TMyApplet will all be found in those two JARs. Furthermore, if the browser already has a current copy of one or both of those JAR files in its cache, it may be able to skip the download and display the applet right away. Figure 41.5 illustrates how the class files for TMyApplet are distributed across the two JAR files.

---

NOTE:  If your applet uses files that aren’t in the JAR file, the Web browser will go back to the Web server and look in the current CODEBASE directory for the missing files.

---

FIGURE 41.5  You can store the files of an applet in one or more JAR files.

As an applet developer, you get six benefits from JARs:

•  Improved download efficiency—You need only one HTTP transfer per JAR instead of one per class file.

•  Improved file storage—A JAR stores the class files in one compressed file instead of leaving them “loose” in the directory.

•  Improved security—You can sign JAR files digitally, giving the end user a guarantee that the file has not been tampered with since you signed it. If the end user trusts you, he or she may be willing to give your signed applet access to the hard drive or other sensitive resources.

•  Platform independence—JAR files are based on PKZIP, a popular DOS compression utility, but they can be built and stored on any computer platform.

•  Backwards compatibility—A JAR file doesn’t care what kind of files you put into it. You could take a JDK 1.0 applet and store its class files in a JAR file. As long as the user’s browser understands how to read JAR files, he or she will be able to download and run the applet.

•  Extensibility—Sun acknowledges that Internet technology in general—and Java technology in particular—is still in a state of flux. They’ve provided some hooks in the JAR specification for future growth, so that future developers can extend it as demands change.

Although you can use PKZIP-based tools to make and change JARs, Sun provides a tool specifically designed for the task. This utility is called jar—versions for all supported platforms are offered.

Suppose you have the directory structure shown in Figure 41.6: several .class files plus an images directory. You could use the jar utility to put all these into a new JAR file. We’ll name it MyApplet.jar.

The general format for the jar command line is

jar options filenames

FIGURE 41.6  This directory contains a typical set of files for an applet or application.

---

NOTE:  The name for Sun’s Java archive format is not accidental. Sun’s jar utility is consciously modeled on a UNIX utility called “tar” (for tape archiver). The tar utility is used by UNIX users for building a variety of archives (not just those on tape) in much the same way as PKZIP and WinZip are used by MS-DOS and Windows users.

---