[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jdt-core-dev] extension directories
|
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.