JDK-7069603 : refactor unregister deploy in regfx.cpp
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 7-client
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2011-07-22
  • Updated: 2013-09-12
  • Resolved: 2011-10-13
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 Availabitlity Release.

To download the current JDK release, click here.
7u2 b08Fixed 8Fixed
when fixing 7068626 - it's noticed that we should refactor unregisgterDeploy in regfx.cpp:

I'd suggest to structure code differently like:
    if (checkIfOurBinariesAreRegisteredFroDeploy()) {
        if (hadShadowedJRE()) {

For reregister logic we can refactor registerDeploy() to extract function that will register everything given
root directory. Then we can use it for reregister and registerDeploy() to avoid replicating the code
to reconstruct registry keys?

EVALUATION 1) remove/clean some dead code 2) right now we create/remove HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\JavaFX\2.0.0 key in registerDeploy/unregisgterDeploy; should be done in FX installer instead. ( http://javafx-jira.kenai.com/browse/RT-16934 - will work on that tomorrow for FX 2.0.2) test: manual test to make sure fxreg -register/unregister works

EVALUATION I still think refactoring may be helpful (not blocker though) as we will need to update this code once we resolve problemwith upgrading DT when installing from DT. Then we may have registry pointing into JRE for deployJava1.dll, etc. and they also need to be corrected. So, soon it will be more tan 2 keys and we will need to keep them in sync.