MSVM provides various ways for developers to put their classes and
native libraries in the MSVM search path:

        %SYSTEMROOT%\Java\TrustClasses  for trusted CLASS
        %SYSTEMROOT%\Java\TrustLib      for trusted JAR/CAB
        %SYSTEMROOT%\Java\Classes       for untrusted CLASS
        %SYSTEMROOT%\Java\Lib           for untrusted JAR/CAB
        %SYSTEMROOT%                    for DLL

        See http://support.microsoft.com/default.aspx?scid=kb;EN-US;177168 for
more details.

        The similar solution in Sun VM is through the extension mechanism:

        {java.home}\bin         for DLL
        {java.home}\lib\ext     for JAR/ZIP

        While this mechanism works, developers migrating from MSVM found this
solution unacceptable because the libraries can only be deployed to a
specific JRE; each time a new JRE is installed (either through manual
install, Java Web Start auto download, or Java Update), the libraries
deployed in the existing JRE would not be visible to the new JRE, thus
their apps that rely on these libraries won't work in the new JRE unless
the developers re-deploy their libraries to the new JRE. 

        An alternative is to modify the J2SE installer to copy the user
libraries from the installed JRE to the new JRE, but this approach is
quite problematic especially when there are multiple JREs on the system
and each may contain a slightly different version of the library.

        In order to fully resolve this issue, we need a solution like the
optional package repository. However, due to Tiger schedule and
potential risk involved, a full blown solution would not be feasible in
the Tiger timeframe. As a result, a scale-down version of the optional
package repository is proposed to ease the MSVM migration problem in the
Tiger timeframe, while the engineering team would seek a more complete
solution in Dragonfly.

        This Java library repository would provide functionalities similar to
the repository in MSVM, i.e. to provide a way for the VM to look for
libraries (JAR/native) from a global location. It will be supported by
Java Plug-in on Win32.

        %SYSTEMROOT%                            for DLL
        {deployment.system.home}\Lib\Untrusted  for untrusted JAR
        {deployment.system.home}\Lib\Trusted    for trusted JAR

        On XP, they will look like the following:

        C:\Windows\                     
        C:\Windows\Sun\Java\Deployment\Lib\Untrusted
        C:\Windows\Sun\Java\Deployment\Lib\Trusted

        Notice that the repository would be located under the v1.5 deployment
infrastructure. Classes within untrusted JAR would be given default
applet permission based on applet classloader, while classes within
trusted JAR would be given AllPermission.

        This repository is very primitive, and it doesn't have any version or
namespaces control. It will be up to the deployers to determine how to
avoid version and namespaces conflicts at deployment time. 

        The list of JAR files within the repository will be recognized at VM
startup time. If new JAR files are added to the repository during the VM
execution, they will be recognized in the next VM startup.

###@###.### 2004-02-05
###@###.### 2004-02-05