JDK-6874881 : Read manifest lazily from the cache
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-08-22
  • Updated: 2013-11-01
  • Resolved: 2009-11-20
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.
6u18 b04Fixed 7Fixed
Related Reports
Relates :  
For signed jars manifest files are often large (e.g. for FX runtime manifest is 100k compressed and 250k uncompressed) and vast majority of space is occupied by list of (name, signature) for all class files.

With recent enhancements in the caching results of security validation this info is often not used for subsequent starts of the same app. In fact majority of application obtain very few details from manifest files
- some of the main attributes and also sealing information for packages (but it is rarely present).

The idea is to keep all but main attributes and package data separately in the cache index file and read them only if they are requested.

EVALUATION Prototype shows 5% improvement in the warm startup time for applet_fx_jpi benchmark. Note that downside is that we need to do a bit more work when jar is downloaded (to generate index file). In longer term we should consider saving/generating index files in the background but this will be investigated under different bug id.