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 namespaces 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.