|
|
Support for Extensions and Applications
|
An extension or application is packaged in one or more JAR (Java Archive) files.
The extension namespace is open, but it is recommended that companies follow the standard package naming conventions when implementing extensions. These conventions are outlined in The Java Language Specification, but the requirement that the domain prefix be specified in all upper case has been removed. For example, the package name com.sun.server is an accepted alternative to COM.sun.server. Unique package naming is recommended in order to avoid conflicts, since an application and the downloaded extensions may share the same class loader.
An implementation of an extension may consist of code written in the Java programming language and, less commonly, platform-specific native code. In addition, it may consist of various resources, such as properties, localization catalogs, images, serialized data, etc specific to the extension.
When packaging extensions, the JAR file manifest can be used to identify vendor and version information (see The Java Versioning Specification).
Support for extensions in browsers such as Internet Explorer and Netscape Navigator is available through the Java Plug-In
Currently, an extension that contains native code cannot be downloaded by network code, whether such code is trusted or not, into the virtual machine at execution time. An extension that contains native code and is bundled with a network application must be installed in the JRE or JDKTM software. This restriction may be removed in a future release.
Installation of extensions must be user-driven. We leave open the issue of cacheing and automatic upgrades. Other VM implementors may wish to layer such functionality on the infrastructure proposed here.
This architecture, since it allows applications, applets and servlets to extend their own class path, also permits packaging and deploying these as multiple JAR files.
An extension or application may refer to additional JAR files which will be referenced from the primary JAR, and these can optionally contain their own dependency information as well.
A installed extension may additionally contain one or more DLLs (shared libraries) and EXEs (commands).
Classes for bundled extensions are private to the class loader of the application, applet or servlet. In the case of network applications such as applets, these extensions will be automatically downloaded as needed. Since class loaders are currently associated with a codebase, this permits multiple applets originating from the same codebase to share implementations (JARs).
An application (or, more generally, JAR file) specifies the relative URLs of the extensions (and libraries) that it needs via the manifest attribute Class-Path. This attribute lists the URLs to search for implementations of extensions (or other libraries) if they cannot be found as extensions installed on the host Java virtual machine. These relative URLs may include JAR files and directories for any libraries or resources needed by the application or extension. Relative URLs not ending with '/' are assumed to refer to JAR files. For example,
Class-Path: servlet.jar infobus.jar acme/beans.jar images/
Multiple Class-Path headers may be specified, and are combined sequentially.
Currently, the URLs must be relative to the code base of the JAR file for security reasons. Thus, remote extensions will originate from the same code base as the application. A future enhancement will leverage the facilities of the Java 1.2 Security APIs to allow references to JAR files at other URLs.
Each relative URL is resolved against the code base that the containing application or extension was loaded from. If the resulting URL is invalid or refers to a resource that cannot be found then it is ignored.
The resulting URLs are used to extend the class path for the application, applet, or servlet by inserting the URLs in the class path immediately following the URL of the containing JAR file. Any duplicate URLs are omitted. For example, given the following class path:
a.jar b.jarIf extension b.jar contained the following Class-Path manifest attribute:
Class-Path: x.jar a.jarThen the resulting application class path would be the following:
a.jar x.jar b.jarOf course, if x.jar had dependencies of its own then these would be added according to the same rules and so on for each subsequent URL. In the actual implementation, JAR file dependencies are processed lazily so that the JAR files are not actually opened until needed.
Its native code libraries, if any, are placed in<java-home>\lib\ext [Win32] <java-home>/lib/ext [Solaris]
Here <java-home> refers to the directory where the JRE or JDK software was installed, and <arch> refers to the Solaris processor architecture (sparc or x86).<java-home>\bin [Win32] <java-home>/lib/<arch> [Solaris]
By default, installed extensions in this standard directory are trusted. That is, they are granted the same privileges as if they were core platform classes (those in rt.jar). This default privilege is specified in the system policy file, but can be overridden for a particular extension by adding the appropriate policy file entry.
Note also that if a installed extension JAR is signed by a trusted entity, then it will be granted the privileges associated with the trusted signer.
Other locations for installed extensions can be specified through the system property java.ext.dirs. This property specifies one or more directories to search for installed extensions, each separated by File.pathSeparatorChar. The default setting for this property is the standard directory for installed extensions indicated above.
A package sealed within a JAR specifies that all classes defined in that package must originate from the same JAR. Otherwise, a SecurityException is thrown.
A sealed JAR specifies that all packages defined by that JAR are sealed unless overridden specifically for a package.
A sealed package is specified via the new manifest attribute, Sealed, whose value is true or false (case irrelevant). For example,
specifies that the javax.servlet.internal package is sealed, and that all classes in that package must be loaded from the same JAR file.Name: javax/servlet/internal/ Sealed: true
If this attribute is missing, the package sealing attribute is that of the containing JAR file.
A sealed JAR is specified via the same new manifest header, Sealed, with the value again of either true or false. For example,
specifies that all packages in this archive are sealed unless explicitly overridden for a particular package with the Sealed attribute in a manifest entry.Sealed: true
If this attribute is missing, the module is assumed to not be sealed, for backwards compatibility. The system then defaults to examining package headers for sealing information.
Package sealing is also important for security, because it restricts access to package-protected members to only those classes defined in the package that originated from the same JAR file. For example, in the runtime JAR rt.jar all of the standard core Java packages with the exception of packages sun.io and java.text.resources are sealed.
Package sealing is checked for installed as well as downloaded extensions, and will result in a SecurityException if violated. Also, the null package is not sealable, so classes that are to be sealed must be placed in their own packages.
The default policy is for a installed extension to behave the same way it would if were part of the core platform. This follows from the common need for a installed extension to load native code.<java-home>/lib/security/java.policy
The Java 1.2 Security Model provides some safety when installed extension code is called from untrusted code. However extension code must be carefully reviewed for potential security breaches wherever it uses privileged blocks.
A remotely loaded 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.
Consult The Java 1.2 Security Specification for further details regarding how to write extension and application code to use the new security features.
This class has been updated to support the new class loader delegation model for loading classes and resources. The class loader delegation model allows a "parent" class loader to be specified which will always be searched first when loading a class or resource before attempting to load it locally. New class loader implementations override the methods findClass and findResource in order to specify how classes and resources are loaded locally.
The following methods have been changed or added to support the new delegation model:
The new delegation model provides a consistent and well defined search policy for loading classes and resources that simplifies class loader implementation. These changes are backward compatible and will not affect existing class loader implementations. However, applications that wish to create their own class loaders and use extensions must use the new delegation model.
The following example demonstrates a simple network class loader:
public class NetClassLoader extends ClassLoader {
URL url;
public NetClassLoader(URL url, ClassLoader parent) {
super(parent);
this.url = url;
}
protected Class findClass(String name)
throws ClassNotFoundException
{
.. load class from URL ...
}
protected URL findResource(String name) {
URL u = new URL(url, name);
if (u.openConnection() != null) {
return u;
} else {
return null;
}
}
}
This example will search the parent class loader (or bootstrap class loader,
if no parent was specified) for classes and resources before checking the
given URL. Classes and resources will be loaded according to the new
delegation model as described above.
This class has been changed to include two new methods for accessing information about sealed packages. The method isSealed can be used to check if a package has been sealed, in which case it will return true. A second form of this method takes a URL and will return true if the package is sealed with respect to the specified URL. This can be used to in class loader implementations to keep track of currently sealed packages when loading new classes.
This class provides the basic class loader support for extensions and applications. It overrides both the findClass and findResource methods to search one or more base URLs for classes and resources. The search is lazy, such that a URL is not opened until needed.
URLClassLoader manages a search path of URLs that is used to load classes and resources. Initially, this is set to the URLs specified when the class loader was created, but can be extended by Class-Path manifest attribute as described above.
URLClassLoader supports all of the manifest attributes for versioning specified in The Java Versioning Specification.
In addition, the following main manifest attributes are supported:
A consequence of this change is that the property java.class.path no longer includes entries from the bootstrap class path. The system class path can now be obtained separately from the system property sun.boot.class.path.
The CLASSPATH environment variable specifies the default value of the property java.class.path. If this environment variable is not set, then the default value for java.class.path is set to the current directory.
The option -classpath is now shorthand for setting the java.class.path property. Formerly, this option was used to override the search path for system classes. In the new java command there is no longer any need to set the system class path.
For example, the following command usages are all equivalent:
java -classpath foo.jar:bar Foo java -Djava.class.path=foo.jar:bar Foo java -cp foo.jar:bar Foo
To install a security manager when invoking an application, use the -Djava.security.manager command-line option:
java -Djava.security.manager Foo
The default system policy file resides at {java.home}/lib/security/java.policy. Individual users may augment this with policy files located at {user.home}/.java.policy. To specify a policy file to be used in addition to these default policies, use:
java -Djava.security.policy=somePolicy Foo
See the JDK 1.2 documentation for more information on policy files.
When using the -jar option the java.class.path property is set to the JAR file being executed and overrides any other definition specified via the -classpath or -cp options. The JAR file's manifest is then consulted to find the name of the application's main class specified via the Main-Class manifest attribute. For example, if the manifest for server.jar contained the following attribute:
Main-Class: com.sun.server.Mainthen server.jar could be executed using either of the following:
java -jar server.jar java -Djava.class.path=server.jar com.sun.server.Main
On Win32 systems the installation program will register a default association for JAR files so that double-clicking a JAR file on the desktop will automatically run it with java -jar. Dependent extensions bundled with the application will also be loaded automatically. Such a feature will make the end-user JRE easier to use on Win32 systems.
The Solaris 2.6 kernel has already been extended to recognize the special "magic" number that identifies a JAR file, and to invoke java -jar on such a JAR file as if it were a native Solaris executable. A application packaged in a JAR file can thus be executed directly from the command line or by clicking an icon on the CDE desktop.
For compatibility we still provide the old-style launcher behavior in the command oldjava which can be used to run applications from the system class path as in version 1.1 of the Java platform. However, extensions are not supported with the oldjava command.
|
Copyright © 1997, 1998
Sun Microsystems, Inc.
All Rights Reserved.
Please send comments to: Java Software |
|