JAV2I12 — Mapping of CORBA any and TypeCode

The Java to IDL mapping does not specify how the Java classes produced
by the forward mapping from the CORBA "any" and "TypeCode" types should
be mapped back to IDL.

Since org.omg.CORBA.Any and org.omg.CORBA.TypeCode both inherit from
IDLEntity, section 1.3.9 implies that these types should be "boxed" in
the same way as other IDLEntity types. This would imply the following
mapping to IDL:

module org {
module omg {
module boxedIDL {
module CORBA

;
};
};
};

module org {
module omg {
module boxedIDL {
module CORBA

;
};
};
};

The above raises a number of questions:

1. What is the correct IDL name for the boxed valuetype enclosing the Java "Any"
type? Is it ::org::omg::boxedIDL::CORBA::_Any or ::org::omg::boxedIDL::_any?

2. How should the hashcodes and SUIDs be computed in the above repid pragmas?
For other boxed IDLEntity Java types, these are computed from the actual
implementation classes. However, for these two types, the actual
implementation classes are ORB-specific and it seems meaningless to send
their hashcodes or SUIDs on the wire. We could either do what we do for
object references and send zeros for the hashcode and SUID, or we could
use IDL-style repids instead or RMI-style repids for these types.

3. Is it better to make these types an exception to the general rule as defined
in section 1.3.9? An alternative non-boxed mapping would be to simply map
them to the IDL/PIDL types "any" and "::CORBA::TypeCode". This would have
the drawback that RMI semantics of being able to pass nulls and maintaining
referential integrity for shared references to "by value" Java objects would
not apply to these Java types.

See revised text below.