This content has been marked as final. Show 10 replies
Here is something curious....
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.
Now I specify only the one jar in the archive section of the html, which contains a jar with the classpath to all the necessary jars in the manifest and and Index file as well.
Each new jar shows up in the java cache and the console itself refers to the jar in the cache....
Reading certificates from 11 http://blahblahblah.jar | C:\Documents and Settings\dude\Application Data\Sun\Java\Deployment\cache\6.0\20\61ee19d4-232a6a61.idx
Is it possibly downloading the jar every time to the cache?
Brohonimo wrote:Oh an applet. It would have been handy to mention that 2 posts ago.
Here is something curious....
I would recommend launching it using [Java Web Start|http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp]. JWS provides a much more reliable caching mechanism, and you can go further to take complete programmatic control of the downloads if you wish.
I assumed the title of the post implied applet caching, but now that it is much clearer great!
Because our user base is the general population, JWS isn't really practical. It can be very clean, especially for in-house purposes, but for general population use dealing with users who don't have it is a much bigger pain than dealing with users who don't have the plugin. We get millions of users for our applets a year and that would be too radical a change for now.
Right now I'd like to figure out what the plugin and cache are doing. Is it caching or not?
Does the class-path variable prevent caching? Can I add the other jars to the html archive and keep the class-path variable (there appear to be benefits from the INDEX.list in the main jar as well....)
..Because our user base is the general population, JWS isn't really practical. It can be very clean, especially for in-house purposes, but for general population use dealing with users who don't have it is a much bigger pain than dealing with users who don't have the plugin.
1) If the user has the Java plug-in, they have JWS.
2) deployJava.js can ensure the user has Java (& JWS).
3) A JNLP embedded applet is indistinguishable from a non-JWS embedded applet.
.. We get millions of users for our applets a year and that would be too radical a change for now.What 'change'? See point 3 above.
I really feel that Java users are more accepting of JWS than some developers. You sound like you're stuck in thinking that was out of date 5 years ago!
We tried it. I thought I'd seen the light and then simple in-house testing was fraught with all sorts of peril and problems. People who have java 6 have JWS, but not everyone else. We are trying to move to java 6 for all, but until then its not an option. General users of the internet are stuck in 2004. You have to go with the least common denominator.
Brohonimo wrote:JWS has come standard (co-bundled) with Java, since 1.4.2.
We tried it. I thought I'd seen the light and then simple in-house testing was fraught with all sorts of peril and problems. People who have java 6 have JWS, but not everyone else.
..We are trying to move to java 6 for all, but until then its not an option. General users of the internet are stuck in 2004. You have to go with the least common denominator.In that case, make sure your app. is powered by fire.
I can't explain why users with the plugin are unable to run JWS apps, but many can't. The internet is full of examples of why not to use JWS unless you have absolute control over the environment.
We may try again in the future, perhaps once we can rely on a base of java 6 things will be more streamlined.
I appreciate your input but its not the answer I am looking for.
For what its worth...
Beside the problems we had with people using JWS, I believe this was the clincher
Java Web Start has support for lazy downloading, but few developers use it. It can be a way to significantly improve the download and startup time in some applications. To effectively use lazy downloading, Java Web Start must be aware which jar to download to resolve a request for a specific resource. Previous versions of Java Web Start required a complex specification of parts and packages to provide this information. Beginning with version 6.0, the same thing can be accomplished using Jar Indexing.
We do use jar indexing. In any case I tried our our JWS mockup and compared to our current system. Both are caching as they should. And both run with the same performance. The hold up is in the accounting back and forth checking to see if the jar is cached and contains what we need I presume. Since the production environment has so much traffic, it takes a while.
I have made a discovery.
I made some changed. I changed the way we were creating images to use getResourceAsStream as recommended here....
I have found however that only if all of the images are in the same jar do you get the benefits of the cache.
Because we bundle our jars in an "as needed" way, you only have to download a small jar when you need some new images. Images could be in a number of jars in the cache. This used to work great. but it seems now, that there is a great deal of client server searching for the images, or it just doesn't sift through the currently download cache efficiently.
Interestingly, when I implemented this with Java Web Start, it still was very slow in loading the images, even though there was one jar.