Java Extensions FAQ - JDK 5 Documentation v1.2.2, Java 2 SDK 英文文档

Java^TM Extensions FAQ

What is a standard extension?
Why is there a need for standard extensions?
How are extensions packaged?
What is the difference between installed extensions and download extensions?
How are the classes in an extension invoked?
Will the standard extensions made available by Sun be free?
Can standard extensions have platform-specific native code?
Can a standard extension rely on other extensions?
How will standard extensions be named?
Will the release of standard extensions be coupled to the release of the Java Development Kit?
Are Java licensees required to adopt the javax packages?
Are javax packages going to be as widely available across platforms as java packages?
How do standard extensions relate to 100% Pure Java?
Can I use standard extensions and still be considered compliant with the 100% Pure Java logo programs?
What are examples of extensions that Sun plans for the future?
Are extensions versioned?
What about security?

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 JDK^TM 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 (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 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

<java-home>\bin              [Win32]
<java-home>/lib/<arch>       [Solaris]

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:

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 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.

Java Software