JavaTM Extensions FAQ


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:

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:

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:

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

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.

Copyright © 1995-97 Sun Microsystems, Inc. All Rights Reserved.

Java Software