This section covers the following topics:
Once an applet it is cached, it no longer needs to be downloaded when referenced again. Thus performance is improved.
This release introduces an alternative form of applet caching, allowing an applet deployer to decide if an applet should be "sticky", i.e., placed in a secondary disk cache 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 new feature is activated by including the new cache_archive,
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="1.2.0.1, 2.1.1.2, 1.1.2.7">
Each version number is in the form X.X.X.X, where X
is hexadecimal. Each version number corresponds to a respective .jar
file in the cache_archive.
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.
The value of cache_archive_ex has the following format:
cache_archive_ex =
"<jar_file_name>;<preload(optional)>;<jar_file_version(optional)>,<jar_file_name>; <preload(optional)>;<jar_file_version(optional)>,....
The optional tags
like preload or the jar_file_version can appear
after the jar_file_name in any order seperated by the delimiter
";".
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.A.B, 0.A.B.C"> <PARAM NAME="cache_archive_ex" VALUE="applet.jar;preload, util.jar;preload;0.9.0.abc, tools.jar;0.9.8.7"> </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.A.B,
and 0.A.B.C, 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
cache_archive_ex cache_archive archive 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 will 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.
Although sticky applets are cached locally, they will still conform to the security policy defined by their original codebase and signer.