JDK-6852576 : 1.6.0_14 Jar caching is broken
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u14
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: generic
  • Submitted: 2009-06-18
  • Updated: 2010-05-22
  • Resolved: 2009-10-22
Related Reports
Relates :  
Relates :  
Description
The JAR download component uses internals of IDX files used to track the Jar Cached by Java.

I believe that in certain file named, Cache.java in the com.sun.deploy.cache package the value of a particular constant seems have changed in the 160_14. This class is present in the deploy.jar archive in <JRE_HOME>/lib

private final static int VERSION_INT = 602;

The value for this seems to have changed to 603. This I suppose is the version of the IDX file itself and since the version of the same is set to 602 in our application, there is a mismatch with the version expected in 160_14. This leads to a new download of Jars and when this Jars are written into the cache, they are written again with version 602 and hence there will be a mismatch again next time around as well.

Please investigate the circumstances for this change in the version no. and suggest how we can overcome this.
Also has the structure of the IDX changed with 160_14 ? If so how.

Comments
EVALUATION This is not a bug in the JDK. And customer has resolved it from their end. So closing the case.
22-10-2009

EVALUATION This behavior is seen due to fix for 6791250: Tune cache index files Its an expected behavior, after fix for CR 6791250. I am adding Igors comments from the CR 6791250 I am adding him to the interest list , so that he can further comment on the issue, and if any workaround to it. ************** This fix increments deployment cache version. To facilate upgrade from previous versions of JRE we do support in-place upgrade of cache entries from previous version of cache. However, if this JRE will upgrade the cache and then older update of JRE 6 will try to use the cache it will download application again. Entry 3 igor.nekrestyanov [2009-02-03 12:21] ***************
23-06-2009