Documentation Contents
Java Platform, Standard Edition Deployment Guide
Contents Previous Next

# 32 Other Deployment Features

This topic provides information on additional deployment features that are supported for rich Internet applications, such as protocols, multiple JRE versions, and special applet attributes.

This topic contains the following sections:

- Protocol Support

- Multi-Version Support

- System-Wide Repository (Windows only)

- Applet Persistence API

- Special Applet Attributes

## 32.1 Protocol Support

Support for the following common protocols is built into the Java Plug-in:

- HTTP and FTP

- HTTPS

- Socks

- NTLM Authentication

### 32.1.1 HTTP and FTP

Java Plug-in supports HTTP and FTP protocols, including built-in proxy configuration support.

### 32.1.2 HTTPS

HTTPS is supported in Java Plug-in through Java Secure Socket Extension (JSSE), which provides a Java implementation of SSL and HTTPS for the Java platform.

#### 32.1.2.1 Error handling support

When accessing an HTTPS server, errors might occur. Java Plug-in has hooked into JSSE to provide the following types of error handling:

- Hostname mismatch: If the HTTPS server host name does not match the name on the server certificate, a warning dialog will appear.

- Untrusted server certificate: If the server certificate can not be verified during the SSL handshaking, a warning dialog will appear.

- Untrusted client certificate: In case client authentication is required by the server and the client certificate cannot be verified, a warning dialog will be appear.

- Server authentication: If the client accesses a protected directory on the HTTPS server, the users will be prompted for a username and password. Note: Only basic authentication is currently supported.

#### 32.1.2.2 Potential issues with HTTPS through JSSE

Although support of HTTPS through JSSE eliminates many browser-specific problems, the following issues could occur:

- Untrusted server certificate: When SSL handshaking takes place in establishing an HTTPS connection, the server certificate is verified against the root CA store in Java SE. However, Java SE supports fewer root CA certificates than does the browser. As a result, you may have problems with untrusted server certificates.

- Client authentication: Java Plug-in supports browser keystore in JRE 1.5 or later. With browser keystore, client authentication of HTTPS server is performed differently for Internet Explorer and Mozilla family browsers. For Internet Explorer the certificate is not imported into the JRE keystore. For Mozilla family browsers, a JSS package should be installed to read the certificate from the Mozilla keystore. By default browser keystore support is turned on.

- Level of error handling: Java Plug-in currently handles the types of error listed in the previous section. However, if the Java Plug-in encounters errors that it does not recognize, Java applet code might break.

### 32.1.3 Socks

Java Plug-in currently supports SOCKS version 4.

Note: For HTTP/HTTPS, a SOCKS proxy server can be used with a web proxy server to add caching. The behavior, however, might differ from that observed when running a similar configuration in a browser without Java Plug-in.

### 32.1.4 NTLM Authentication

Java Plug-in supports NTLM authentication protocol for HTTP/HTTPS. When attempting to access a server requiring NTLM authentication, the user is prompted to enter User Name, Password and the Domain.

## 32.2 Multi-Version Support

The following sections describe the methods used to support multiple versions of the JRE on a single system.

### 32.2.1 Unique MIME Type

Every new and update version of Java Plug-in has a unique MIME type. MIME type identifies the type or version of the Java executable to be loaded and initialized by Java Plug-in. It is specified with the element type in the `embed` tag with Firefox and with `<param name="type">` in the `object` tag for Internet Explorer. If you want to use a minimum version of Java Plug-in with Firefox, specify the unique MIME type in the `embed` tag.

The MIME type corresponding to the version of Java Plug-in installed in your computer looks like the following:

    application/x-java-applet;jpi-version=<version>

where version includes the major, minor and patch version numbers.

The Java Plug-in supports the latest MIME type version (corresponding to the version of the Java Plug-in) and all previous MIME type versions.

Other MIME types supported by the Java Plug-in look like the following:

    application/x-java-applet;version=<version>

To determine which MIME types are supported by the version of the Java Plug-in installed on your computer, enter `about:plugins` in the Firefox location bar. This displays a list of installed and detected plugins. Look for the Java Plug-in entry; it will list all supported MIME types. See `about:plugins` in the MozillaZine Knowledge Base for more information.

For Java Plug-in 1.7.0, the unique MIME type is `application/x-java-applet;jpi-version=1.7`.

Note: Note: If you have different versions of the JRE installed, only the latest version of the Java Plug-in is installed. As mentioned previously, this version of the Java Plug-in supports all previous versions of the Java Plug-in MIME type. These MIME types are supported by the file `npjp2.dll`. The location of this file is listed in the `about:plugins` page.

### 32.2.2 Unique Java Plug-in Registry Key

Every new and update version of Java Plug-in has a unique Java Plug-in registry key. The main Java Plug-in registry key is as follows:

    HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\<version number>

Note: Note: If you installed a 32-bit JRE in a 64-bit operating system, then the Java Plug-in registry key is `HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Plug-in\`<version number>.

To determine <version number>, refer to the Java Plug-in entry in the Firefox `about:plugins` page.

The Java Plug-in that comes with JRE 7u3, has the following registry key:

    HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Plug-in\10.3.0

### 32.2.3 Unique Java Plug-in Property File

The property file is named `deployment.properties`. It is located in the following directory:

    <User Application Data Folder>\Sun\Java\Deployment

<User Application Data Folder> is an application data folder specific to the user.

As an example, for a user `testuser` on a Windows 7 system, the value of <User Application Data Folder> would be `C:\Users\testuser\AppData\LocalLow`

The value of <User Application Data Folder> is obtained from the Win32 API function call `SHGetFolderPath()` with `CSIDL_APPDATA`.

### 32.2.4 Unique Java Plug-in Trace and Log Files

The default location for trace and log files is <User Application Data Folder>`\Sun\Java\Deployment\log`, where <User Application Data Folder> is as defined in Section 32.2.3, "Unique Java Plug-in Property File."

See Section 22.2, "Tracing and Logging" for more information.

### 32.2.5 Unique Java Control Panel

Every new and update release has a unique Java Control Panel. The filename for the Java Control Panel is `javacpl.exe`, which is located in the directory <JRE installation directory>`\bin`.

Only the latest installed version of the Java Control Panel is available from the Windows Control Panel.

### 32.2.6 Unique Registry Keys for JRE/JDK

Every new and update release of the JRE/JDK has unique registry keys. These registry keys are in the following locations:

    HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Runtime Environment\<version number>
    HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Development Kit\<version number>

where the <version number> includes the major, minor and the patch version numbers; for example: `1.7.40`.

Note: Note: If you installed a 32-bit JRE in a 64-bit operating system, then the registry keys are located in Java Plug-in registry key is `HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft`.

These keys enable Java Plug-in to locate the proper version of the JRE.

### 32.2.7 Multi Version Support in Browser Sessions

Multiple JRE versions can be installed on the Windows platform. With multiple JRE's applets using MIME type `jpi-version` will work with Firefox browsers only if you enable the following option:

- To enable the Mozilla Family option for JRE 6 and later, open Java Control Panel and click the Advanced tab. Under Default Java for browsers, select Mozilla family.

To invoke Java Control Panel for a specific version of the JRE, go to the <JRE_HOME>`/bin` directory for that version and run `javacpl.exe`.

Note: Note: Multiple versions of the JRE can be run in different browser sessions. However, multiple versions cannot be run in the same browser session. Should this be attempted, the user is warned and the attempt will fail.

## 32.3 System-Wide Repository (Windows only)

Previously, when a new JRE was installed, JAR and native libraries for the old release were not visible to the new one. Thus applications and applets that relied on those libraries would not work, and developers were forced to redeploy their libraries to the new JRE. The System-Wide Repository is the solution to that problem. It provides a global or system-wide location where the VM can search for libraries, JAR or native, independent of the JRE location. It provides functionality similar to the repository in the Microsoft VM.

Note: The system-wide repository is supported by Java Plug-in only on Windows.

The table below shows the location of the new System-Wide Repository:

Type of Library | System-Wide Location
--- | ---
DLL | Any directory in the System Path environment variable.
Untrusted JAR | `<Windows Directory>\Sun\Java\Deployment\Lib\Untrusted`
Trusted JAR | `<Windows Directory>\Sun\Java\Deployment\Lib\Trusted`

`<Windows Directory>` is the Windows OS directory on the drive where Windows was installed (also called `%SystemRoot%`).

For example, on Windows 7, where Windows has been installed on the C drive (typical), the locations of these libraries would be as follows:

Type of Library | System-Wide Location
DLL | Any directory in the System Path variable; e.g., `C:\WINDOWS\repository` if `C:\WINDOWS\repository` has been set in the System Path variable.
Untrusted JAR | `C:\WINDOWS\Sun\Java\Deployment\Lib\Untrusted`
Trusted JAR | `C:\WINDOWS\Sun\Java\Deployment\Lib\Trusted`

The classes in the JAR files from the system-wide trusted repository are loaded by the extension class loader, whereas the classes in the JAR files from system-wide untrusted repository are loaded by the applet class loader. Thus the former classes are given the `AllPermission` permissions, while the latter are given only default applet permissions.

The system-wide trusted repository implementation is based on the system property `java.ext.dirs`. If users select their own `java.ext.dirs` system property via the Java Control Panel, the JAR files in the system-wide trusted repository will not be loaded by Java Plug-in.

The repository does not provide version or name spaces control. It is up to the deployer to avoid version and name spaces conflicts at deployment time.

## 32.4 Applet Persistence API

Two methods in the interface `java.Applet.AppletContext` enable applet persistence across browser sessions:

- `setStream(String key, InputStream stream)`

- `getStream(String key)`

These methods enable you to stream data and objects from one browser session so that they can be reused in subsequent browser sessions. This provides applet persistence and makes it unnecessary to use static objects in applets for this same purpose.

The `setStream(key, stream)` method maps a key to a stream. The `getStream(key)` method returns the stream mapped to the key. If the `AppletContext` already has a stream mapped to the key when the `setStream(key, stream)` method is invoked, the mapping is updated.

## 32.5 Special Applet Attributes

Applets have default attributes associated with them. Special attributes like `image` and `boxmessage` can be associated with applets and used for customizing the applet window during downloading of an applet. JavaBeans component can also be customized using these special attributes.

### 32.5.1 `image`

The `image` attribute allows you to replace the default animation with a custom graphic. The format with the standard `applet` element is:

    <applet ...>
    <param name="image" value="my_image.gif">
    </applet>

See Using `applet`, `object` and `embed` Tags in Java Plug-in for how this would be mapped to the `object` or the `embed` tags.

If a custom graphic is specified, it should be the same size as the area of the applet window. If these sizes do not match, the graphic will be placed in the upper left corner of the area specified for applet. If it is larger than the applet window, part of it will get chopped off. If it is smaller than the applet window, white, or whatever color is specified for `boxbgcolor`, will appear around it.

The image can be either a GIF or JPEG, and it should reside in the same directory where other resources for the applet reside; i.e., if the applet uses the `codebase` attribute, then this image should be in the `codebase` directory.

Note: The image file should not be in a packaged jar file with other applet resources, since the image needs to be displayed while downloading resources.

The status bar of the browser will display "`Loading Java Applet ...`" when the mouse is pointed at the applet window.

### 32.5.2 `boxmessage`

With the `boxmessage` attribute you can customize the text displayed in the status bar of the browser. This attribute will be in effect when `image` attribute is used. The format for using this with the standard `APPLET` element is:

    <APPLET ...>
    <PARAM name="boxmessage" value="<your custom message goes here>">
    </APPLET>

### 32.5.3 `boxbgcolor, boxfgcolor`

These attributes can be used to customize colors in the applet window.

These attributes will be in effect when the `image` attribute is used. Custom colors cannot be specified for the default appearance of the applet viewing area.

By default the applet window background color is white. The attribute `boxbgcolor` can be used to specify a different background color. The format for use with the standard `APPLET` element is:

    <APPLET ...>
    <PARAM name="boxbgcolor" value="<value>">
    </APPLET>

where `<value>` may be:

- any `Color` from `java.awt.Color`;

- `r,g,b` where `r`, `g`, and `b` are integers in the range of `0-255` that would render an opaque standard RGB (sRGB) color in the `Color` constructor `Color(int r, int g, int b)`;

- standard HTML colors: silver, green, maroon, purple, navy, teal, and olive; or

- hexadecimal color format

Examples of each item above:`value="cyan"`, `value="111,222,145"`, `value="silver"`, `value="#33FF33"`

By default the applet window foreground color is black. The attribute `boxfgcolor` can be used to specify a different foreground color. The color values are the same as described above. The format for use with the standard `APPLET` element is:

    <APPLET ...>
    <PARAM name="boxfgcolor" value="<value>">
    </APPLET>

### 32.5.4 Applet Attribute Precedence

The order of precedence for these attributes in applets is as follows:

1. If no parameters are provided, the default appearance is used.

2. If a custom graphic is specified for the `image` attribute, then the custom graphic appears as described for `image`.

3. If custom text is provided for the `boxmessage` attribute, then custom text is displayed as described for `boxmessage`.

With any combination of `image` and `boxmessage` attributes, custom colors can always be provided with the `boxbgcolor` and `boxfgcolor` attributes.

### 32.5.5 Troubleshooting Scenario

If an applet fails to load the following actions are performed:

- The applet window displays error information.

- The applet window has a single pixel border using white for the foreground color, and a small "broken" graphic occupies the upper left corner.

The user can click the link for more details about the error.

Contents Previous Next

Copyright © 1993, 2015, Oracle and/or its affiliates. All rights reserved.
Contact Us