Even when cache version are specified for jar files, plug-in connects to the server to get the time stamp and last modified date

N/A

Too late for mantis, committing to tiger
 xxxxx@xxxxx  2003-03-25

The initialized CachedJarLoader is not used if the version check is passed. Because of this, the caching code results in timestamp check even if the required version is on the user system.
 xxxxx@xxxxx  2003-07-14

When is 1.4.2_02 expected?

I just downloaded 1.4.2_02 and this does not seem fixed to 
me.  I still am seeing multiple request for the .jar files that 
should be cached

Jar caching in 1.4.2 is a complete mess. 

In my case the plugin does not query the timestamp from the
host, but repeatedly downloads the whole jar file despite
having it in the cache.

I checked all versions from 1.3.1_04 up to 1.4.2_03:
Up to 1.4.1_05 the caching seems to work fine.
From 1.4.2 the plugin stores the applet in its cache, but
still downloads it (several times!) when I visit the page.  

I know a similar problem when the ResourceBundle class looks
for localized .properties files and makes a host connection
despite having the relevant jar in its cache.
In this case however no .properties files are looked up. 

Some other applets seem to be cached ok in the 1.4.2
version. The difference to the repeatedly loaded applet is,
that they do not load any GUI stuff like widgets and images.

This is a very frustrating bug for many developers, because
they cannot send people with a freshly installed java plugin
to see their  applets: the repeated loading makes the
overall startup time unacceptable. 

Agree - the plugin add

Cache-Control: no-cache
Pragma: no-cache

to the HTTP request. that cause a HTTP 200 with full content
body. Tested with 1.4.2_01,02 and 03.

Is there an open bug for that issue?

With 1.4.2_03 (Windows), the cache isn't used. This 
bug isn't fixed so please reopen it.

I agree with everyone else.  The bug is not fixed.  
Console set to lvl 5 tracing will confirm this bug still 
exists.  Re-open it.

We have the same problem. Trying in same 
environtment with jre 1.3.1_11, caching works fine. 
With JRE 1.4.2_04-b05 not work yet. This is a 
important function of JRE Plug-in and I think that this 
bug is important to solve.

We have the same problem. Trying in same 
environtment with jre 1.3.1_11, caching works fine. 
With JRE 1.4.2_04-b05 not work yet. This is a 
important function of JRE Plug-in and I think that this 
bug is important to solve.

Agree.   This bug is a show-stopper for everyone who 
is developing in the applet environment.  BTW, 
is "tiger" the 1.5 release?

Really - why it closed if it's obviously persistant defect? Looks like 1.5 fixed it...

I have the same problem with 1.4.2_05. Grrr.

Given same issue exists with 1.4.2_02  - why is the bug closed?

My client reports double network traffic with 1.4.2.02 rather than earlier versions.

This bug still exists in the 5.0 RC.  When running an applet using the 1.4.1_07 runtime, the applet takes 1 minute to download.  On the 5.0 RC runtime, it takes about 30 minutes!  With a level 5 console watch, you can see that the applet continuously validates against the server instead of locally.

Look at this one 4912903 - I think it will brings the light to the many questions 

This bug has been discovered to have not been fixed.  A new bug has been opened under the id: 5109018

Vote for it there.