JDK-4615364 : java.ext.dirs should be at least two dirs to segregate optional packages
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2001-12-18
  • Updated: 2017-09-26
  • Resolved: 2017-09-26
Related Reports
Relates :  
Description
Name: pa48320			Date: 12/18/2001

Optional packages should not install in same directory as JRE standard
extensions.

Prior to 1.4, Javasoft did not ship any standard extensions in
jre/lib/ext. In 1.4, the JRE comes with:

    dnsns.jar 
    jgss_kerberos.jar 
    ldapsec.jar 
    sunjce_provider.jar 

However, Optional Packages installed by applets also install jar files
in this same directory. This makes it impossible for a Java application
to ensure a consistent, clean deployment run time environment. Prior to
1.4, we could run Java applications with

   java -Djava.ext.dirs= com.sas.myapp.Main

and this insulate the application from any jars downloaded by applets
using the Optional Package specification. If we launch 1.4-based
applications using this runtime option, these new jars will not be
available.

Optional Package jars downloaded by applets will also cause a
performance problem for non-applet applications which use the same JRE.
For example, when an application loads a resource such as a class or
resource bundle, the application classloader will first delegate to the
extension class loader (which in turn delegates to tbe boot class
loader). The extension class loader will then try to find that resource
in all the optional package jars.

To fix this, java.ext.dirs should be two separate directories

    jre/lib/standard-ext

         would contain dnsns.jar, jgss_kerberos.jar, ldapsec.jar,
         sunjce_provider.jar, and other jar files Javasoft
         or JVM vendors wish to ship with their JRE.
         
    jre/lib/optional-packages

         would contain jars downloaded by the applet Optional Package
         specification.
         
Further, the extension directory path used by the Java tools (java,
javadoc, javap, javaws, web servers, etc.) would be

    -Djava.ext.dirs=JAVA_HOME/jre/lib/standard-ext

and the java.ext.dirs used by the plug in would be

    -Djava.ext.dirs=JAVA_HOME/jre/lib/standard-ext;JAVA_HOME/jre/lib/optional-packages;

Thus, applications could run in a clean environment, not polluted by
applet Optional Package installed jars.

======================================================================

Comments
The extension mechanism has been removed in JDK 9 [1]. Close as will not fix. [1] http://openjdk.java.net/jeps/220
26-09-2017

WORK AROUND Name: pa48320 Date: 12/18/2001 The only workaround is for applications to copy the Javasoft installed jar files into a separate location and use -Djava.ext.dirs=location but this is a deployment nightmare and is too fragile, since it assumes a fixed set of jar files. ======================================================================
11-06-2004

EVALUATION A very sensible request, but unfortunately we cannot change the layout of the extensions directory, and the mechanism by which extensions are found and loaded, until Tiger. -- ###@###.### 2002/4/22 I want to point out that jgss-kerberos.jar is not placed in jre/lib/ext directory. ###@###.### 2002-05-10 Too late to fix for Tiger. We will investigate the possibility of defining a new layout for the extensions directory in the next feature release. -- iag@sfbay 2003-11-03
10-05-2002