Package Management Previous
Previous
Welcome
Welcome
Next
Next

Note: Internet Explorer Version 4.0 or higher is required for these samples to work correctly.

Introduction

The new Java Package Manager (JPM) picks up where the CAB system leaves off. The JPM is a part of the Java Virtual Machine whose primary function is to find classes when they are requested. When a class is requested, the JPM determines what package the class is in, and then refers to an internal database to determine where the package is stored.

The primary advantages of JPM are:

  • 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.
  • Attribute Storage. Different attributes of a package can be stored.
  • 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 programs can now install packages without having to alter the CLASSPATH and require a reboot.
  • Compatibility. The JPM will accept ZIP, CAB, and JAR formats for installation.
  • Cross-Platform Flexibility. Applications control the JPM through COM, DLL, and Java interfaces.
  • Scalability. JPM can quickly search a large number of libraries, unlike the CLASSPATH which fast becomes unwieldy and makes class-searching bugs hard to uncover.
Versioning

JPM will ensure that only updated versions of packages are installed. Version numbers will be stored in the codestore database. Individual classes are not tracked, but are assumed to have the same version number as their package. Differential updates are handled by the Code Download facility. Each package in JPM can have only one version stored.

Application Namespaces

Java classes installed on the ClassPath can be used by any Java applet or application. In many cases, a toolkit will be installed for only a few applets or applications used by a particular vendor, but becauses of current ClassPath limitations be available to all. This means that the ClassPath gets very cluttered very quickly with toolkits and libraries that are only used for a few applications.

The Java Package Manager allows packages to be installed in an application namespace. These packages are visible only to applications and applets running in the namespace. Packages which need to be visible to all applications (such as the system classes and AFC) 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 fear 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 Package Manager.

Security

Security is handled on a package-by-package basis. Each package is in a separate cabinet, and each cabinet is digitally signed with a certificate. The certificate indicates what privileges the package requests from the VM, and is stored in the package manager. This way, Java packages can be supplied and placed on the local disk without receiving the carte blanche trust of packages in the classpath.



Top © 1996-1997 Microsoft Corporation. All rights reserved.