JDK-6644778 : Improve handling of failed bundle downloads
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: beta,6u4,6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,windows,windows_2003,windows_xp,windows_vista generic,windows,windows_2003,windows_xp,windows_vista
  • CPU: generic,x86
  • Submitted: 2007-12-21
  • Updated: 2010-09-08
  • Resolved: 2008-03-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.
6u10 b13Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
When a Kernel bundle download fails or is cancelled, the current behavior is to simply continue running, allowing the appropriate error to be thrown in response (e.g. NoClassDefFoundError).  This seemed reasonable in theory, but it is proving inadequate in practice.

Programs do not expect to encounter NoClassDefFoundError on system classes.  They generally handle it badly, popping up a variety of misleading error messages.  JNI code, including much of the JRE's own code, often doesn't bother checking error codes for system classes (which are "known" to be present), causing an outright crash.  This happens in the plug-in as well, which crashes in response to failed bundle downloads -- but because it's running in the browser's process, the whole browser dies with it.

Clearly, we cannot rely on arbitrary programs to react properly to missing system classes, or users to understand the bizarre error messages and other problems that can occur when they cancel a bundle download.  The right approach is probably to pop up a dialog explaining that the current program will have to be shut down, and then gracefully kill it before it has a chance to display strange error messages or crash.  This will pose some special challenges in the plug-in, where we cannot call System.exit() without taking the whole browser out with us.