JDK-7165926 : my .jar file can no long run by double-click under Windows Explorer.
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 7,7u4,7u6
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_7
  • CPU: x86
  • Submitted: 2012-05-02
  • Updated: 2013-06-07
  • Resolved: 2012-05-03
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.
7u4 b22Fixed 8Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
I tried to move to 7u4 on Windows, and then discovers that all my .jar file can no long run by double-click under Windows Explorer.

Verified by Andy Chen at Evergreen.

EVALUATION It looks like the regdeploy project introduced this regression on the install side. These 2 lines were incorrectly removed from RegInstall.cpp: regMapEntriesCurrent[index].szKey = L"JARFILE_PARAM"; regMapEntriesCurrent[index++].szData = A2OLE("\"%1\" %*"); when generating the RegCurrentVersion.rgs file, which looks like this: HKCR { ForceRemove .jar = s 'jarfile' { } ForceRemove jarfile = s 'Executable Jar File' { ForceRemove shell { ForceRemove open { ForceRemove command = s '"%JAVAHOME%\bin\javaw.exe" -jar %JARFILE_PARAM%' } } } NoRemove Applications { ForceRemove 'java.exe' { val IsHostApp = s '' } ForceRemove 'javaw.exe' { val IsHostApp = s '' } } } HKLM { NoRemove SOFTWARE { NoRemove JavaSoft { NoRemove 'Java Runtime Environment' { val CurrentVersion = s '%FAMILY_VERSION%' } } } } This rgs file used to be riddled with plugin registries before we pruned them for the regdeploy project. So I must have missed that the JARFILE_PARAM was still in the rgs file after taking the deploy stuff out. It looks like the HKLM tree of the rgs file was applied correctly, which would have made the issue more obvious if it hadn't. Only the HKCR part fails silently.