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.
This section covers the following topics:
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_version , and
cache_archive_ex values in the
OBJECT/EMBED tag as described below.
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 .
The cache_version is an optional attribute. If used, it contains a list of file versions to be cached:
<PARAM NAME="cache_version" VALUE="188.8.131.52, 184.108.40.206, 220.127.116.11">
Each version number is in the form
x is a
hexadecimal number. Each version number corresponds to a respective
.jar file in the cache_archive.
In order to allow pre-loading of
.jar files, the
cache_archive_ex can be used. This
parameter allows you to specify whether the
needs to be pre-loaded; optionally the version of the
.jar file can also be specified.
cache_archive_ex has the following format:
The optional tags
jar_file_version can appear after the
jar_file_name in any order separated by the
delimiter ";". "
The following shows how these tags might be used in an HTML page:
<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">
In the above example,
a.jar is specified in
d.jar are specified in
cache_archive. The versions are also specified for
0.3D.22.FFFE, respectively. In
applet.jar is specified
to be pre-loaded.
util.jar is also specified to be
pre-loaded but along with the version. For
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
is used without
files specified in
cache_archive are treated no
differently than the
.jar files specified in HTML
archive. Similar treatment is given to
.jar files specified in
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
By default, without the cache_version attribute, applet caching will be updated if:
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.
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.
Although sticky applets are cached locally, they will still conform to the security policy defined by their original codebase and signer.
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
preloadto 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,
<PARAM NAME="archive_1" VALUE="a.jar, preload, version=2.0*">
<PARAM NAME="archive_2" VALUE="b.jar, version=0.0.0.3">
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.
.jarfiles specified in the manifest's Class-Path variable using Java Plug-in's cache is currently not supported.
codebase. Full URLs are not supported in cache_archive.
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.