Name: ggC50526 Date: 01/12/98
NEEDED for 1.1.6. Oracle bug number: 609609.
Oracle has some appletviewer changes to enable the appletviewer to cache
JAR files locally (part of an effort to get Oracle Applications to work better
over a dialup line).
The changes are in AppletPanel.java and AppletSecurity.java,
and we have added a new file called AppletCache.java. All of the changes made were done with the JDK 1.1.5K
release from JavaSoft (which I believe became 1.1.5Final).
For verification, the diffs from JDK 1.1.5K look as follows:
AppletPanel.java:
511d510
< AppletCache.getAppletCache().stop();
AppletSecurity.java:
409,417d408
< /**
< * Check if an applet can delete a particular file.
< *
< * ### Temporary impl uses checkDelete.
< */
< public synchronized void checkDelete(String file) {
< checkWrite(file);
< }
AppletResourceLoader.java:
119,125d118
< * The urlCache for this applet. This is where JAR
< * (and in future Class, Image etc) files get cached to.
< */
<
< AppletCache urlCache = AppletCache.getAppletCache();
<
< /*
146c139,141
< InputStream in = urlCache.getInputStream(jarURL);
---
> URLConnection c = jarURL.openConnection();
> InputStream in = HttpURLConnection.openConnectionCheckRedirects(c);
>
The Applet JAR Caching mechanism was built to accomodate the loading, and
storage, of JAR files loaded across a network through the HTTP protocol. It
uses standard HTTP/1.0 based techniques to ensure that the cache entries are
kept up-to-date with the corresponding server. It's use could easily be
expanded to cache other types of information such as class and image files.
Upon startup of the AppletViewer, the AppletCache [singleton] object is
instantiated. It checks to see whether the corresponding cache directory
"jcache" exists and is writable. It searches for this directory in two
places, first it checks the user's home directory "user.home" followed by
checking the JDK home directory "java.home". If the directory isn't found
then the caching is disabled (which allows us to disable it in the field
should a major bug be determined).
All JAR files loaded through HTTP are also stored in the cache directory.
Subsequent requests for the file are pulled from the cache directory instead
of the original server (a check is made with the server to ensure that the
file is up-to-date).
The cache directory is cleaned out whenever it's size exceeds the cache limit.
The cache size defaults to 2Mb, and can be over-ridden by the command line
setting "cache.size" specified as follows:
% java -Dcache.size=20000000 sun.applet.AppletViewer http://...
Unfortunately, the Appletviewer doesn't appear pass along such command line
arguments.
Cache cleanup is performed by a thread. This thread will cleanup the cache
directory in the following cases:
1. a file completes loading.
2. a time interval has passed (60 seconds currently)
3. the cache is shutdown.
The Cleanup thread is shutdown by calling AppletCache.shutdown (this action is
currently performed after all of the JAR files have been loaded).
Bug fixes that are required for this to operate (sample of fixes included in
our source changes):
4092938 The Appletviewer's SecurityManager impl doesn't override
checkDelete()
Other bugs noticed (but not required) during the implementation:
4092605 HttpURLConnection doesn't implement If-Modified-Since Header
4092590 sun.net.www.http.KeepAliveCache should use Daemon threads instead
We have worked around bug 4092605 in the code of AppletCache, but this code
could be simplified if the bug were addressed.
(Review ID: 23147)
======================================================================
- duplicates
-
JDK-4628782 Java Plugin & jar files - No way to exclude web server directory from classpath
-
- Closed
-
-
JDK-4628066 plugin cache does not work for jars loaded by java-applet via URLClassLoader
-
- Closed
-