Documentation Contents

Note: This Java plug-in guide describes features released prior to the Java SE 6 update 10 release. See Java Rich Internet Applications Development and Deployment for the latest information.

< Contents

# Applet Caching

This section covers the following topics:

- Caching Option
  - cache_archive
  - cache_version
  - cache_archive_ex
  - Cache Update Algorithm
- Security
- Known Issues

## Caching Option

When an applet is cached, it no longer needs to be downloaded when referenced again. This reduces applet startup time. All file types used by Java Plug-in applets are now cached.

An alternative form of applet caching is provided which allows an applet deployer to decide if an applet should be sticky A sticky applet is placed in a disk cache created and controlled by Java Plug-in which the browser cannot overwrite. The only time a sticky applet gets downloaded after caching is when it is updated on the server. Otherwise the applet is always available for fast loading. Applets providing core business applications should be made sticky to improve startup performance.

This feature is activated by including the `cache_archive`, `cache_version` , and `cache_archive_ex` values in the `OBJECT/EMBED` tag as described below.

## Note `.jar` files specified with the `archive` attribute also get cached in this sticky cache.

### cache_archive

The `cache_archive` attribute contains a list of the files to be cached:

    <PARAM NAME="cache_archive" VALUE="a.jar,b.jar,c.jar">

Like the `archive` attribute in the `APPLET` tag, the list of `.jar` files in the `cache_archive` attribute do not contain the full URL, but are always downloaded from the `codebase` .

### cache_version

The `cache_version` is an optional attribute. If used, it contains a list of file versions to be cached:

    <PARAM NAME="cache_version" VALUE="1.2.0.1, 2.1.1.2, 1.1.2.7">

Each version number is in the form `xxxx.xxxx.xxxx.xxxx`, where `x` is a hexadecimal number. Each version number corresponds to a respective `.jar` file in the `cache_archive`.

### cache_archive_ex

In order to allow pre-loading of `.jar` files, the HTML parameter `cache_archive_ex` can be used. This parameter allows you to specify whether the `.jar` file needs to be pre-loaded; optionally the version of the `.jar` file can also be specified. `VALUE` for `cache_archive_ex` has the following format:

    VALUE="<jar_file_name>;<preload(optional)>;<jar_file_version(optional)>,<jar_file_name>;
           <preload(optional)>;<jar_file_version(optional)>,..."

The optional tags `preload` and `jar_file_version` can appear after the `jar_file_name` in any order separated by the delimiter ";". "`,`" separates multiple entries.

The following shows how these tags might be used in an HTML page:

`<OBJECT ....` <PARAM NAME="archive" VALUE="a.jar"> <PARAM NAME="cache_archive" VALUE="b.jar, c.jar, d.jar"> <PARAM NAME="cache_version" VALUE="0.0.0.1, 0.0.2A.1, 0.3D.22.FFFE"> <PARAM NAME="cache_archive_ex" VALUE="applet.jar;preload, util.jar;preload;0.9.0.AC1, tools.jar;0.9.8.7F"> </OBJECT>

In the above example, `a.jar` is specified in `archive`, whereas `b.jar`, `c.jar` and `d.jar` are specified in `cache_archive`. The versions are also specified for `b.jar`, `c.jar`, and `d.jar` as `0.0.0.1`, `0.0.2A.1`, and `0.3D.22.FFFE`, respectively. In `cache_archive_ex`, `applet.jar` is specified to be pre-loaded. `util.jar` is also specified to be pre-loaded but along with the version. For `tools.jar`, only version is specified.

Java Plug-In doesn't compare the versions if they are not specified for all the `.jar` files specified in HTML parameter `cache_archive`. If `cache_archive` is used without `cache_version`, the `.jar` files specified in `cache_archive` are treated no differently than the `.jar` files specified in HTML parameter `archive`. Similar treatment is given to `.jar` files specified in `cache_archive_ex` when preload and version options are not provided.

Class files and resources will be searched in the following order from the `.jar` files specified by the HTML parameters

1. `cache_archive_ex`
2. `cache_archive`
3. `archive`

### Applet Caching Update Algorithm

By default, without the `cache_version` attribute, applet caching will be updated if:

- The `cache_archive` has not been cached before, or
- The "Last-Modified" value of the `cache_archive` on the web server is newer than the one stored locally in the applet cache, or
- The "Content-Length" of the `cache_archive` on the web server is different from the one stored locally in the applet cache.

However, in some situations, the "Last-Modified" value returned from the web server through HTTP/HTTPS may not reflect the actual version of the applets. For example, if the web server crashes and all the files are restored, the `cache_archive` may have a different modification date on the server. Even if the `cache_archive` has not been updated, it will still force all the Java Plug-in clients to download the `cache_archive` again.

To strongly enforce the version update, it is recommended that the applet deployer use the `cache_version` attribute.

If `cache_version` is used, applet caching will be updated if the `cache_version` for the `cache_archive` is larger than the one stored locally in the applet cache. Note that the version number is used for triggering an update; there is no actual version number attached to the `.jar` file on the web server. In fact, unless version is used to trigger an update, it is possible the applet on the web server could be updated without the applet in cache_archive.

`Using cache_version` eliminates the need to connect to the web server to obtain "Modification-Date" and "Content-Length" of the `cache_archive`. In most cases this will speed up performance.

## Security

Although sticky applets are cached locally, they will still conform to the security policy defined by their original codebase and signer.

## Versioning Support

Java Plug-in 6 applets can use the JNLP Version Download protocol for launching JAR resources listed in the HTML file. Versioning also supports JarDiff. To use versioning support use the `archive_x` tag where x specifies a number. The following is the syntax of the `archive_x` tag.

- First value must be the jar filename
- Each value must be separated by comma
- Use `preload` to indicate preloading of the jar file
- `version=` is used to specify the version string for the jar file request

The following are the various ways in which the archive_x tag can be used.

`<PARAM NAME="archive_1" VALUE="a.jar, preload, version=2.0+">`

- The + sign after the version indicates the Java Plug-in to request for a jar file whose version is equal to or higher than the specified version

`<PARAM NAME="archive_1" VALUE="a.jar, preload, version=2.0*">`

- The * sign after the version indicates the Java Plug-in to request for a jar file whose version begins with 2.0, e.g 2.0.1 or 2.0.2

`<PARAM NAME="archive_2" VALUE="b.jar, version=0.0.0.3">`

- This allows Java Plug-in to request for a jar file whose version is exactly 0.0.0.3

## Note If the `archive_x` tag is specified, old style tags (`cache_archive`, `cache_version`, `cache_archive_ex`) are ignored.

Applets using JNLP style version support should use the JNLPDownloadServlet to host the applet resources. More information about JNLP Version Download protocol and JNLPDownloadServlet is available in the JNLP Guide.

## Known Issues

- Caching of the `.jar` files specified in the manifest's `Class-Path` variable using Java Plug-in's cache is currently not supported.
- The path specified in the `cache_archive` must be a relative URL to the applet's `codebase`. Full URLs are not supported in `cache_archive`.
- The "`java.io.IOException: Caching not supported for` ..." is thrown because Java Plug-in could not get the expiration and last-modification dates for a given JAR file from the web server. If the Java Plug-in cannot get the date information, the JAR file is downloaded every time it is used.

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