Java Package Management and Code Download

The Java language supports the concept of Java packages to manage the namespace of classes, but does not provide for installing or managing packages. The Microsoft virtual machine (Microsoft VM) provides package management services with the Java Language Package Manager (JPM). Microsoft® Internet Explorer 4.0 uses the JPM to provide code download services for Java applets. This article provides an introduction to the Java Language Package Manager and Internet Explorer 4.0 code download services.

A Brief History of Package Management

A Java package is a collection of classes that share a common namespace. For example, if a class named "test.java" contains the line "package com.ms.fx", the full name of the compiled class will be "com.ms.fx.test". Packages are the building blocks of Java applications—the Java core libraries are a set of packages: java.lang, java.io, and so on.

Early adopters of Java realized that packages would be easier to work with if they could be encapsulated in a single file. The Java community chose to use the public-domain PKZIP archiving standard to encapsulate Java packages. The PKZIP archive format remains the de facto standard for delivering Java packages. Two other packaging standards have since arisen to address the packaging requirements of Java applications: the Sun Microsystems Java Archive (JAR) standard and the Microsoft Cabinet File (CAB) standard.

The Java Archive Standard

The Sun JAR standard appeared in Java Development Kit (JDK) version 1.1. JAR files continue to use the PKZIP archiving standard, but add a manifest component to the Java class files in the archive. The manifest file provides a way to individually digitally sign each class file. Signature files are added in a META-INF directory inside the JAR file.

Compression in JAR files is done on a file-by-file basis. This method of compression can be inefficient because Java class files are often too small to benefit from individual compression.

The Cabinet File Standard

The CAB standard was initially used to package Windows 95 and other products. Cabinet files have since become Microsoft's standard archive format. CAB compression first concatenates all files into a large block and compresses the block, a method similar to the TAR/GZIP archiving standard used on UNIX platforms. This method of compression significantly increases the compression of Java packages.

The Internet Explorer 3.0 Code Download Mechanism

Internet Explorer 3.0 includes a code download feature to allow web distribution of software using cabinet files. To use the code download feature, you first create an inner cabinet with all the files needed for the application. Next, you write a master .inf file to describe how to install the files in the cabinet file. Finally, you place both the .inf file and the inner cabinet file into an outer cabinet file, which you can then use for download.

The OBJECT tag in an HTML file specifies a cabinet file for download. When Internet Explorer sees the OBJECT tag, it checks to see if a current version of the cabinet file is present on the user's system. If not, Internet Explorer downloads the cabinet file and installs it according to the instructions in the enclosed .inf file.

CAB files should be digitally signed before being made available for download. The cabinet standard does not support individually signing each class file—the signature on the cabinet file is assumed to apply to all the files in the archive.

Note Code download is not limited to using the cabinet format. Other archive formats can be used as long as there is some method for digitally signing the archive.

The Internet Explorer 4.0 Solution—Distribution Units

Code download in Internet Explorer 3.0 relies on registry entries to determine if a particular archive (CAB) is installed and, if it is, what version is installed. Version information is maintained at the cabinet-file level—it does not extend to individual packages. The Internet Explorer 3.0 code download mechanism does not provide for uninstalling packages or for providing version information to the virtual machine.

Internet Explorer 4.0 addresses these limitations with a more advanced transport for code download: the Distribution Unit (DU). DUs have version numbers that are checked by browser's code download feature to see if the DU should be downloaded. Each DU contains a list of all of the packages and applications inside the DU. This list, called an Open Software Distribution manifest (OSD), also contains version and security information.

A powerful feature of OSDs is that they can be nested inside other OSDs. This allows a single DU to act as a front-end for a multicomponent application. DUs can also be delivered with push technology. A push channel can check to see if the client has the latest version of content and update the client, if necessary. The issues are largely the same from a package management viewpoint, but from the user's point of view, push is superior to standard browsing because the user does not have to actively check for updates.

The Microsoft SDK for Java includes a utility, dubuild, to create Distribution Units. See Using DUBuild for details on using dubuild to create Distribution Units.

The Java Language Package Manager

The Microsoft VM (the version included with Internet Explorer 4.0 and with the Microsoft SDK for Java version 3.0 pre-release 2) includes the JPM to handle package installation and management. The JPM's primary function is to find classes when they are needed by the Microsoft VM. When a class is needed, the JPM determines what package the class is in, and then refers to an internal database to determine where the package is stored. The following is a list of the features of the JPM.

• Version Control. Package version numbers are tracked, allowing Java programs and installers to intelligently update the system.
• Application Namespaces. Java applications are installed in private namespaces, shielding their classes from name collisions and use by other applications.
• Improved Security. Instead of having to fully trust all installed classes, the package manager stores the allowed capabilities of each package, as verified by Authenticode.
• Ease Of Use. Java applications can install packages without having to alter the CLASSPATH environment variable and without requiring a restart.
• Compatibility. The JPM will install ZIP and JAR archives, as well as cabinet file archives.

Package Installation

Java classes installed on the class path can be used by any Java applet or application. In many cases, a small group of utility classes will be installed for only a few applications of a particular vendor, but because of current class path limitations, will be visible to all applications. This means that the class path gets cluttered quickly with toolkits and libraries that are only used for a few applications.

The JPM allows packages to be installed in an application namespace. These packages are visible only to applications and applets running in the namespace. Packages that need to be visible to all applications (such as the system classes and Application Foundation Classes) are installed in the global namespace. Only packages signed by the namespace's principal are allowed to be installed in the namespace. Applications that have classes in the anonymous package can run without the possibility of name collisions with other installed applications. Without this protection, Java applications cannot be installed. Application namespaces give vendors what is necessary to install Java applets and applications in the Java Language Package Manager.

Security

Security is handled on a package-by-package basis. Each package is in a separate archive, and each archive is digitally signed with a certificate. The certificate indicates which privileges the package requests from the VM and is stored in the JPM. This way, Java packages can be supplied and placed on the local disk without receiving the carte blanche trust of packages in the class path. See Security for more information on Microsoft's security model for Java applications.

FAQ

• Q1. What is the Java Language Package Manager?
• Q2. How do I use non-JPM-aware Java development tools?
• Q3. What is an application namespace and how do I use it?
• Q4. Can I extract individual packages from the Package Manager?
• Q5. How can I list currently installed packages?
• Q6. What is the order of a class search?
• Q7. What is a Distribution Unit?
• Q8. How do I make a Distribution Unit for my Java classes?
• Q9. How do I provide updates for a Distribution Unit?
• Q10. How do I install a Java applet using Internet Explorer 4.0?
• Q11. How do I install a stand-alone Java application using Internet Explorer 4.0?

Q1. What is the Java Language Package Manager?

The version of the Microsoft VM included with Internet Explorer 4.0 and the Microsoft SDK for Java version 3.0 pre-release 2 includes the JPM to handle package installation and management. The JPM's primary function is to find classes when they are needed by the VM. When a class is needed, the JPM determines what package the class is in, and then refers to an internal database to determine where the package is stored. All the standard Java packages shipped with Internet Explorer 4.0 are installed in the Package Manager.

Q2. How do I use Java development tools with the JPM?

When a Java package is installed in the JPM, the original archive file is removed, and the classes are stored internally. You must use the clspack tool to generate the .zip files used by Java development tools. This tool enables you to take packages that are currently installed through the JPM, and write their contents into a .zip file.

The easiest way to use clspack is to type the following command:

clspack -auto

This will create a single classes.zip in your %WINDIR%\Java\Classes directory that contains all classes stored in the JPM. The Jvc compiler, which ships with the Microsoft SDK for Java, looks for classes in this directory by default, so there is no need to change your CLASSPATH environment variable.

If you're using a compiler that does not check this directory by default, set your CLASSPATH environment variable as shown below.

set CLASSPATH=%WINDIR%\Java\Classes\Classes.zip

Q3. What is an application namespace and how do I use it?

The Microsoft VM supports application namespaces—namespaces that are a layer above the namespace of packages and classes. If you have any anonymous classes (classes not in a package) in your DU, you must specify an application namespace when you create the DU—otherwise, the anonymous classes will not be properly installed.

To run a Java applet or stand-alone application that is installed in an application namespace, you must specify the namespace when you run the applet or application. To specify an application namespace when running an applet, add the following parameter to the <APPLET> tag:

<PARAM NAME=namespace value="namespace">

To specify an application namespace for an application, use the -n switch with the jview utility:

jview -n <namespace> <classname>

Q4. Can I extract individual packages from the JPM?

clspack can also be used to extract individual packages. The usage is:

clspack myzipfile.zip <listfile>

The listfile parameter specifies the name of a text file containing the list of packages to extract to the zip.

Q5. How can I list currently installed packages?

If you specify the -dump switch with clspack, it will list all of the packages currently installed in the package manager to the specified outputfile.

clspack -dump <outputfile>

Q6. What is the order of a class search?

When a class is requested, the VM normally searches for it in the following order:

1. Check explicitly-specified path (typically supplied with the -classpath command-line option).
2. Search JPM-installed classes.
3. Check the HKLM\Software\Microsoft\Java VM\TrustedClasspath registry entry.
4. Check the HKLM\Software\Microsoft\Java VM\TrustedLibsDirectory registry entry.
5. Check the HKLM\Software\Microsoft\Java VM\Classpath registry entry.
6. Check the HKLM\Software\Microsoft\Java VM\LibsDirectory registry entry.
7. Check the CLASSPATH local environment variable.

However, if served from a web page with a trusted applet, the VM additionally searches for the class in the following locations:

1. Check any cabinet files referenced by the 'cabinets' applet parameter (in the order in which they appear in the HTML).
2. Check any cabinet file referenced by the 'cabbase' applet parameter.
3. Check any zip or jar file referenced by the 'archive' tag.
4. Check for any classes relative to the codebase of the HTML.

Untrusted applets will not search the previously mentioned trusted paths.

Q7. What is a Distribution Unit?

A Distribution Unit (DU) is a transport standard for downloadable archives. A DU is a cabinet file that contains an Open Software Distribution manifest (OSD), which contains details on what version the DU is, the versions of the contents of the DU, and how to install the contents of the DU. DUs are handled by the code download feature of Internet Explorer 4.0. You can create DUs that target Internet Explorer 3, but they are essentially wrapped cabinet files (you still need to work with MASTER.INF and procedures for creating cabinet files) with MSZIP compression. If you place your DU on an HTML page with the <OBJECT> tag, Internet Explorer will automatically install it onto client systems. If a DU contains Java packages, Internet Explorer will invoke the JPM to install them.

Q8. How do I make a Distribution Unit for my Java classes?

To make a DU for a set of Java packages, use the dubuild tool. Given a tree of Java classes, it will archive the tree into a cabinet file and create an Open Software Distribution (OSD) file that has an entry for each package in the tree. For example, consider the following directory tree.

C:\tree ------- tools
           |
           +--- image

The following commands will create c:\first.cab with the packages tree.tools and tree.image.

cd \
dubuild first.cab tree /N MyAppNamespace

Q9. How do I provide updates for a Distribution Unit?

It's possible to create delta DUs that consists only of changed packages and have pointers to a secondary DU that contains the other unchanged packages. The following command will create a cabinet named "second.cab" that has only the changed packages in the tree from the time first.cab was created.

dubuild second.cab tree /P first.cab

The OSD in second.cab points to first.cab for all unchanged packages. Note that a package is considered changed if any one of the files inside has been modified since the time first.cab was created.

Q10. How do I install a Java applet using Internet Explorer 4.0?

To install and run an applet, use the <APPLET> instead of the <OBJECT> tag:

<APPLET
  code=com.mycorp.AppletMain
  width=200
  height=200>  
<PARAM NAME=useslibrary VALUE="MyApplet"> 
<PARAM NAME=useslibrarycodebase VALUE="applet.cab"> 
<PARAM NAME=useslibraryversion VALUE="1,1,23,0"> 
</APPLET> 

Q11. How do I install a Java application using Internet Explorer 4.0?

You can install stand-alone applications as well as applets using the Internet Explorer 4.0 code download mechanism. Archiving a stand-alone application in a DU is similar to archiving an applet. You should specify an application namespace when creating the DU for your application to prevent possible namespace collisions.

It's a good idea to put an applet inside the DU to notify the user that the download is complete. Use the code parameter of the <APPLET> tag to point to this applet.