|
JavaTM Extensions FAQ
|
Contents
What is a standard extension?
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 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
(JAR)
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 JDK or
JRE, 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 JDK or JRE software. Its native code binaries, if any, are placed in
<java-home>\bin [Win32]
<java-home>/lib/<arch> [Solaris]
where <arch> refers to the Solaris processor
architecture (sparc or x86).
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:
Class-Path: servlet.jar infobus.jar acme/beans.jar
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 an extension is an installed extension because of the location
of its JAR file in
<java-home>/lib/ext. 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.
- Unlike installed extensions, download extensions cannot have any
native code.
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 system classes. 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 CLASSPATH.
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.
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.
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 the javax packages?
No. Licensees are required to adopt only packages in the core platform.
They are not required to adopt standard extensions.
Are javax packages going to be as widely available
across platforms as java 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?
Some standard extensions will be 100% Pure, some will not. There is no
correlation between being a standard extension and being 100% Pure Java.
Can I 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 you use 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 examples of extensions that Sun plans for the future?
All or part of the following features may be packaged
as standard extensions:
Are extensions versioned?
The extension framework 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?
A standard extension is treated as optionally installed system code and
must respect the restrictions of any installed Security Manager. A
standard 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 standard extension (one in
<java-home>/lib/ext) has a pre-configured security
policy associated with it. The exact level of trust granted to JARs
in this directory is specified by the standard Java policy configuration
file
<java-home>/lib/security/java.policy
The default policy is for a installed standard extension to behave
as it would if placed in the system CLASSPATH. 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, standard extension code must be carefully reviewed for
potential security breaches where it uses privileged blocks.
A remote standard 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.
