Extensions are packages of classes written in the Java programming
language (and any associated native
code) that application developers can use to extend the functionality
of the core part of the Java platform. The extension mechanism allows
the Java virtual machine (VM) to use the extension classes in much the
same way as the virtual machine uses the system classes. The extension
mechanism also provides a way for
needed extensions to be retrieved from specified URLs when they are not
already installed in the JDKTM software.
A standard extension is an extension designated as such by
Sun that implements an
open, published, uniform, conformance-tested (hence "standard")
Java API that is not part of the core API.
Three things are required for an API to be eligible to become a
standard extension:
A complete specification that describes the API.
A Java Compatibility Kit to enable the testing and verification
of implementations.
A reference implementation (can be platform-specific).
Why is there a need for standard extensions?
The size of the core part of the Java platform has been growing steadily
since the
release of version 1.0. The first Java platform had 8 core
packages, in version 1.1 there were 22 packages, and in version 1.2 there
are over 50! The extensions framework provides a standard means to add
functionality to the Java platform for use when needed, without
having to increase the size of the core API.
How are extensions packaged?
Extensions are packaged in one or more Java Archive
()
files. An extension may consist of more than one JAR file. In
that case, one JAR file will be the primary JAR file that specifies the
extension name and references other JAR files comprising the extension.
A JAR file can serve as an extension in two ways:
by being placed in the lib/ext directory of the Java
Runtime Environment (which corresponds to the location jre/lib/ext
in the JDK software), in which case it is an installed extension.
by being referenced in the Class-Path header in the manifest of the
JAR file of an applet or application, in which case it is a
download extension.
What's the difference between installed extensions and download
extensions?
An extension is an installed extension when its primary JAR file
is located in the JDK or JRE directory structure at:
<java-home>/lib/ext [All, Trusted]
where <java-home> is the top-level directory of
the Java Runtime Environment (or the jre directory in the
JDK software). Its native code binaries, if any, are placed in
where <arch> refers to the Solaris processor
architecture (sparc or i386).
A download extension is a JAR file referenced from the Class-Path
header in the manifest of an applet, application, or other extension. A Class-Path header might look
like this, for example:
With this header field, the classes in the files servlet.jar,
infobus.jar, and acme/beans.jar will serve as
extensions for purposes of the applet or application. The URLs in the
Class-Path field are given relative to the URL of the JAR file of the
applet or application.
Some differences between installed and download extensions are:
The classes in an installed extension are shared by all code in
the same virtual machine. Classes for downloaded extensions are
private to the session of the application or applet that uses the
download extension.
An extension is an installed extension because of the location
of its JAR file in <java-home>/lib/ext (where
<java-home> is the top level of the Java Runtime
Environment or the jre directory within the JDK software). The location
of the JAR files that serve as download extensions is irrelevent. A
download extension is an extension because it is referenced from the
Class-Path header in another JAR file's manifest.
Only applets and applications bundled in a JAR file can make use of
download extensions. Applets and applications not bundled in a JAR file
don't have a manifest from which to reference download extensions.
How are the classes in an extension invoked?
When the VM is searching for a class of a particular name, it will first
look among the classes in the core API. If it fails to find the desired class
there, it will next look for the class among any installed extensions. If it
doesn't find the class among either the system classes or the installed
extensions, the VM will search among any download extensions referenced
by the application or applet. There is no need to include the extension's
JAR file(s) in the class path.
Will the standard extensions made available by Sun be free?
Sun contemplates both free standard extensions and "premium extensions"
for which there will be a charge. Whether Sun releases source
(either freely or at cost) with the
binary release of an extension will be a case-by-case business decision.
Specifications for standard extensions will be free.
Can standard extensions have platform-specific native code?
An implementation of an installed standard extension may contain native
code. In addition, an implementation may use
other resources such as properties, localization catalogs, images, and
serialized data.
If implementations are platform-specific, installer programs can ask
for which platform the extension is desired before installing the
extension in the JDK or JRE directory structure.
Can a standard extension rely on other extensions?
A standard extension can rely on the public APIs of other
standard extensions.
How will standard extensions be named?
Standard extensions will have names in the javax.* namespace. Exceptions
will be allowed on a case-by-case basis, as for example, when necessary
because of open standards. However, just because a package name begins
with javax does not guarantee that that package is an extension
rather than a part of the core platform. The Swing packages have names
beginning with javax indicating that they were non-core
extensions prior to version 1.2 of the platform. They are part of the
core 1.2 platform even though they are in the javax.* namespace.
Will the release of standard extensions be coupled to the release
of the Java Development Kit?
No. Releases of standard extensions will not necessarily be coupled to the
releases of the Java Development Kit. When released, a standard extension must
be compatible with the current Java platform, and subsequent versions of the
platform must be compatible with existing standard extensions.
Are Java licensees required to adopt standard extensions?
No. Licensees are required to adopt only packages in the core platform.
They are not required to adopt standard extensions.
Are standard extensions going to be as widely available
across platforms as are core packages?
It depends. It is Sun's goal to make them widely available. Some will
be packaged for free with the Java Development Kit. Some will be
downloadable for free.
Some will be licensed for a fee. We hope that Java platform vendors
will choose to include many standard extensions with their products.
How do standard extensions relate to 100% Pure Java?
Platform-independent standard extensions released by Sun will normally
be certified as 100% Pure Java.
Can my application use standard extensions and still be considered compliant
with the 100% Pure Java logo program?
Only if the standard extensions that you use are 100% Pure. You must
submit both your application and any extensions that your application
uses for 100% Pure
certification. The combination of your application and all standard
extensions it uses is what will be tested. 100% Pure standard extensions
will signifcantly ease the testing burden, but even some standard
extensions that are not certified 100% Pure may meet the requirements
when combined with your application, depending on how your application
uses the standard extension.
What are some examples of standard extensions?
Are extensions versioned?
The extension mechanism of the 1.2 Java platform provides no versioning
feature of its own. Packages
in extensions, like all packages, can make use of the
Package Version Identification feature of JDK 1.2.
What about security?
An extension is treated as optionally installed system code and
must respect the restrictions of any installed Security Manager. An
extension will not introduce new security-related
behavior that would require changes to the SecurityManager interface.
A network-loaded extension must be trusted (either signed by a
trusted entity or loaded from a trusted source) if it requires
access to controlled system services.
The code source for a installed extension has a pre-configured security
policy associated with it. The exact level of trust granted to installed
extensions is specified by the standard Java policy configuration
file
<java-home>/lib/security/java.policy
Here, <java-home> is the top-level directory of the
Java Runtime Environment or the jre directory in the JDK
software.
The default policy is for a installed extension to behave
as it would if placed in the system class path. This follows from the
need for a installed extension to load native code.
The Java 1.2 Security Model provides some safety when installed
extension code is called from untrusted code. However, like system
code, extension code must be carefully reviewed for
potential security breaches where it uses privileged blocks.
A remote extension that needs to use access-checked system
services (such as file I/O) to function correctly must either be
signed by a trusted entity or loaded from a trusted source.
