Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6606277

Control panel work for new Java Plug-In

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P1
    • Resolution: Duplicate
    • Affects Version/s: 6u5
    • Fix Version/s: None
    • Component/s: deploy
    • Labels:
    • Subcomponent:
    • Introduced In Build:
      b08
    • Introduced In Version:
    • CPU:
      generic
    • OS:
      windows

      Description

      At least for one release, both the old and new Java Plug-Ins will be
      shipped side by side in order to have a safety net in case of
      significant incompatibilities. We need a mechanism to toggle between
      the usage of the two.

      The Java Control Panel needs to be extended with a check box like "Use
      New Java Plug-In for Running Applets". When this check box's value is
      changed and either "Apply" or "OK" selected:

      1. If the check box is enabled:

      1a. The registry key settings associated with the Java Plug-In need to
      be updated. All CLSIDs that currently point to ssv.dll need to be
      updated to point to jp2iexp.dll. ssv.dll needs to be unregistered as a
      browser helper object and the new browser helper object for the new
      plugin needs to be registered.

      1b. All DLLs associated with the old OJI-based Java Plug-In for
      Firefox need to be deleted from the jre/bin directory. Currently the
      thinking is to have a new directory like jre/bin/unused_plugin which
      contains all of the Mozilla-specific DLLs associated with both the old
      and the new Java Plug-Ins. The DLLs associated with the selected
      plugin would be copied from jre/bin/unused_plugin into jre/bin and the
      DLLs associated with the unselected plugin would be deleted from
      jre/bin.

      The DLLs associated with the old plugin that need to be removed when
      the new one is in use include:

        jpinscp.dll
        jpioji.dll
        npjava*.dll
        npjpi160_05.dll
        npoji610.dll

      The DLL associated with the new plugin that needs to be copied into
      jre/bin is:

        npjp2.dll

      2. If the check box is disabled:

      2a. The registry key settings need to be reverted back to the way they
      currently are (ssv.dll registered for all CLSIDs, and as the browser
      helper object).

      2b. The DLL associated with the Firefox implementation of the new Java
      Plug-In needs to be removed from jre/bin and the DLLs associated with
      the old OJI-based plugin need to be copied from jre/bin/unused_plugin
      into jre/bin. See 1b, above, for the list of these DLLs.

      On Unix platforms we would ideally switch the symlink in the Mozilla /
      Firefox plugin directory from the old plugin to the new plugin. I
      don't know what we currently do in this area. From talking with the
      engineers at Mozilla.org, it sounds like we should probably be
      installing a symlink in ~/.mozilla/plugins/ rather than the global
      plugins directory.
      As of the fix for 6606271, cleanups are needed in make/common/Release.gmk, make/plugin/ssv/Makefile, and RegInstall.cpp. Currently ssv.dll is being built into the unused_plugin directory, but both ssv.dll and jp2ssv.dll will have to always live side-by-side and be registered, and one will need to skip doing its work based on the value of the control panel switch. The uninstaller needs to be modified to see whether the version we are downgrading to supports the new plug-in and, if so, to register jp2ssv.dll alongside ssv.dll from the previous release.
      The control panel code should invoke the new jp2ssvbroker.exe to do the work of switching between the old and the new plugin. This broker process should be changed to accept some command line argument like -old or -new to indicate what sort of work it should do. It should attempt to do the work, and return a nonzero status code (and have no side-effects) if it was unable to do so, for example because a browser was open and had one of the DLLs locked. The control panel code should receive this status code and present options to the user to retry, etc.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                ccheung Calvin Cheung
                Reporter:
                kbr Kenneth Russell (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: