-
Bug
-
Resolution: Fixed
-
P2
-
1.4.2_10
-
b01
-
x86
-
windows_2000, windows_xp
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2139029 | 6 | Valerie Peng | P2 | Resolved | Fixed | b95 |
JDK-2139028 | 5.0u10 | Abhijit Saha | P2 | Resolved | Fixed | b02 |
From speaking with Mala Bankal, he believes that the fix for bug id 5098318 to be the cause for this problem.
From the original bug, we have:
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
jars.
Will have to disable caching unless the current JarURLConnection
impl can be fixed/enhanced to support the file purging.
As the disablement of this cache is now causing problems, would it be possible to
fix the JarURLConnection implementation, so that the cipher code correctly obeys
the caching status as set by setUseCaches?
- backported by
-
JDK-2139028 Fix for bug 5098318 prevents caching of JAR files containing cipher code
- Resolved
-
JDK-2139029 Fix for bug 5098318 prevents caching of JAR files containing cipher code
- Resolved
- duplicates
-
JDK-6400923 REGRESSION:When call getOutputStream, JVM seems to continuously attempt to connect to the applet
- Closed
- relates to
-
JDK-6226269 JAR verification causes significant footprint increases
- Resolved
-
JDK-5098318 Cached Jar file should be released on appl. exit even that is opended by Cipher
- Resolved
-
JDK-6354728 Verification of signed JAR files is very slow (performance reduction)
- Resolved