JDK-6833260 : Revisit DownloadManager initialization if it should only begin after VM completes its initialization
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: generic
  • Submitted: 2009-04-22
  • Updated: 2010-09-15
  • Resolved: 2010-09-15
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.
JDK 7
7Resolved
Related Reports
Duplicate :  
JDK-6612680 - Remove classloader dependency on jkernel
Relates :  
JDK-6888880 - JKernel VM to inject the sun.jkernel.DownloadManager as a boot classloader hook
Relates :  
JDK-6833261 - Error when building 6u14 b05 jkernel on Windows
Relates :  
JDK-6825019 - DownloadManager should not be loaded and referenced for full JRE
Description
The current DownloadManager initialization begins before VM completes its initialization during System.initializeSystemClass is called.  However, the DownloadManager's static initializer assumes that the VM initialization has completed. For example, it is using java.io.FileOutputStream.

The DownloadManager initialization has to be revisited to make sure that the initialization sequence is properly implemented.
Comments
EVALUATION This has been fixed by 6612680. The fix for 6612680 changes that the download manager will not start until the VM completes the initialization (see also 6888880).
15-09-2010