[jdt-core-dev] extension directories

["Jim des Rivieres/OTT/OTI" <Jim_des_Rivieres@xxxxxxx>]

Here is a revised proposal for extension directory support.



Please send comments (via jdt-core-dev@xxxxxxxxxxx,
jdt-ui-dev@xxxxxxxxxxx).

---jeem
(See attached file: ext-dirs.html)

Title: JDT - Extension Directories

Extension Directories

Last revised 11:15 Monday November 12, 2001

Work item: Add support to Java model for JDK 1.2-style extension directories (aka optional packages)

An extension directory is a folder containing any number of JAR files (including 0). Extension directories were originally added in JDK 1.2, and are described in http://java.sun.com/j2se/1.3/docs/guide/extensions/index.html.

There are two facets to extension directories: runtime support, and compile time support.

Compile-time support

Extension folders typically contain a bunch of unrelated JARs, making it
likely that a user will be interested in a particular subset and uninterested
in the rest. The IBM 1.3.0 JRE jre\lib\ext contains indicim.jar and JawBridge.jar.
The Sun JDK 1.4.0-beta jre\lib\ext contains dnsns.jar, ldapsec.jar, and
sunjre_provider.jar. All these JARs are likely pure noise and do not contain
API that a client would write to.  In a J2EE JRE, there would be a
diverse collection of JARs in the jre\lib\ext extension directory (e.g.,
Java Telephony, JavaMail, Java 2D, Java 3D, Java Media Frameworks), only
a handful of which would be used within any given project.

No special compile time support is required beyond making it convenient for a user to add some (or all) of the JARs in an extension directory to a project's build classpath (and attach source, if available). Users may choose to be selective and only include those JARs from the extension directory that are actually needed to compile against. Or they may include all available JARs; it would be their choice. The clutter in the Packages view can be reduced by hiding the JAR library entries (an existing UI option).

Runtime support

Standard JVMs allow extension directories to be specified on the command
line. By default, jre/lib/ext is the extension directory at runtime. Overriding
this default entails specifying a command line argument to set the value
of the java.ext.dirs system property. This system property specifies
one or more directories to search for installed extensions, each separated
by File.pathSeparatorChar.

The ability to explicity specify additional extension directories, and even to override the standard implicit default, needs to be exposed at the UI to the user. Like the boot classpath, the whole notion of extension directories is somewhat JVM specific. The VM launcher should be responsible for gathering and persisting this information.

Clearly, a JAR on the build classpath does not need to be included on the runtime classpath if that JAR is contained in an extension directory on the runtime classpath. Since the launcher is JVM-install-type-specific, it feels like the right place to hardcode the knowledge of how to map a build classpath to a runtime classpath. The JAR for the standard class library does not need to be included in the runtime classpath because it is implicitly on the boot classpath. Similarly, any JAR that is included in an extension directory does not need to be mentioned explicitly.