Extension Mechanism in Java. What, How, etc.

Extensions in Java

Extension are nothing but a set of packages or classes or related resources all bundled into a Java Archive (JAR) file and stored at (or referenced from) a specified location. You can have two types of extensions in Java based on whether you store the JAR at a specified location OR reference the JAR from a specified location. These are:

• Installed Extension: If you store the JAR file in a particular directory (inside the current Java Runtime Environment), which is especially meant to store Java extensions then such extensions are named installed extensions.
• Download Extenssion: If you specify the JAR file from the manifest file of another JAR file (accessible to the application) then in this case the extensions are named download extensions.

Installed Extensions

The special directory used to keep the installed extensions is jdk<version>/jre/lib/ext. These installed extensions become part of the Core API of the underlying Java platform, so they will be visible and hence available in all the processes running in the current Java Runtime Environment, so do take care of the directory structure of the classes in the JAR file before bundling them. It should be similar to what we have for the other standard APIs in Java.

Java 6 goes one step further and allows you to store the installed extensions at an independent location and all the JREs installed on a particular system can share the same extensions. Prior to Java 6, the extensions were looked only in ../jre/lib/ext directory, but from Java 6 they will be looked in a series of directories staring with this directory. So, the first directory of that series will always be .../jre/lib/ext and maybe you can have the independent location as the second entry. Currently this independent location is independent only to the JREs installed on a system, but fixed for a particular Operating System. Like, this directory should be SystemRoot\Sun\Java\lib\ext for MS Windows OS, /usr/jdk/packages/lib/ext for Solaris OS, and /usr/java/packages/lib/ext for Linux OS.

Download Extensions

In this case the extension JAR files are referenced from the manifest file of any other JAR of the current JRE. The JAR file referring to the download extension need to be itself an extension. It can be a normal JAR file somehow reachable to the application (i.e., the directory having this JAR file should be there somewhere in the CLASSPATH). There are two ways of referring to an external JAR file in a manifest file: One, by using a Class-Path header and Two, by using an Extension-List header. A maximum of one of each of the headers is allowed in a manifest file. But, one header can refer any number of extension JARs.

The difference between the two ways is that the download extensions referred by a Class-Path header are downloaded only for the lifetime of the application which downloads them. For example, a Web Browser running an Applet may require certain functionalities to be shipped via download extensions for the smooth execution of the Applet in the browser window. The advantage of using this approach is that you don't need to install anything on the clinet machine. The clinet machine should be capable of running a Web Browser. That's it. The disadvantage is also quite clear - you download it every time you need. Download extentions referred by an Extension-List header cause the extensions to be downloaded the first time they are needed and they are directly installed in the .../jre/lib/ext directory of the underlying JRE that time only. So, they become similar to an installed extension afterwards. This is the advantage that you need to download them only once, but the disadvantage is that the deployment of Extension-List header based download extentions is complex as compared to Class-Path header based download extensions.