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.