JDK-6718336 : kernel jre uninstallation interrupted with java setup - close applications dialog
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows,windows_xp
  • CPU: x86
  • Submitted: 2008-06-24
  • Updated: 2010-04-06
  • Resolved: 2009-07-27
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.
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Kernel jre  uninstallation interrupted with java setup - close applications dialog

Tested build : 6u10 b27 PIT
Tested OS : Win XP

Steps to reproduce:
1. install kernel bundle
2. once the installation is completed, try to uninstall the jre
"Java Setup - Close Applications" dialog popsup asking to close "java.exe" with retry and cancel buttons
Background downloader is still running and it is not getting killed automatically. When retry button is clicked by checking the checkbox "quit the applications listed", it proceeded with uninstallation.

It is a regression from b26. Image file attached.

EVALUATION putback to the integration ws is complete for b01.

EVALUATION I think Bill intended to say we need to call our Files-In-Use custom action *after* the other custom actions above. Please also see CR 6674868...we initially called our own FIU (custom action) as a workaround to the difficiencies of the MSI native version. The native version is invoked in InstallValidate in the InstallExecute sequence. We needed to call our own before InstallValidate in order to avoid the native version. To address the issue of this CR, we'll need to move our own FIU to a point in the InstallExecute sequence that is *after* InstallValidate. This will increase the likelihood that MSI's native version of the dialog will be invoked, but that's ok. Here's why... The native version of the dialog will not catch java[w].exe or jbroker.exe because there is no associated window with these processes. This is one of the downfalls of the native dialog that prompted us to create our own version in the first place. Therefore, we will not need to remove java[w].exe or jbroker.exe from the RemoveFile table...they will not cause the native dialog to be invoked. In considering 6674868, any problems associated with the native version of the dialog will STILL be handled when our 'custom' version is invoked. For example, if the user clicks 'ignore', that's ok because our FIU will be invoked later and handle any processes that are still locking the JRE. The ONLY downside to this fix is that there is potential for 2 "files-in-use" dialogs being displayed. In my opinion this is also ok because the potential for that is very low (user would need to click on 'ignore', or start more java procs after the MSI version is invoked). Generating a webrev now for moving the Files-In-Use custom action down the InstallExecute sequence...

EVALUATION It seems that adding the FilesInUseDialog CustomAction to the InstallExecuteSequence is creating a regression: 6718336: kernel jre uninstallation interrupted with java setup - close applications dialog -this is because FilesInUseDialog is getting called before UninstallJRE can shutdown the background downloader I think we need to call FilesInUseDialog CustomAction before both UninstallJRE and UnInstallJUpdate Custom Actions.