Bug ID: JDK-6271065 java.ext.dirs should be expanded

Versions (Unresolved/Resolved/Fixed)

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.

JDK 6
6 b55Fixed

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

29-09-2005

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.

16-05-2005

Duplicate :	JDK-4856549 - provided improved support for executable JARs
Relates :	JDK-6349966 - REGRESSION:System property "java.ext.dirs" returns an invalid path name
Relates :	JDK-6214495 - Any attempt to set sun.boot.library.path causes VM to fail
Relates :	JDK-4615364 - java.ext.dirs should be at least two dirs to segregate optional packages
Relates :	JDK-6329385 - Hotspot build failed on Solaris 9 due to undefined LA_SER_MASK
Relates :	JDK-6428896 - javap cannot read multiple entries on the extension classpath