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.
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.
- relates to
-
JDK-6850029 java.lang.NoSuchMethodError observed after upgrade from 1.6.0_10 to 1.6.0_11
- Closed
-
JDK-6791250 Tune cache index files
- Closed