|
Quick Lists
|
|
Bug ID:
|
4528599
|
|
Votes
|
133
|
|
Synopsis
|
RFE: Support all file types in caching
|
|
Category
|
java_plugin:misc
|
|
Reported Against
|
1.3
, 1.4
, 1.4.2
|
|
Release Fixed
|
|
|
State
|
11-Closed, duplicate of 4802551,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
|
|
Submit Date
|
16-NOV-2001
|
|
Description
|
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
The current version (1.3.1) of Java Plug-In only checks the browser cache for
files whose names end in .jar or .class. I have been told that for Java Plug-In
1.4 the browser cache will be checked for the following file
types: .class, .jar, .zip, .jpg, .gif, .wav, .au.
While this is a large improvement, I would like to see the browser cache
checked regardless of file type. Our app has thousands of data files (about 500
meg) whose names end in ".bin" and I would like them to be cached. This would
produce a dramatic improvement in performance both in the applet and on the
server that provides this data.
The java example code illustrates the problem and the workaround. You'll need
to create the image files, any 120x120 (or smaller) jpeg will do. Make five
copies of the same jpeg but with the names listed in the applet. Put the
images, the applet and the html page in the same folder on a web server. Start
your favorite browser, load the html page which runs the applet in the plug-in,
look at the server log. Close the browser and do it all again. See that .jar
and .class are cached (status 304) but .jpg, .gif, .zip are not and are loaded
by user-agent Java 1.3.1. Also see that the images are loaded correctly
regardless of file name (the workaround).
Here is my log, customer combined file format:
10.1.1.105 - - [16/Nov/2001:10:03:41 -0500] "GET /imagecaching.html HTTP/1.1"
200 2136 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
10.1.1.105 - - [16/Nov/2001:10:03:44 -0500] "GET /imagecaching.class HTTP/1.1"
200 1345 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
10.1.1.105 - - [16/Nov/2001:10:03:44 -0500] "GET /bill.jar HTTP/1.1" 200 8246 "-
" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
10.1.1.105 - - [16/Nov/2001:10:03:44 -0500] "GET /bill.class HTTP/1.1" 200
8246 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
10.1.1.105 - - [16/Nov/2001:10:03:44 -0500] "GET /bill.jpg HTTP/1.1" 200 8246 "-
" "Java1.3.1"
10.1.1.105 - - [16/Nov/2001:10:03:44 -0500] "GET /bill.gif HTTP/1.1" 200 8246 "-
" "Java1.3.1"
10.1.1.105 - - [16/Nov/2001:10:03:44 -0500] "GET /bill.zip HTTP/1.1" 200 8246 "-
" "Java1.3.1"
10.1.1.105 - - [16/Nov/2001:10:04:14 -0500] "GET /imagecaching.class HTTP/1.1"
304 - "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
10.1.1.105 - - [16/Nov/2001:10:04:14 -0500] "GET /bill.jar HTTP/1.1" 304 - "-
" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
10.1.1.105 - - [16/Nov/2001:10:04:14 -0500] "GET /bill.class HTTP/1.1" 304 - "-
" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
10.1.1.105 - - [16/Nov/2001:10:04:14 -0500] "GET /bill.gif HTTP/1.1" 200 8246 "-
" "Java1.3.1"
10.1.1.105 - - [16/Nov/2001:10:04:14 -0500] "GET /bill.zip HTTP/1.1" 200 8246 "-
" "Java1.3.1"
10.1.1.105 - - [16/Nov/2001:10:04:14 -0500] "GET /bill.jpg HTTP/1.1" 200 8246 "-
" "Java1.3.1"
HTML page to load applet:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Image Caching AWT Applet - Examples</title>
</head>
<body>
<table border="0" cellspacing="0" cellpadding="0" width="780">
<tr>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td align="left" valign="top">
<!--"CONVERTED_APPLET"-->
<!-- HTML CONVERTER -->
<SCRIPT LANGUAGE="JavaScript">
<!--
var _info = navigator.userAgent;
var _ns = false;
var _ns6 = false;
var _ie = (_info.indexOf("MSIE") > 0 &&
_info.indexOf("Win") > 0 &&
_info.indexOf("Windows 3.1") < 0);
//-->
</SCRIPT>
<COMMENT>
<SCRIPT LANGUAGE="JavaScript1.1">
<!--
var _ns = (navigator.appName.indexOf("Netscape") >= 0 &&
((_info.indexOf("Win") > 0 &&
_info.indexOf("Win16") < 0 &&
java.lang.System.getProperty("os.version").indexOf("3.5") < 0) ||
(_info.indexOf("Sun") > 0) || (_info.indexOf("Linux") > 0) ||
(_info.indexOf("AIX") > 0) || (_info.indexOf("OS/2") > 0)));
var _ns6 = ((_ns == true) && (_info.indexOf("Mozilla/5") >= 0));
//-->
</SCRIPT>
</COMMENT>
<SCRIPT LANGUAGE="JavaScript">
<!--
if (_ie == true)
document.writeln('<OBJECT classid="clsid:CAFEEFAC-0013-0001-0000-ABCDEFFEDCBA" WIDTH = 658 HEIGHT = 650 codebase="http://java.sun.com/products/plugin/1.3.1/jinstall-131-
win32.cab#Version=1,3,1,0"><NOEMBED><XMP>');
else if (_ns == true && _ns6 == false)
document.writeln('<EMBED type="application/x-java-applet;jpi-version=1.3.1" CODE = "imagecaching.class" CODEBASE = "." WIDTH = 658 HEIGHT = 650 pluginspage="http://java.sun.com/products/plugin/1.3.1/plugin-install.html"><NOEMBED><XMP>');
//-->
</SCRIPT>
<APPLET CODE = "imagecaching.class"
codebase="."
WIDTH = 658
HEIGHT = 650
id=Applet1></XMP>
<PARAM NAME = CODE VALUE = "imagecaching.class" >
<PARAM NAME = CODEBASE VALUE = "." >
<PARAM NAME="type" VALUE="application/x-java-applet;jpi-version=1.3.1">
</APPLET>
</NOEMBED></EMBED></OBJECT>
<!--
<APPLET CODE="imagecaching.class"
CODEBASE = "."
WIDTH = 658
HEIGHT = 650>
</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
Java applet source code:
import java.awt.*;
import java.awt.image.*;
import java.applet.Applet;
public class imagecaching extends Applet
{
Image imagejpg = null;
Image imagegif = null;
Image imagejar = null;
Image imageclass = null;
Image imagezip = null;
public void init()
{
// The data: 5 identical copies of a 120x120 jpeg image
// The files are named with different extensions to see the effect
// of the filename on whether they are loaded from the
// browser cache or whether the applet goes directly to the server
// The files are in the same directory as the applet and the
// applet is run in the Java Plug-In 1.3.1
// Watch the web server's log for two things, the status code
// and the user agent. For .jpg, .gif and .zip the useragent is Java
1.3.1
// for .jar and .class it is the browser (MSIE on win2k)
imagejpg = getImage(getCodeBase(), "bill.jpg");
imagegif = getImage(getCodeBase(), "bill.gif");
imagejar = getImage(getCodeBase(), "bill.jar");
imageclass = getImage(getCodeBase(), "bill.class");
imagezip = getImage(getCodeBase(), "bill.zip");
}
public void paint(Graphics g)
{
int x = 10;
int y = 30;
mydrawimage(g,imagejpg,x,y,"bill.jpg");
x += 128;
mydrawimage(g,imagegif,x,y,"bill.gif");
x += 128;
mydrawimage(g,imagejar,x,y,"bill.jar");
x += 128;
mydrawimage(g,imageclass,x,y,"bill.class");
x += 128;
mydrawimage(g,imagezip,x,y,"bill.zip");
}
public void mydrawimage(Graphics g, Image image, int x, int y, String label)
{
if(image != null)
{
g.drawImage(image,x,y,this);
g.drawString(label,x,y+10+image.getHeight(this));
}
}
}
(Review ID: 135813)
======================================================================
FULL PRODUCT VERSION :
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)
FULL OPERATING SYSTEM VERSION : customer Windows 2000
[Version 5.00.2195]
A DESCRIPTION OF THE PROBLEM :
When running applets that use .gifs they are no longer in
the browser cache (temporary internet files) nor are they
in the plugin cache. .class and .jar are there but
not .gif.
Images are instantiated using Applet.getImage(URL).
Everything is cached with the customer VM and previous
versions of the applet but not with 1.4.
REGRESSION. Last worked in version 1.3
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.run applet
2.view cache
3.
EXPECTED VERSUS ACTUAL BEHAVIOR :
I expected to see a listing of the .gifs with the .classes
and .jars
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER WORKAROUND :
images can be placed in jars, but because of the amount of
images it is problematic.
(Review ID: 163747)
======================================================================
|
|
Work Around
|
Renaming a file to end with .jar or .class will cause the applet to check the
browser cache first, but I don't know what effect this has on performance as
the real content type will be different from what would be guessed from the
file name. I also haven't checked for calls other than getImage().
======================================================================
|
|
Evaluation
|
Committed to Hopper.
xxxxx@xxxxx 2002-03-01
uncommit to hopper. Not on our fix list.
xxxxx@xxxxx 2002-03-20
Commit to tiger
xxxxx@xxxxx 2002-07-30
Reassign to Rajani.
xxxxx@xxxxx 2003-01-15
This is related to the Unified download engine work. Reassign to Thomas.
xxxxx@xxxxx 2004-11-10 00:20:32 GMT
As the synopsis of this bug suggest, this is only for adding support to cache all file types in the current plugin cache. This support is targeted for mustang (6.0).
For browser cache support in java plugin, please refer to RFE 6230311.
xxxxx@xxxxx 2005-2-17 01:27:31 GMT
this is fixed as part of 4802551: Consolidate Download Engine and Cache from plugin and webstart
xxxxx@xxxxx 2005-04-01 23:30:44 GMT
|
|
Comments
|
Submitted On 30-NOV-2003
Hockey_Dave
I'd like to see the plugin enhanced to not only check for files
in the browser cache, but to also have an option to deposit
files read via URLConnection into the browser cache. That's
the way the old legacy browser jvm's worked and my
company has built a business around this. We need this for
all file types (i.e. check the browser cache, honor
expirations, and deposit to browser cache w/ expirations).
Submitted On 01-DEC-2003
Hockey_Dave
In case you're wondering why I keep saying browser cache
and not jpi_cache. It is because we need that content
cached as reusable components outside of the java applet
context (i.e. normal html page contexts w/ or w/o the applet).
Submitted On 01-DEC-2003
Hockey_Dave
If nothing else, Sun should fix this RFE because the Sun JVM
creates massively more load on the Internet. The default
setting if URLConnection.setIfModifiedSince(0); means that all
file types will be downloaded over and over again creating
massive bottlenecks on the Internet. Not very friendly of
Sun.
Submitted On 01-DEC-2003
Hockey_Dave
Let me be absolutely specific about what we'd like to see
implemented. In a nutshell legacy equivalent functionality in
utilizing the browser cache (i.e. /Temporary Internet
Files/IE5.Content) minimally as an option. For all file types:
1. When a URLConnection read is performed, the jvm should
check to see if the file is already in the browser's cache
(IE5.Content). If so, check the expiration header -- if
necessary ping the origin server w/ an If-Modified-Since
(once per browser session only!), provide the data to the
applet from the browser cache, or from the origin server
depending upon whether the origin server replied w/ an HTTP
304 or 200 response code.
2. If the origin server responded with a 200 http code, the
file must be put into the browser cache with the proper
Expiration header so that the file is available to the browser
in normal HTML context. At least as an option if not the
default behavior.
3. Ideally, this should be controlled by the
URLConnection.setUsesCache(true); to utilize the browser
caceh or not as this is the legacy behavior.
Submitted On 02-DEC-2003
kiacavoni
I agree with the sentiments from someone else that I found
in the forum. This is right on. This defect is:
1. It's contrary to legacy jvm solutions. Some of us have
built a business with applets taking into account this behavior.
2. Sun is not being a nice member of the Internet community
by forcing applets to download files over and over again
clogging up you LAN, WAN, Internet, and heaven help you if
you're on dialup.
3. Contrary to proper OOD (i.e. no component reuse). If
your applet downloads a large media file, it should be
reusable on other HTML pages that may be outside of the
applet context (i.e. normal HTML, active-x, etc environments).
4. Increased costs. My business pays for bandwidth into
and out of our data center. We also pay for a CDN (content
distribution network) to cache our large media files around
the world. Downloading these files over and over again is
costing us a bundle of money.
Submitted On 04-DEC-2003
JoshSultanik
While the JPI cache might be useful for a standalone Java
app, it is not useful for web app. In fact, by not integrating
with the browser's cache and using its own cache, the
current SUN JVM is harmful to a web apps performance. A
web app utilizes several technologies, including Java,
JavaScript, HTML, ActiveX objects, etc. Sun needs to fix
this bug in the next release so that we can continue to build
fully integrated and efficient web apps
Submitted On 04-DEC-2003
mvalarelli
We really need this fixed. We use Unicast's products and the
fact that Sun doesn't allow caching could affect a big
percentage of our users. Please help
Submitted On 04-DEC-2003
javajackman
This really is a horrible implementation for the java plugin. I'm
not even crazy about it in a j2ee environment, but at least
there I can maybe figure out how to accomplish what I need
to do. I agree with the above people. Bad for the Internet,
bad OOD. Please fix this asap!
Submitted On 04-DEC-2003
blberman
I believe this should be classified as a defect rather than an
enhancement.
Submitted On 04-DEC-2003
beckella
This should be listed as a bug, not a feature!
This must be fixed.
Please fix this in the 1.5 tiger release
Submitted On 04-DEC-2003
nyLUXny
This should be listed as a bug, not a feature!
This must be fixed.
Please fix this in the 1.5 tiger release
Submitted On 04-DEC-2003
asavarino
This bug has to be fixed -- soon! Please advise when you will
respond with a timeframe.
Submitted On 18-MAR-2004
Hockey_Dave
renaming our files to .jar or .class is not an acceptable
workaround for us because of 2 reasons:
1. Sun caches .jar and .class files in the .jpicache and
not in the normal IE cache. We use complicated (i.e.
powerful) Internet technology solutions that employ
Java (heavily), javascript, and plugins. Javascript and
the plugins also need access to the files and storing
them in your proprietary cache denies them access.
2. Putting on an incorrect extension also messes up
the plugins as most of them need the proper extension
to behave correctly.
thanks.
Submitted On 06-DEC-2004
gbishop
This is a bug, not an RFE.
Submitted On 16-MAR-2005
JessHolle
The lack of caching for .properties files is particularly loathesome. There are good reasons if these are volatile to exclude them from jar files, but they can also become big enough to be worth caching...
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
|
