Issue 6411: Custom marshalled abstract interfaces and Java/IDL (java2idl-rtf) Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com) Nature: Uncategorized Issue Severity: Summary: We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says: "Other Java objects are marshaled in the form of an IDL abstract interface (i.e., a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false)." However, the Java/IDL spec does not mandate that _all_ Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2. Clarification appreciated Resolution: Revised Text: Actions taken: November 3, 2003: received issue July 30, 2007: closed issue Discussion: Closed as duplicate of issue 6410. End of Annotations:===== ender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 03 Nov 2003 11:31:54 -0800 To: issues@omg.org, cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org From: Andy Piper Subject: Custom marshalled abstract interfaces and Java/IDL Cc: little@bea.com We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says: "Other Java objects are marshaled in the form of an IDL abstract interface (i.e., a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false)." However, the Java/IDL spec does not mandate that _all_ Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2. Clarification appreciated. andy X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 03 Nov 2003 12:43:29 -0800 To: Jonathan Biggar From: Andy Piper Subject: Re: Custom marshalled abstract interfaces and Java/IDL Cc: cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com At 12:37 PM 11/3/2003 -0800, Jonathan Biggar wrote: This looks like a problem only in the Java to IDL mapping to me. Do you mean that you believe the expected behavior is precluded by the CORBA spec? andy Date: Mon, 03 Nov 2003 12:58:20 -0800 From: Jonathan Biggar Organization: LinuxCare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: Andy Piper CC: cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Subject: Re: Custom marshalled abstract interfaces and Java/IDL Andy Piper wrote: At 12:37 PM 11/3/2003 -0800, Jonathan Biggar wrote: This looks like a problem only in the Java to IDL mapping to me. Do you mean that you believe the expected behavior is precluded by the CORBA spec? The Java to IDL spec is mandating that objects of this variety be marshaled as if they were derived from AbstractBase, but the generated IDL doesn't in fact use that derivation. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 03 Nov 2003 12:37:33 -0800 From: Jonathan Biggar Organization: LinuxCare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: Andy Piper CC: issues@omg.org, cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Subject: Re: Custom marshalled abstract interfaces and Java/IDL Andy Piper wrote: We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says: "Other Java objects are marshaled in the form of an IDL abstract interface (i.e., a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false)." However, the Java/IDL spec does not mandate that _all_ Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2. Clarification appreciated. This looks like a problem only in the Java to IDL mapping to me. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org te: Mon, 03 Nov 2003 21:40:58 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Andy Piper CC: cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Subject: Re: Custom marshalled abstract interfaces and Java/IDL Andy, These objects are marshalled using the same wire format as IDL abstract interfaces. They are NOT abstract interfaces, and cannot be read by methods designed to read abstract interfaces. Perhaps the following rewording of this spec sentence would be clearer: "Other Java objects are marshaled in the form of a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false." Simon Andy Piper wrote: > > We currently are having a problem implementing abstract interface behaviour > in C++ for valuetypes marshaled according to the Java/IDL spec. For custom > marshaled objects the spec says: > > "Other Java objects are marshaled in the form of an > IDL abstract interface (i.e., a union with a boolean discriminator > containing either an > object reference if the discriminator is true or a value type if the > discriminator is false)." > > However, the Java/IDL spec does not mandate that _all_ Java objects of this > type be mapped to IDL that has an abstract interface as a supertype. Thus > we are left in the position for IDL that objects marshaled as abstract > interfaces are not truly abstract interfaces as defined in the CORBA spec > section 6.2. Moreover the generated C++ for these types will not include > inheritance from AbstractBase, so how should these types be handled? In > particular should DataInputStream::read_Abstract() work at all for these > types? You could imagine making this work by having read_Abstract() return > some container class that held the actual object (valuetype or object > reference), but its not clear that this is actual legal wrt 6.2. > > Clarification appreciated. > > andy -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 03 Nov 2003 14:43:30 -0800 To: Simon Nash From: Andy Piper Subject: Re: Custom marshalled abstract interfaces and Java/IDL Cc: cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Hi Simon, At 09:40 PM 11/3/2003 +0000, Simon Nash wrote: These objects are marshalled using the same wire format as IDL abstract interfaces. They are NOT abstract interfaces, and cannot be read by methods designed to read abstract interfaces. Perhaps the following rewording of this spec sentence would be clearer: "Other Java objects are marshaled in the form of a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false." I can see the logic in this. Its unfortunate that things like Util.writeAbstractObject() make explicit reference to write_abstract_interface(). I don't know whether we should consider cleaning up all of this sort of documentation. One could consider actually making this work by introducing the idea of an "anonymous abstract" in the CORBA spec whereby it would be legal to pass any object reference or valuetype into a signature declared using AbstractBase (and vice versa). One could then make to_object() and to_value() in the C++ mapping do the right thing and introduce some notion of insertion. This does bring up a more philosophical question though - why was java.lang.Object mapped to an any in the first place? Why not AbstractBase? That would have made a lot of these problems moot and made custom marshaling consistent with standard marshalling. andy Date: Tue, 04 Nov 2003 17:48:43 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Andy Piper CC: cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Subject: Re: Custom marshalled abstract interfaces and Java/IDL Andy, Util.writeAbstractObject() is provided for use by stubs to write abstract interface types to a stream. These are genuine IDL abstract interface types (as described in section 1.3.11) that can be read as abstract interface types from other languages. If an RMI-IIOP implementation happens to reuse this method as a convenient means of implementing custom marshalling of Java objects, that is an internal detail of the implementation and is not the business of the specification. To move on to your "why" question, we could have mapped java.lang.Object to AbstractBase but this would have required all other Java object types to be mapped to IDL types that inherit from some IDL abstract interface (JavaToIDLBase?), since only IDL types that inherit from some IDL abstract interface type would be valid values for an IDL AbstractBase signature type. This would have violated the goal of making the Java to IDL mapping simple for simple cases, so that a simple RMI remote interface maps to a simple IDL interface that doesn't parade its RMI-IIOP origins. With hindsight and knowledge of the performance issues associated with CORBA "any"s, this slight ugliness in the generated IDL might have been a good trade-off, but it's always easier to get these things right with 20-20 hindsight. Simon Andy Piper wrote: > > Hi Simon, > > At 09:40 PM 11/3/2003 +0000, Simon Nash wrote: > >These objects are marshalled using the same wire format as IDL > >abstract interfaces. They are NOT abstract interfaces, and > >cannot be read by methods designed to read abstract interfaces. > >Perhaps the following rewording of this spec sentence would > >be clearer: > > "Other Java objects are marshaled in the form of a union with a > > boolean discriminator containing either an object reference if > > the discriminator is true or a value type if the discriminator > > is false." > > I can see the logic in this. Its unfortunate that things like > Util.writeAbstractObject() make explicit reference to > write_abstract_interface(). > I don't know whether we should consider cleaning up all of this sort of > documentation. One could consider actually making this work by introducing > the idea of an "anonymous abstract" in the CORBA spec whereby it would be > legal to pass any object reference or valuetype into a signature declared > using AbstractBase (and vice versa). One could then make to_object() and > to_value() in the C++ mapping do the right thing and introduce some notion > of insertion. > > This does bring up a more philosophical question though - why was > java.lang.Object mapped to an any in the first place? Why not AbstractBase? > That would have made a lot of these problems moot and made custom > marshaling consistent with standard marshalling. > > andy -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Tue, 04 Nov 2003 18:19:06 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Jonathan Biggar CC: Andy Piper , cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Subject: Re: Custom marshalled abstract interfaces and Java/IDL Jonathan, This is not a problem with the Java to IDL spec. Just because an object of kind X is marshalled using the same bits on the wire as an object of kind Y, this is not the same as saying that an object of kind X is semantically or operationally equivalent to an object of kind Y. But to clarify this beyond all possible doubt, I am OK with changing this sentence in the Java to IDL spec to remove all mention of abstract interfaces. Simon Jonathan Biggar wrote: > > Andy Piper wrote: > > > At 12:37 PM 11/3/2003 -0800, Jonathan Biggar wrote: > > > >> This looks like a problem only in the Java to IDL mapping to me. > > > > > > Do you mean that you believe the expected behavior is precluded by the > > CORBA spec? > > The Java to IDL spec is mandating that objects of this variety be > marshaled as if they were derived from AbstractBase, but the generated > IDL doesn't in fact use that derivation. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 X-Sender: andyp:san-francisco.beasys.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 17 Nov 2003 19:58:53 -0800 To: Simon Nash From: Andy Piper Subject: Re: Custom marshalled abstract interfaces and Java/IDL Cc: cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Thanks for the clarification andy At 05:48 PM 11/4/2003 +0000, Simon Nash wrote: Util.writeAbstractObject() is provided for use by stubs to write abstract interface types to a stream. These are genuine IDL abstract interface types (as described in section 1.3.11) that can be read as abstract interface types from other languages. If an RMI-IIOP implementation happens to reuse this method as a convenient means of implementing custom marshalling of Java objects, that is an internal detail of the implementation and is not the business of the specification. To move on to your "why" question, we could have mapped java.lang.Object to AbstractBase but this would have required all other Java object types to be mapped to IDL types that inherit from some IDL abstract interface (JavaToIDLBase?), since only IDL types that inherit from some IDL abstract interface type would be valid values for an IDL AbstractBase signature type. This would have violated the goal of making the Java to IDL mapping simple for simple cases, so that a simple RMI remote interface maps to a simple IDL interface that doesn't parade its RMI-IIOP origins. With hindsight and knowledge of the performance issues associated with CORBA "any"s, this slight ugliness in the generated IDL might have been a good trade-off, but it's always easier to get these things right with 20-20 hindsight. Date: Wed, 19 Nov 2003 10:29:06 -0800 From: Jonathan Biggar Organization: LinuxCare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en To: Todd Little CC: Simon Nash , Andy Piper , cxx_revision@omg.org, corba-rtf@omg.org, java2idl-rtf@omg.org, little@bea.com Subject: Re: Custom marshaled abstract interfaces and Java/IDL Todd Little wrote: I'm still not sure I understand exactly what a C++ implementation is supposed to do with this. If the state of the object is declared as being something that maps to a valuetype, why would it get encoded in a manner that allows an object reference to be encoded? What should a compliant C++ implementation do if it receives an object reference when its state definition is for a valuetype? If I understand the issue now, these are all custom valuetypes. As such, a C++ implementation of the valuetype will need to implement the CustomMarshal valuetype signature. Then it is usercode that handles the marshal/unmarshal duties, and that usercode does what it must. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org