Issue 3969: Mapping of CORBA any and TypeCode (java2idl-rtf)
Source:  (Mr. Simon C. Nash, )
Nature: Uncategorized Issue
Severity: 
Summary: 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 {
valuetype _Any any;
#pragma ID Any “RMI:org.omg.CORBA.Any:xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy”
};
};
};
};

module org {
module omg {
module boxedIDL {
module CORBA {
valuetype TypeCode ::CORBA::TypeCode;
#pragma ID TypeCode “RMI:org.omg.CORBA.TypeCode:xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy”
};
};
};
};

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.

Resolution:  See revised text below.
Revised Text: Add the following to the end of section 1.3.9: 
The IDLEntity types org.omg.CORBA.Any and org.omg.CORBA.TypeCode are mapped as follows: 

module org {

module omg {

module boxedIDL {

module CORBA {

valuetype _Any any;

#pragma ID _Any “RMI:org.omg.CORBA.Any:0000000000000000”

};

};

};

};



module org {

module omg {

module boxedIDL {

module CORBA {

valuetype _TypeCode ::CORBA::TypeCode;

#pragma ID _TypeCode “RMI:org.omg.CORBA.TypeCode:0000000000000000”

};

};

};

};




Actions taken:
October 18, 2000: received issue
May 24, 2001: closed issue
Discussion: 
This resolution is being voted a second time with a minor change. The original resolution (which passed) named the mapped IDL
type as ::org::omg::boxedIDL::CORBA::_any. The amended resolution names the type as ::org::omg::boxedIDL::CORBA::_Any.
This is the only change to the original resolution. 
 
The following points are in favor of mapping org.omg.CORBA.Any and org.omg.CORBA.TypeCode to boxed IDL types: 
1. It is more consistent with the current spec, which says that all IDLEntity types are boxed, except for certain specified cases. 
2. It supports sharing semantics when passing multiple references to the same Java Any or TypeCode object across RMI-IIOP,
just like other IDLEntity and serializable objects. 

If these are mapped to boxed types, then we need to specify the repids for the boxed valuetype encoding. These would not be
derived from the Java implementation classes as they are for other IDLEntity types (e.g., RMI:com.acme.AnyImpl:hhh:sss) since
using implementation names would not be interoperable. It would seem reasonable to use 
  RMI:org.omg.CORBA.Any:0000000000000000 and 
  RMI:org.omg.CORBA.TypeCode:0000000000000000 
as the repids.
End of Annotations:=====
Date: Tue, 17 Oct 2000 20:19:13 +0100
From: Simon Nash <nash@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: issues@omg.org
CC: java2idl-rtf@omg.org
Subject: Mapping of CORBA any and TypeCode
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1
X-UIDL: h0De9>mCe90OLe9i$U!!

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 {
valuetype _Any any;
#pragma ID An y
};
};
};
};

module org {
module omg {
module boxedIDL {
module CORBA {
valuetype TypeCode ::CORBA::TypeCode;
#pragma ID TypeCod e
};
};
};
};

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.

   Simon
-- 
Simon C Nash, Technology Architect, IBM Java Technology Centre
Tel. +44-1962-815156   Fax +44-1962-818999    Hursley, England
Internet: nash@hursley.ibm.com   Lotus Notes: Simon Nash@ibmgb


Date: Tue, 14 Nov 2000 21:31:15 +0000
From: Simon Nash <nash@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: java2idl-rtf@omg.org
Subject: Issue 3969 proposed resolution
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1
X-UIDL: XJGe97=G!!5Dfd9~a>e9

I would like to place a consensus resolution for issue 3969 in vote 3
of
the Java to IDL RTF.  Here is a "straw man" to get the discussion
going.

Discussion:

The following points are in favor of mapping org.omg.CORBA.Any and
org.omg.CORBA.TypeCode to boxed IDL types.
 1. It is more consistent with the current spec, which says that all
    IDLEntity types are boxed, except for certain specified cases.
 2. It supports sharing semantics when passing multiple references to
    the same Java Any or TypeCode object across RMI-IIOP, just like
    other
    IDLEntity and serializable objects.

If these are mapped to boxed types, then we need to specify the repids
for the boxed valuetype encoding.  These would not be derived from the
Java implementation classes as they are for other IDLEntity types
(e.g.,
RMI:com.acme.AnyImpl:hhh:sss) since using implementation names would
not be interoperable.  It would seem reasonable to use
  RMI:org.omg.CORBA.Any:0000000000000000 and
  RMI:org.omg.CORBA.TypeCode:0000000000000000
as the repids.

Proposed Resolution:

Add the following to the end of section 1.3.9:

The IDLEntity types org.omg.CORBA.Any and org.omg.CORBA.TypeCode are
mapped as follows:

module org {
module omg {
module boxedIDL {
module CORBA {
valuetype _any any;
#pragma ID _an y
};
};
};
};

module org {
module omg {
module boxedIDL {
module CORBA {
valuetype _TypeCode ::CORBA::TypeCode;
#pragma ID _TypeCod e
};
};
};
};

   Simon
-- 
Simon C Nash, Technology Architect, IBM Java Technology Centre
Tel. +44-1962-815156   Fax +44-1962-818999    Hursley, England
Internet: nash@hursley.ibm.com   Lotus Notes: Simon Nash@ibmgb