As part of JCE export requirement, JCE framework has mechanisms
which would check the crypto configuration of the system
(JCE jurisdiction policy file) and the calling apps (optional
permission files bundled with the app) and determine the
available crypto algorithms and their max key length.
Thus, JCE framework would access caller codebase as well as
several other jars in order to determine the allowed crypto
strength. The accesses are through JarURLConnection and caching
is on *by default*. The current JarURLConnection impl does
not seem to allow its callers to purge or delete the cached
Will have to disable caching unless the current JarURLConnection
impl can be fixed/enhanced to support the file purging.
###@###.### 2004-11-19 22:33:57 GMT
###@###.### 2004-11-19 22:34:10 GMT
We have provided a fix in 1.4.2_10 that also works in tiger,
but for some reason the same fix is not working in mustang. I'm pretty
sure the problem is in either the GC or in the Zip file code. I took
a large chunk of the JCE jar verification code out, and watched it
iterate over the 8 jar entries (skipping the rest) and it worked fine,
but on the 9th (skipping the rest), it failed. I'm pretty sure it's GC, but
need to move the zip/jar code from tiger into mustang to remove this
###@###.### 2005-06-07 00:13:39 GMT
I generated another testcase based on the current testcase but without calling
into JCE. This looks very much like a GC issue as the test is very fickle and
there is no single API call which would cause the behavior to change.
Anyway, I've filed 6321722 "On windows, sometimes jar file cannot be deleted even when there is no reference to it" to keep track of this. Thus, I have attached
the JCE regression test (JarCachingTest.java) for verifying the fix in mustang.
6321722 was filed, and following promotion of that fix (b59), Valerie reports:
Both the modified (which I modified to remove the dependency on JCE) and
the original (which uses JCE) testcase work as expected, i.e. fail on
b58 and pass on b59.
Guess we finally have this hard-to-trace bug nailed down and fixed. :)
Yay...that burned way too many cycles!