JDK-6423370 : Fix for bug 5098318 prevents caching of JAR files containing cipher code
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 1.4.2_10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2006-05-09
  • Updated: 2010-12-07
  • Resolved: 2006-06-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_13 b01Fixed 6Fixed
Related Reports
Duplicate :  
JDK-6400923 - REGRESSION:When call getOutputStream, JVM seems to continuously attempt to connect to the applet
Relates :  
JDK-6226269 - JAR verification causes significant footprint increases
Relates :  
JDK-6354728 - Verification of signed JAR files is very slow (performance reduction)
Relates :  
JDK-5098318 - Cached Jar file should be released on appl. exit even that is opended by Cipher
Description
My customer develops an online banking application for a major german bank. Since upgrading to 1.4.2_10 (where the fix to bug 5098318 is included), their online application JAR file is no longer cached. This results in a massive delay for customers when they attempt to login, as the whole JAR file is downloaded every time a login takes place.

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?
Comments
EVALUATION Based on the various troubleshooting feedback from the customer, the performance issue is affected by: 6226269: JAR verification causes significant footprint increases 5098318: Cached Jar file should be released on appl. exit even that is opended by Cipher Thus, the fix for this performance issue would be to fix the Jar verification performance problem (addressed by 6364728) as well as changing JCE to enable Jar caching for the (plug-in + http jar URL) scenario. As for other scenarios such as (JRE + http/file jar URL), their caching mechanism is memory based and does not affect JCE performance since the jar verification is done only once.
12-06-2006