Given that we can't easily update uninstall native wrapper to enforce JDK 7 usage or provide message to that effect, it is hard to fix the root cause at this point.
However, given that Windows installer/uninstaller are in fact able to run using JDK 6 runtime provided that we also compile our custom install configuration extensions with 1.6 target, it would IMO make sense to reconfigure maven compiler plugin in installer module and enable this. This would mitigate some of the issues with Windows JDK detection and improve usability. Such installer would still independently enforce the use of JDK 7 for GlassFish runtime.
- What is the impact on the customer of the bug?
While this is not a regression, there is significant usability impact with newer Windows versions and increased 64 bit JDK usage. So, it may be worthwhile to be able to run installer with any JDK that is automatically detected by the wrapper.
- What is the cost/risk of fixing the bug?
Low/moderate risk. We tested and run an almost identical installer code base in 3.1.x release using JDK 6.
- Is there an impact on documentation or message strings?
Possible limited impact on installation guide (need to document the ability to run installer/uninstaller using JDK 6 or higher on Windows platform).
- Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Regular installer testing plus several installer runs using explicitly provided path to JDK 6 installation.
- Which is the targeted build of 4.0 for this fix?
- If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.