JDK-6833261 : Error when building 6u14 b05 jkernel on Windows
  • Type: Bug
  • Component: other-libs
  • Sub-Component: other
  • Affected Version: 6u14
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2009-04-22
  • Updated: 2010-07-23
  • Resolved: 2009-04-23
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 6
6u14 b05Fixed
Related Reports
Relates :  
JDK-6833260 - Revisit DownloadManager initialization if it should only begin after VM completes its initialization
Description
Windows JRE build failed.

NeededToRun attempt=1 Exec: "C:\BUILD_AREA\jdk6_14\control\build\windows-i586\tmp\kernel\j2re-image-copy\bin\java" -verbose -Dkernel.nomerge=true -Dkernel.debug=true -Dkernel.download.url=internal-resource/ -Dkernel.background.download=false -Dkernel.deploy.debug=true -verify -Xbootclasspath/a:SplitJRE.jar                     -Djava.security.manager sun.kernel.DownloadTest

Error occurred during initialization of VM
java.lang.ExceptionInInitializerError
    at java.io.File.deleteOnExit(Unknown Source)
    at sun.jkernel.DownloadManager$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.jkernel.DownloadManager.<clinit>(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.loadLibrary0(Unknown Source)
    at java.lang.System.loadLibrary(Unknown Source)
    at java.lang.System.initializeSystemClass(Unknown Source)
Caused by: java.lang.NullPointerException
    at java.io.DeleteOnExitHook.<clinit>(Unknown Source)
    at java.io.File.deleteOnExit(Unknown Source)
    at sun.jkernel.DownloadManager$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.jkernel.DownloadManager.<clinit>(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.loadLibrary0(Unknown Source)
    at java.lang.System.loadLibrary(Unknown Source)
    at java.lang.System.initializeSystemClass(Unknown Source)
Comments
EVALUATION The DownloadManager initialization begins before the VM completes its initialization (during System.initializeSystemClass). The classes/libraries needed for VM initialization should be included in the core bundle for bootstrapping. The DownloadManager should be deferred until This issue surfaces due to the fix for 6810254. For 6u14 b05, we will putback a fix to workaround the existing DownloadManager initialization. The DownloadManager initialization has to be revisited for the next release (see 6833260)
22-04-2009
SUGGESTED FIX ------- j2se/src/share/classes/java/lang/System.java ------- 34c34 < * @version %I%, %G% --- > * @version 1.162, 04/01/09 1072a1073,1077 > // Workaround until DownloadManager initialization is revisited. > // Make JavaLangAccess available early enough for internal > // Shutdown hooks to be registered > setJavaLangAccess(); > 1118a1124 > } 1119a1126 > private static void setJavaLangAccess() {
22-04-2009