I2JAV11 — Updated proposal for the OBV Java mapping

Summary: updated proposal for the OBV Java mapping which addresses
a number of issues which have been raised by us and others. This
proposal is based on a number of discussions and previous proposals
and current OMG submissions (thanks to Simon Nash and Bernard
Normier). As with previous poposals, these are not currently formal
proposals, just working drafts.

Here are the current issues:

1. Java valuetypes cannot unmarshal recursive references to themselves.
This is the same problem that occurs with custom valuetypes.

2. The current language mapping mixes both generated code with user
written code in the same source file. This poses a very complex "tool"
issue for IDL compilers which is unnecessarily complex.

3. Java valuetypes need a way to unmarshal the state of their base class.

4. The addition of the new Helper interface adds ~400 bytes to every
Helper class, of which there are about 250 in a typical ORB implementation.
Which is an overhead of about 100k just to support an optimization of
a corner case in RMI/IIOP where an RMI type happens to contain an IDL type.
This doesn"t even begin to address the bloat that would occur to user code
as well as any additional CORBA services. The space/time tradeoff here
appears to have gone the wrong way.

5. The ValueHelper interface contains the method get_safe_base_ids, which is
inconsistent with current OBV terminology.

6. The marshaling of boxed types should be considered carefully, because of
the special casing required for boxed strings, arrays, and sequences.

7. The compiler should provide compile time enforcement of init() declarations.

resolved, see revised text