I2JAV11 — Java LocalStub

Summary: From IDL/Java specification (draft version 3.4 - August 9):

The remote stub must be named _<interface_name>Stub where
<interface_name> is the IDL interface name this stub is
implementing. The local stub must be named _<interface_name>LocalStub
where <interface_name> is the same IDL interface name. Local stubs
are defined to be direct subclasses of remote stubs.

and:

The _is_local() method is provided so Helper classes may determine if a
particular object is implemented by a local servant and if so create a
local stub, rather than a remote stub. This function would typically
be called from within the narrow() method of a Helper class. The
_is_local() method may only return true if the servant incarnating the
object is located in the same Java VM. The method may return false if
the servant is not local or the ORB does not support local stubs for
that particular servant. The default behavior of _is_local() is to
return false.

The design described in the specification seems to make it very difficult,
if not impossible, to do the following:

• Create a proxy that refers to some remote servant
• Upon a request to the remote servant, a LocationForward is generated that
  refers to a colocated servant.

Merge the two stub classes together as one class with as minimal impact on the APIs and performance.