JDK-6271065 : java.ext.dirs should be expanded
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Affected Version: 5.0,6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2005-05-16
  • Updated: 2017-05-16
  • Resolved: 2005-10-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6 b55Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
The fact that all optional packages are installed on a per-jre
basis has long been a problem on Windows and Linux.  With the
mJRE project, this problem was brought to Solaris.

This request is for a simple method to installation a single instance
of an "optional package" which can be easily used by multiple jdk/jre
instances. The obvious way to accomplish this is by expanding the set
of directories defined by the java.ext.dirs property to include a jre
independent component in addition to the existing jre specific component.

###@###.### 2005-05-16 20:03:54 GMT

EVALUATION As per suggested fix

SUGGESTED FIX 1) The default extensions to the system property java.ext.dirs by the "System-Wide Repository (Windows only)" addition to Tiger should be generalized to all platforms and not just the plug-in. The relevant semantic extension is "a global or system-wide location where the VM can search for libraries, JAR or native, independent of the JRE location". The conceptual extension for Solaris/Linux would be: Solaris: $(JREHOME)/lib:/usr/jdk/packages/lib Linux: $(JREHOME)/lib:/usr/java/packages/lib The names are negotiable, but the Solaris "packages" directory already exists (private) due to the way this is problem is being finessed in Tiger. 2) A STRONG policy needs to be developed to protect the Java namespace from inappropriate intrusions by the "optional packages". See CR 6217360 for a problem caused by JMF not respecting the namespace. The policy will probably be very strongly based on the existing "reverse domain name" and "class hierarchy" conventions. For extensions provided by Sun, the policy will be a rule. Note: Most of this change is policy and documentation. The actual code changes are on the order of a dozen lines of code. ###@###.### 2005-05-16 20:03:55 GMT Note that the implementation of this requires fixing CR 6214495 which was closed as "Will Not Fix". CR 6214495 is a regression introduced in 1.5 such that sun.boot.library.path could only be a single directory, rather than a path of directories.