Applet Caching and Installation in Java Plug

Applet Caching
Select a Chapter/Topic Table of Contents Search Page Chapter 1: Overview--What Is Java Plug-in? What Does It Support? Chapter 2: Using the Conventional Applet Tag Chapter 3: Using OBJECT, EMBED and APPLET Tags in Java Plug-in Chapter 4: Using the HTML Converter to Convert Applet Tags for Java Plug-in Chapter 5: Proxy Configuration Chapter 6: Protocol Support: HTTP, HTTPS, FTP, GOPHER and SOCKS Chapter 7: Cookie Support Chapter 8: Applet Caching and Installation Chapter 9: Using the Java Plug-in Control Panel to Set Plug-in Behavior/Options Chapter 10: Installation for Conventional Applets (Microsoft Windows Only) Chapter 11: Intranet With OBJECT/EMBED Tag Chapter 12: Internet Deployment Chapter 13: Silent Installation Chapter 14: Jar Indexing Chapter 15: Java Server Pages Chapter 16: Overview—Applet Security Basics Chapter 17: How RSA Signed Applet Verification Works in Java Plug-in Chapter 18: How to Sign Applets Using RSA-Signed Certificates Chapter 19: How to Deploy RSA-Signed Applets in Java Plug-in Chapter 20: Debugging Support Chapter 21: Java Plug-in Console Chapter 22: Tracing and Logging Chapter 23: Supporting Multiple Versions of JRE/Java Plug-in Chapter 24: Java-to-JavaScript Communication Chapter 25: JavaScript-to-Java Communication (Scripting) Chapter 26: Deploying Java Extensions Chapter 27: Applet Persistence API Chapter 28: Special Applet Attributes Appendix 1: Netscape 6 Appendix 2: Frequently Asked Questions (FAQ) Appendix 3: More About HTML Converter Appendix 4: Microsoft VM and Java 2 Compatibility Issues Appendix 5: Complete Example -- Deploying Java Media Framework as Java Extension Appendix 6: Sun-Supported Specification-Version and Implemenation-Version Formats
This section covers the following topics:
Caching Optioncache_archivecache_versioncache_archive_exCache Update Algorithm
SecurityKnown Issues
Caching Option
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 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 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.
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:
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:

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=";;,; ;, ..."
The optional tags preload and jar_file_version can appear after the jar_file_name in any order seperated by the delimiter ";". "," separates multiple entries.
The following shows how these tags might be used in an HTML page:

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
cache_archive_ex cache_archive 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.
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. If you get the "java.io.IOException: Caching not supported for ..." exception, this is because Java Plug-in was unable to get the expiration and last-modification dates for a given JAR file from the web server. If the Java Plug-in cannot get this information, there is no point in caching since the JAR file will be downloaded every time it is used. Even with this exception, however, the applet should work fine. This exception is merely informative.