From 1.4 release, Java Plug-In by default caches all the jar files downloaded by using HTTP and HTTPS protocols. Earlier releases of Java Plug-In provided an option to use the browsers cache and/or Java Plug-In jar cache. Disadvantage of using browser cache is that we do not know when the jar file is removed from the browser cache. Also, it is not possible for the user to configure to their own requirements. So, we have decided not to rely on browser cache any more. This implementation will be backward compatible with earlier releases of Java Plug-In.
By default jar files are downloaded from the server when they are needed by the applet. Although this approach improves the applet startup time, there are few issues we need to consider
In order to address the problem mentioned in the above paragraph, we have
introduced a new HTML parameter which allows user to specify jarfiles which are
to be pre-loaded.
Java Plug-In does not require any special parameters in HTML tags in order to use Java Plug-In jar cache. Whenever a jar file is required to run an applet, Java Plug-in checks whether that file exists in the cache. If exists, before using the cached file, Plug-in verifies whether the file is upto-date. This is accomplished by obtaining the header information from the host. For performance reasons some users do not like to make connection every time they run their applets. Java Plug-In resolves this issue by using HTML parameters cache_archive and cache_version. Similar to HTML parameter archive, user can specify jar files in HTML parameter cache_archive. For each of the jar file specified in cache_archive, user can specify the version in the format x.x.x.x, where x is an hexa-digit number ranging from 0000-FFFF. When a version is specified for a jar file, plug-in checks whether the version for the cached jar file is equal to or greater than the version specified in the HTML page. If yes, it uses the cached jar file. Otherwise, it downloads the jar file. As explained, extra connection to verify the jar file is avoided.
In order to allow
pre-loading of jar files, we have introduced a new HTML parameter called cache_archive_ex,
this parameter allows one 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 HTML tag describes the various parameters,
<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. Whereas 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 is treated no differently than the jar files specified in HTML parameter archive. Similar treatment goes to the jar files specified in cache_archive_ex without preload or version options.
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
By default the location of cache is dependent on environment variables and OS
platforms.
If USER_JPI_PROFILE is set, the location will be
$(USER_JPI_PROFILE)\.jpi_cache\jar\1.0 on both Windows and Unix platforms
If USER_JPI_PROFILE is not set, cache location depends on the OS platform and is
as follows
$(USER_PROFILE)\.jpi_cache\jar\1.0 on windows NT and Windows 2000
$(Windows System Directory)\.jpi_cache\jar\1.0 on Windows 95 and 98
$(HOME/.jpi_cache/jar/1.0 on Unix platforms
Cache tab in the Java Plug-In control panel allows users to configure the jar cache to their requirements. Cache tab of control panel is as shown below
Control panel allows you to do the following
Jar
Cache Viewer allows user to view and delete the jar files in Java Plug-In jar
cache. It can be launched either by selecting the button View Jar Cache
in the cache tab of Java Plug-In control panel or as a separate application by
using the command
java ?
<location of jaws.jar> sun.plugin.cache.JarCacheViewer
Snapshot
of a jar cache viewer is as shown below.
Following attributes are shown for each of the jar file
Viewer has three buttons at the bottom, their name and functions are as follows
If you try to delete any jar file which is being used by some other processes,
following dialog box is shown
Jar files in the cache will be updated based on the following attributes
Assuming an applet requires a jar file from a remote server. Java Plug-In before making a connection to fetch the jar file, it checks whether the jar file is available in the cache. The logic followed by Java Plug-in is as follows.
If a cached jar file is not upto-date, it is marked as unusable and the latest jar file is downloaded into a new file. Java Plug-in periodically removes the unused files.
Downloaded .jar file is stored in the cache as a .zip file. In order to manage the jar cache, Java Plug-In generates an index file with an extension .idx for each of the cached jar file. Therefore we have files with the extensions .idx and .zip for each jar file. In order to improve the performance, signed jar files are verified only when they are downloaded into the cache. This is made possible by storing the authentication information in an index file for signed jar files.
The content of an index file has the following format
First byte of an index file is marked 0 until the file is completely downloaded. When it is completely downloaded it is set to the value of Jar Cache Implementation version. The Jar Cache Implementation Version is greater than 16 and usually its value changes with any modifications to the index file format. Its first byte is set to 1 as soon as the cached jar file becomes unusable.
If a size limit is specified in the control panel, before adding a new jar file into the cache, Java Plug-in will try to remove the least recently used jar files in the cache until the cache size is within the user specified limit. Unusable jar files are deleted before deleting any usable jar files. Jar Cache Viewer allows the user to selectively delete the cached jar files. An option is available on the cache tab of the control panel to delete all the jar files.
Revision | Modification date | Author(s) |
0.2, revised the text, added pre-load HTML parameter explanation | 07/30/2001 | Devananda J.(jdeva@eng.sun.com) |
0.1(Initial Draft) | 06/15/2001 | Devananda J.(jdeva@eng.sun.com) |