Issue 3857: Descriptions of readAny and writeAny not precise enough (java2idl-rtf) Source: (Mr. Simon C. Nash, ) Nature: Uncategorized Issue Severity: Summary: The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL mapping spec are not very precise and don't say how null values should be handled. These methods are currently described in section 1.5.1.4 as follows: > The writeAny method writes the Java object obj to the output stream out in the > form of a GIOP any. The readAny method reads a GIOP any from the input stream > in and unmarshals it as a Java object, which is returned. Proposed resolution: Replace the above paragraph in section 1.5.1.4 by the following: The writeAny method writes the Java object obj to the output stream out in the form of a GIOP any. The contents of the GIOP any are determined by applying the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, then it is written as follows: the TypeCode is tk_value, the repository ID is "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value is a null valuetype (0x00000000). The readAny method reads a GIOP any from the input stream in and unmarshals it as a Java object, which is returned. The following TypeCodes are valid for the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything other than these, a MARSHAL exception is thrown. Resolution: See revised text below. Revised Text: Replace the second paragraph in section 1.5.1.4 by the following: "The writeAny method writes the Java object obj to the output stream out in the form of a GIOP any. The contents of the GIOP any are determined by applying the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, then it is written as follows: the TypeCode is tk_abstract_interface, the repository ID is "IDL:omg.org/CORBA/AbstractBase:1.0", the name string is "", and the any's value is a null abstract interface type (encoded as a boolean discriminant of false followed by a long value of 0x00000000). The readAny method reads a GIOP any from the input stream in and unmarshals it as a Java object, which is returned. The following TypeCodes are valid for the GIOP any: tk_value, tk_value_box, tk_objref, and tk_abstract_interface. For each of these types, both null and non-null values are valid. If the TypeCode is anything other than these, a MARSHAL exception is thrown." Actions taken: September 5, 2000: received issue May 24, 2001: closed issue Discussion: Using tk_value for java.lang.Object null seems incorrect because a java.lang.Object does not only contain valuetypes. Another alternative is tk_null, but this is currently used for an any with no contents rather than an any containing a null. The bext compromise appears to be tk_abstract_interface. The IDL abstract interface type can represent all the legal values of java.lang.Object in the Java to IDL mapping. Also, using this representation is consistent with the folllowing usability goals: 1. When nulls are sent from IDL to RMI-IIOP, the same insertion operations for anys that are used for non-null values should work for null values as well. This means that all the following anys when received by RMI-IIOP as the value of a java.lang.Object should be unmarshalled as null: tk_value+null tk_value_box+null tk_objref+nil tk_abstract_interface+null 2. When nulls are sent from RMI-IIOP to IDL, the encoding of null sent by RMI-IIOP should be extractable using the same extraction operations that would be used for non-null values. For example, in the IDL-to-Java mapping, both the following should work on null values sent by RMI-IIOP: myValue = myAny.extract_Value(); myObjRef = myAny.extract_Object(); So, if we say that tk_abstract_interface is the correct RMI-IIOP encoding for a null, then both extract_Value() and extract_Object() should be able to handle a null tk_abstract_interface type in the any. The same should be true for other languages. Note 1: it is not clear from either the Java language binding spec or the C++ language binding spec whether a value (not just a null value) that was inserted using a tk_abstract_interface TypeCode can be extracted using the normal extract operations for valuetype or object reference. If this does work (and there is good reason to think it should), then this would automatically take care of handling a null encoded as tk_abstract_interface. Note 2: Issues like the one described in Note 1 above should not be up to all the language mapping RTFs to resolve. The core should define semantics for anys that the language bindings are required to support. Note: (For information only) I have raised a separate issue in the IDL-to-Java RTF proposing that a value (including a null value) that was inserted into an any using a tk_abstract_interface TypeCode should be extractable using the normal extract operations for valuetype or object reference. If this passes, I will raise a similar issue in the C++ RTF End of Annotations:===== Date: Tue, 05 Sep 2000 22:53:44 +0100 From: Simon Nash 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: Descriptions of readAny and writeAny not precise enough Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6G6!!@)?e9_R~!!!!Je9 The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL mapping spec are not very precise and don't say how null values should be handled. These methods are currently described in section 1.5.1.4 as follows: > The writeAny method writes the Java object obj to the output stream out in the > form of a GIOP any. The readAny method reads a GIOP any from the input stream > in and unmarshals it as a Java object, which is returned. Proposed resolution: Replace the above paragraph in section 1.5.1.4 by the following: The writeAny method writes the Java object obj to the output stream out in the form of a GIOP any. The contents of the GIOP any are determined by applying the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, then it is written as follows: the TypeCode is tk_value, the repository ID is "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value is a null valuetype (0x00000000). The readAny method reads a GIOP any from the input stream in and unmarshals it as a Java object, which is returned. The following TypeCodes are valid for the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything other than these, a MARSHAL exception is thrown. 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: Fri, 06 Oct 2000 16:54:36 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Descriptions of readAny and writeAny not precise enough References: <39B56B68.3BE08EFB@hursley.ibm.com> <39D3EAAB.92586EEA@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: h9Sd9aVod9;YI!!ih3!! Vijay, I believe tk_null indicates a null typecode rather than a typecode with a null value. However, the CORBA spec is not very clear about the meaning of tk_null. Perhaps we should raise a Core RTF issue to clarify this. Any comments from the Core folks on the purpose of tk_null would be appreciated. Simon Vijaykumar Natarajan wrote: > > Simon, > > I don't see why that is required at all. An any is perfectly capable of dealing w/ a > null w/ no type information.If an object is null, the any can be marshaled w/ a > tk_null typecode and no data. That is a clear and accurate way of representing a null > in an > any. Why do we need to invent a new format for null? > > Vijay > > Simon Nash wrote: > > > The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL > > mapping spec are not very precise and don't say how null values should be handled. > > These methods are currently described in section 1.5.1.4 as follows: > > > > > The writeAny method writes the Java object obj to the output stream out in the > > > form of a GIOP any. The readAny method reads a GIOP any from the input stream > > > in and unmarshals it as a Java object, which is returned. > > > > Proposed resolution: > > > > Replace the above paragraph in section 1.5.1.4 by the following: > > > > The writeAny method writes the Java object obj to the output stream out in the > > form of a GIOP any. The contents of the GIOP any are determined by applying > > the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, > > then it is written as follows: the TypeCode is tk_value, the repository ID is > > "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is > > VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value > > is a null valuetype (0x00000000). > > > > The readAny method reads a GIOP any from the input stream in and unmarshals it > > as a Java object, which is returned. The following TypeCodes are valid for > > the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything > > other than these, a MARSHAL exception is thrown. > > > > 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 -- 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: Fri, 06 Oct 2000 10:00:03 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Vijaykumar Natarajan , java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Descriptions of readAny and writeAny not precise enough References: <39B56B68.3BE08EFB@hursley.ibm.com> <39D3EAAB.92586EEA@inprise.com> <39DDF5BC.95AFB707@hursley.ibm.com> Content-Type: multipart/mixed; boundary="------------D1D8F0B8B0D2B1560E13A94C" X-UIDL: L24!!T\cd9Q"i!!fSjd9 That is true, but when Util.writeAny is called with a null, we don't know the type and cannot classify it as a null value. The only information we have is a java.lang.Object which has null in it. ie. No type assumptions whatsoever. It could contain an object reference, an array, an IDL type or a value. Why would we then encode this as a null value? Vijay Simon Nash wrote: > Vijay, > I believe tk_null indicates a null typecode rather than a typecode > with > a null value. However, the CORBA spec is not very clear about the > meaning > of tk_null. Perhaps we should raise a Core RTF issue to clarify > this. > > Any comments from the Core folks on the purpose of tk_null would be > appreciated. > > Simon > > Vijaykumar Natarajan wrote: > > > > Simon, > > > > I don't see why that is required at all. An any is perfectly > capable of dealing w/ a > > null w/ no type information.If an object is null, the any can be > marshaled w/ a > > tk_null typecode and no data. That is a clear and accurate way of > representing a null > > in an > > any. Why do we need to invent a new format for null? > > > > Vijay > > > > Simon Nash wrote: > > > > > The descriptions of readAny and writeAny in section 1.5.1.4 of > the Java to IDL > > > mapping spec are not very precise and don't say how null values > should be handled. > > > These methods are currently described in section 1.5.1.4 as > follows: > > > > > > > The writeAny method writes the Java object obj to the output > stream out in the > > > > form of a GIOP any. The readAny method reads a GIOP any from > the input stream > > > > in and unmarshals it as a Java object, which is returned. > > > > > > Proposed resolution: > > > > > > Replace the above paragraph in section 1.5.1.4 by the following: > > > > > > The writeAny method writes the Java object obj to the output > stream out in the > > > form of a GIOP any. The contents of the GIOP any are > determined by applying > > > the Java to IDL mapping rules to the actual runtime type of > obj. If obj is null, > > > then it is written as follows: the TypeCode is tk_value, the > repository ID is > > > "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the > ValueModifier is > > > VM_NONE, the concrete base is tk_null, the member count is 0, > and the any's value > > > is a null valuetype (0x00000000). > > > > > > The readAny method reads a GIOP any from the input stream in > and unmarshals it > > > as a Java object, which is returned. The following TypeCodes > are valid for > > > the GIOP any: tk_value, tk_value_box, and tk_objref. If the > TypeCode is anything > > > other than these, a MARSHAL exception is thrown. > > > > > > 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 > > -- > 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 [] vijayn.vcf Date: Tue, 31 Oct 2000 18:26:10 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Descriptions of readAny and writeAny not precise enough References: <39B56B68.3BE08EFB@hursley.ibm.com> <39D3EAAB.92586EEA@inprise.com> <39DDF5BC.95AFB707@hursley.ibm.com> <39DE0513.F96035E1@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5p6e9!@4!!9;pd9Hc=!! Vijay, I think there are only four possibilities for the type (in IDL terms) of an RMI-IIOP java.lang.Object. It could be a) an object reference, b) an RMI array (which is mapped to IDL as a boxed valuetype), c) an IDL valuetype, d) an IDL abstract interface, e) some other IDL entity (which is mapped to IDL as a boxed valuetype), or f) an RMI value (which is mapped to IDL as a regular valuetype). As far as the wire encoding of a null value is concerned, cases b) c) e) and f) would be encoded as a null valuetype, a) would be encoded as a nil object reference, and d) would be encoded as a null abstract interface. This observation leads to another possibility for encoding these nulls. The abstract interface CDR type can encode either an object reference or a valuetype. The CDR spec already deals with the issue of how to encode nulls for abstract interfaces by specifying that these should be encoded as null valuetypes. This suggests that a suitable encoding for this null java.lang.Object case would be a TypeCode of tk_abstract_interface and a value of null (encoded as a boolean discriminant of false followed by a null valuetype). One issue with whatever encoding we choose is that extraction from the any would be cumbersome if it were necessary to treat null values specially. This problem can be solved by ensuring that the insertion and extraction operations for IDL anys provided by language bindings interoperate well with RMI-IIOP java.lang.Object null values. Ideally, the following should be true: 1. When nulls are sent from IDL to RMI-IIOP, the same insertion operations for anys that are used for non-null values should work for null values as well. This means that all the following anys when received by RMI-IIOP as the value of a java.lang.Object should be unmarshalled as null: tk_value+null tk_value_box+null tk_objref+nil tk_abstract_interface+null 2. When nulls are sent from RMI-IIOP to IDL, the encoding of null sent by RMI-IIOP should be extractable using the same extraction operations that would be used for non-null values. For example, in IDL/Java, both the following should work on null values sent by RMI-IIOP: myValue = myAny.extract_Value(); myObjRef = myAny.extract_Object(); So, if we say that tk_abstract_interface is the correct RMI-IIOP encoding for a null, then both extract_Value() and extract_Object() should be able to handle a null tk_abstract_interface type in the any. The same should be true for other languages. Note 1: it is not clear from either the Java language binding spec or the C++ language binding spec whether a value (not just a null value) that was inserted using a tk_abstract_interface TypeCode can be extracted using the normal extract operations for valuetype or object reference. If this does work (and I think it should), then this would automatically take care of handling nulls encoded as tk_abstract_interface. Note 2: Issues like the one described in Note 1 above should not be up to all the language mapping RTFs to resolve. The core should define semantics for anys that the language bindings are required to support. There is one more issue with my original proposal. For readAny I was proposing that the any received must be of type tk_value, tk_value_box, or tk_objref. We need to extend this to include tk_abstract_interface because of case d) above, so that RMI-IIOP can handle the case where an IDL abstract interface type is sent from another language as the value of a ::java::lang::_Object parameter. Simon Vijaykumar Natarajan wrote: > > That is true, but when Util.writeAny is called with a null, we don't know the type and > cannot classify it as a null value. The only information we have is a java.lang.Object > which has null in it. ie. No type assumptions whatsoever. It could contain an object > reference, an array, an IDL type or a value. Why would we then encode this as a null value? > > Vijay > > Simon Nash wrote: > > > Vijay, > > I believe tk_null indicates a null typecode rather than a typecode with > > a null value. However, the CORBA spec is not very clear about the meaning > > of tk_null. Perhaps we should raise a Core RTF issue to clarify this. > > > > Any comments from the Core folks on the purpose of tk_null would be appreciated. > > > > Simon > > > > Vijaykumar Natarajan wrote: > > > > > > Simon, > > > > > > I don't see why that is required at all. An any is perfectly capable of dealing w/ a > > > null w/ no type information.If an object is null, the any can be marshaled w/ a > > > tk_null typecode and no data. That is a clear and accurate way of representing a null > > > in an > > > any. Why do we need to invent a new format for null? > > > > > > Vijay > > > > > > Simon Nash wrote: > > > > > > > The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL > > > > mapping spec are not very precise and don't say how null values should be handled. > > > > These methods are currently described in section 1.5.1.4 as follows: > > > > > > > > > The writeAny method writes the Java object obj to the output stream out in the > > > > > form of a GIOP any. The readAny method reads a GIOP any from the input stream > > > > > in and unmarshals it as a Java object, which is returned. > > > > > > > > Proposed resolution: > > > > > > > > Replace the above paragraph in section 1.5.1.4 by the following: > > > > > > > > The writeAny method writes the Java object obj to the output stream out in the > > > > form of a GIOP any. The contents of the GIOP any are determined by applying > > > > the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, > > > > then it is written as follows: the TypeCode is tk_value, the repository ID is > > > > "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is > > > > VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value > > > > is a null valuetype (0x00000000). > > > > > > > > The readAny method reads a GIOP any from the input stream in and unmarshals it > > > > as a Java object, which is returned. The following TypeCodes are valid for > > > > the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything > > > > other than these, a MARSHAL exception is thrown. > > > > > > > > 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 > > > > -- > > 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 -- 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: Wed, 01 Nov 2000 12:12:39 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Vijaykumar Natarajan , java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Descriptions of readAny and writeAny not precise enough References: <39B56B68.3BE08EFB@hursley.ibm.com> <39D3EAAB.92586EEA@inprise.com> <39DDF5BC.95AFB707@hursley.ibm.com> <39DE0513.F96035E1@inprise.com> <39FF0EC2.8A4CE62F@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: U< Vijay, > I think there are only four possibilities for the type (in IDL > terms) of > an RMI-IIOP java.lang.Object. It could be > a) an object reference, > b) an RMI array (which is mapped to IDL as a boxed valuetype), > c) an IDL valuetype, > d) an IDL abstract interface, > e) some other IDL entity (which is mapped to IDL as a boxed > valuetype), or > f) an RMI value (which is mapped to IDL as a regular valuetype). > > As far as the wire encoding of a null value is concerned, cases b) > c) e) > and f) would be encoded as a null valuetype, a) would be encoded as > a nil > object reference, and d) would be encoded as a null abstract > interface. > > This observation leads to another possibility for encoding these > nulls. > The abstract interface CDR type can encode either an object > reference or > a valuetype. The CDR spec already deals with the issue of how to > encode > nulls for abstract interfaces by specifying that these should be > encoded > as null valuetypes. This suggests that a suitable encoding for this > null > java.lang.Object case would be a TypeCode of tk_abstract_interface > and a > value of null (encoded as a boolean discriminant of false followed > by > a null valuetype). > > One issue with whatever encoding we choose is that extraction from > the any > would be cumbersome if it were necessary to treat null values > specially. > This problem can be solved by ensuring that the insertion and > extraction > operations for IDL anys provided by language bindings interoperate > well > with RMI-IIOP java.lang.Object null values. Ideally, the following > should > be true: > > 1. When nulls are sent from IDL to RMI-IIOP, the same insertion > operations > for anys that are used for non-null values should work for null > values > as well. This means that all the following anys when received by > RMI-IIOP > as the value of a java.lang.Object should be unmarshalled as > null: > tk_value+null > tk_value_box+null > tk_objref+nil > tk_abstract_interface+null > > 2. When nulls are sent from RMI-IIOP to IDL, the encoding of null > sent by > RMI-IIOP should be extractable using the same extraction > operations > that would be used for non-null values. For example, in > IDL/Java, both > the following should work on null values sent by RMI-IIOP: > myValue = myAny.extract_Value(); > myObjRef = myAny.extract_Object(); > So, if we say that tk_abstract_interface is the correct RMI-IIOP > encoding > for a null, then both extract_Value() and extract_Object() should > be able > to handle a null tk_abstract_interface type in the any. The same > should > be true for other languages. > > Note 1: it is not clear from either the Java language binding > spec or the > C++ language binding spec whether a value (not just a null value) > that was > inserted using a tk_abstract_interface TypeCode can be extracted > using the > normal extract operations for valuetype or object reference. If > this does > work (and I think it should), then this would automatically take > care of > handling nulls encoded as tk_abstract_interface. > > Note 2: Issues like the one described in Note 1 above should not > be up to > all the language mapping RTFs to resolve. The core should define > semantics > for anys that the language bindings are required to support. > > There is one more issue with my original proposal. For readAny I > was proposing > that the any received must be of type tk_value, tk_value_box, or > tk_objref. > We need to extend this to include tk_abstract_interface because of > case d) > above, so that RMI-IIOP can handle the case where an IDL abstract > interface type > is sent from another language as the value of a > ::java::lang::_Object parameter. > > Simon > > Vijaykumar Natarajan wrote: > > > > That is true, but when Util.writeAny is called with a null, we > don't know the type and > > cannot classify it as a null value. The only information we have > is a java.lang.Object > > which has null in it. ie. No type assumptions whatsoever. It could > contain an object > > reference, an array, an IDL type or a value. Why would we then > encode this as a null value? > > > > Vijay > > > > Simon Nash wrote: > > > > > Vijay, > > > I believe tk_null indicates a null typecode rather than a > typecode with > > > a null value. However, the CORBA spec is not very clear about > the meaning > > > of tk_null. Perhaps we should raise a Core RTF issue to clarify > this. > > > > > > Any comments from the Core folks on the purpose of tk_null would > be appreciated. > > > > > > Simon > > > > > > Vijaykumar Natarajan wrote: > > > > > > > > Simon, > > > > > > > > I don't see why that is required at all. An any is perfectly > capable of dealing w/ a > > > > null w/ no type information.If an object is null, the any can > be marshaled w/ a > > > > tk_null typecode and no data. That is a clear and accurate way > of representing a null > > > > in an > > > > any. Why do we need to invent a new format for null? > > > > > > > > Vijay > > > > > > > > Simon Nash wrote: > > > > > > > > > The descriptions of readAny and writeAny in section 1.5.1.4 > of the Java to IDL > > > > > mapping spec are not very precise and don't say how null > values should be handled. > > > > > These methods are currently described in section 1.5.1.4 as > follows: > > > > > > > > > > > The writeAny method writes the Java object obj to the > output stream out in the > > > > > > form of a GIOP any. The readAny method reads a GIOP any > from the input stream > > > > > > in and unmarshals it as a Java object, which is returned. > > > > > > > > > > Proposed resolution: > > > > > > > > > > Replace the above paragraph in section 1.5.1.4 by the > following: > > > > > > > > > > The writeAny method writes the Java object obj to the > output stream out in the > > > > > form of a GIOP any. The contents of the GIOP any are > determined by applying > > > > > the Java to IDL mapping rules to the actual runtime type of > obj. If obj is null, > > > > > then it is written as follows: the TypeCode is tk_value, > the repository ID is > > > > > "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", > the ValueModifier is > > > > > VM_NONE, the concrete base is tk_null, the member count is > 0, and the any's value > > > > > is a null valuetype (0x00000000). > > > > > > > > > > The readAny method reads a GIOP any from the input stream > in and unmarshals it > > > > > as a Java object, which is returned. The following > TypeCodes are valid for > > > > > the GIOP any: tk_value, tk_value_box, and tk_objref. If > the TypeCode is anything > > > > > other than these, a MARSHAL exception is thrown. > > > > > > > > > > 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 > > > > > > -- > > > 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 > > -- > 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: Thu, 02 Nov 2000 18:04:32 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: java2idl-rtf@omg.org, orb_revision@omg.org Subject: Re: Descriptions of readAny and writeAny not precise enough References: <39B56B68.3BE08EFB@hursley.ibm.com> <39D3EAAB.92586EEA@inprise.com> <39DDF5BC.95AFB707@hursley.ibm.com> <39DE0513.F96035E1@inprise.com> <39FF0EC2.8A4CE62F@hursley.ibm.com> <3A007937.AE628A37@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 97d!!!,0!!)gZd9k4md9 Viajy, The problems with using tk_null are: 1. It fails to distinguish between an any with no value and an any with a null value. 2. It won't work transparently when extracting RMI-IIOP nulls in IDL (see point 2 in my note). Every extraction call will need to be preceded by a separate test to see if the type of the any is tk_null before doing the extraction. With my proposal, the extraction operation can handle the null case itself. 3. Even if tk_null were used by writeAny, readAny would still have to accept all the other forms of null, including the one for tk_abstract_interface (see point 1 in my note). Therefore using tk_null requires extra code in readAny to be able to handle receiving a tk_null. Simon Vijaykumar Natarajan wrote: > > Simon, > > I still don't understand. Why take such a complex approach when a null can be very succinctly > represented as a tk_null. It is far more compact than any of these other things anyway and can > reasonably deal with all the cases described by you. What is your issue with using tk_null. How > does it break anything? > > Vijay > > Simon Nash wrote: > > > Vijay, > > I think there are only four possibilities for the type (in IDL terms) of > > an RMI-IIOP java.lang.Object. It could be > > a) an object reference, > > b) an RMI array (which is mapped to IDL as a boxed valuetype), > > c) an IDL valuetype, > > d) an IDL abstract interface, > > e) some other IDL entity (which is mapped to IDL as a boxed valuetype), or > > f) an RMI value (which is mapped to IDL as a regular valuetype). > > > > As far as the wire encoding of a null value is concerned, cases b) c) e) > > and f) would be encoded as a null valuetype, a) would be encoded as a nil > > object reference, and d) would be encoded as a null abstract interface. > > > > This observation leads to another possibility for encoding these nulls. > > The abstract interface CDR type can encode either an object reference or > > a valuetype. The CDR spec already deals with the issue of how to encode > > nulls for abstract interfaces by specifying that these should be encoded > > as null valuetypes. This suggests that a suitable encoding for this null > > java.lang.Object case would be a TypeCode of tk_abstract_interface and a > > value of null (encoded as a boolean discriminant of false followed by > > a null valuetype). > > > > One issue with whatever encoding we choose is that extraction from the any > > would be cumbersome if it were necessary to treat null values specially. > > This problem can be solved by ensuring that the insertion and extraction > > operations for IDL anys provided by language bindings interoperate well > > with RMI-IIOP java.lang.Object null values. Ideally, the following should > > be true: > > > > 1. When nulls are sent from IDL to RMI-IIOP, the same insertion operations > > for anys that are used for non-null values should work for null values > > as well. This means that all the following anys when received by RMI-IIOP > > as the value of a java.lang.Object should be unmarshalled as null: > > tk_value+null > > tk_value_box+null > > tk_objref+nil > > tk_abstract_interface+null > > > > 2. When nulls are sent from RMI-IIOP to IDL, the encoding of null sent by > > RMI-IIOP should be extractable using the same extraction operations > > that would be used for non-null values. For example, in IDL/Java, both > > the following should work on null values sent by RMI-IIOP: > > myValue = myAny.extract_Value(); > > myObjRef = myAny.extract_Object(); > > So, if we say that tk_abstract_interface is the correct RMI-IIOP encoding > > for a null, then both extract_Value() and extract_Object() should be able > > to handle a null tk_abstract_interface type in the any. The same should > > be true for other languages. > > > > Note 1: it is not clear from either the Java language binding spec or the > > C++ language binding spec whether a value (not just a null value) that was > > inserted using a tk_abstract_interface TypeCode can be extracted using the > > normal extract operations for valuetype or object reference. If this does > > work (and I think it should), then this would automatically take care of > > handling nulls encoded as tk_abstract_interface. > > > > Note 2: Issues like the one described in Note 1 above should not be up to > > all the language mapping RTFs to resolve. The core should define semantics > > for anys that the language bindings are required to support. > > > > There is one more issue with my original proposal. For readAny I was proposing > > that the any received must be of type tk_value, tk_value_box, or tk_objref. > > We need to extend this to include tk_abstract_interface because of case d) > > above, so that RMI-IIOP can handle the case where an IDL abstract interface type > > is sent from another language as the value of a ::java::lang::_Object parameter. > > > > Simon > > > > Vijaykumar Natarajan wrote: > > > > > > That is true, but when Util.writeAny is called with a null, we don't know the type and > > > cannot classify it as a null value. The only information we have is a java.lang.Object > > > which has null in it. ie. No type assumptions whatsoever. It could contain an object > > > reference, an array, an IDL type or a value. Why would we then encode this as a null value? > > > > > > Vijay > > > > > > Simon Nash wrote: > > > > > > > Vijay, > > > > I believe tk_null indicates a null typecode rather than a typecode with > > > > a null value. However, the CORBA spec is not very clear about the meaning > > > > of tk_null. Perhaps we should raise a Core RTF issue to clarify this. > > > > > > > > Any comments from the Core folks on the purpose of tk_null would be appreciated. > > > > > > > > Simon > > > > > > > > Vijaykumar Natarajan wrote: > > > > > > > > > > Simon, > > > > > > > > > > I don't see why that is required at all. An any is perfectly capable of dealing w/ a > > > > > null w/ no type information.If an object is null, the any can be marshaled w/ a > > > > > tk_null typecode and no data. That is a clear and accurate way of representing a null > > > > > in an > > > > > any. Why do we need to invent a new format for null? > > > > > > > > > > Vijay > > > > > > > > > > Simon Nash wrote: > > > > > > > > > > > The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL > > > > > > mapping spec are not very precise and don't say how null values should be handled. > > > > > > These methods are currently described in section 1.5.1.4 as follows: > > > > > > > > > > > > > The writeAny method writes the Java object obj to the output stream out in the > > > > > > > form of a GIOP any. The readAny method reads a GIOP any from the input stream > > > > > > > in and unmarshals it as a Java object, which is returned. > > > > > > > > > > > > Proposed resolution: > > > > > > > > > > > > Replace the above paragraph in section 1.5.1.4 by the following: > > > > > > > > > > > > The writeAny method writes the Java object obj to the output stream out in the > > > > > > form of a GIOP any. The contents of the GIOP any are determined by applying > > > > > > the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, > > > > > > then it is written as follows: the TypeCode is tk_value, the repository ID is > > > > > > "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is > > > > > > VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value > > > > > > is a null valuetype (0x00000000). > > > > > > > > > > > > The readAny method reads a GIOP any from the input stream in and unmarshals it > > > > > > as a Java object, which is returned. The following TypeCodes are valid for > > > > > > the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything > > > > > > other than these, a MARSHAL exception is thrown. > > > > > > > > > > > > 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 > > > > > > > > -- > > > > 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 > > > > -- > > 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 -- 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:37:00 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: java2idl-rtf@omg.org Subject: Issue 3857 proposed resolution References: <39B56B68.3BE08EFB@hursley.ibm.com> <39D3EAAB.92586EEA@inprise.com> <39DDF5BC.95AFB707@hursley.ibm.com> <39DE0513.F96035E1@inprise.com> <39FF0EC2.8A4CE62F@hursley.ibm.com> <3A007937.AE628A37@inprise.com> <3A01ACB0.8BD904BF@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: YeN!!n[De9ojX!!n0$"! Vijay, Are you OK with this explanation? I would like to put a consensus proposal up for voting, if we can agree on what it should be. Simon Simon Nash wrote: > > Viajy, > The problems with using tk_null are: > 1. It fails to distinguish between an any with no value and an any with > a null value. > 2. It won't work transparently when extracting RMI-IIOP nulls in IDL > (see point 2 in my note). Every extraction call will need to be preceded > by a separate test to see if the type of the any is tk_null before doing > the extraction. With my proposal, the extraction operation can handle > the null case itself. > 3. Even if tk_null were used by writeAny, readAny would still have to accept > all the other forms of null, including the one for tk_abstract_interface > (see point 1 in my note). Therefore using tk_null requires extra code > in readAny to be able to handle receiving a tk_null. > > Simon > > Vijaykumar Natarajan wrote: > > > > Simon, > > > > I still don't understand. Why take such a complex approach when a null can be very succinctly > > represented as a tk_null. It is far more compact than any of these other things anyway and can > > reasonably deal with all the cases described by you. What is your issue with using tk_null. How > > does it break anything? > > > > Vijay > > > > Simon Nash wrote: > > > > > Vijay, > > > I think there are only four possibilities for the type (in IDL terms) of > > > an RMI-IIOP java.lang.Object. It could be > > > a) an object reference, > > > b) an RMI array (which is mapped to IDL as a boxed valuetype), > > > c) an IDL valuetype, > > > d) an IDL abstract interface, > > > e) some other IDL entity (which is mapped to IDL as a boxed valuetype), or > > > f) an RMI value (which is mapped to IDL as a regular valuetype). > > > > > > As far as the wire encoding of a null value is concerned, cases b) c) e) > > > and f) would be encoded as a null valuetype, a) would be encoded as a nil > > > object reference, and d) would be encoded as a null abstract interface. > > > > > > This observation leads to another possibility for encoding these nulls. > > > The abstract interface CDR type can encode either an object reference or > > > a valuetype. The CDR spec already deals with the issue of how to encode > > > nulls for abstract interfaces by specifying that these should be encoded > > > as null valuetypes. This suggests that a suitable encoding for this null > > > java.lang.Object case would be a TypeCode of tk_abstract_interface and a > > > value of null (encoded as a boolean discriminant of false followed by > > > a null valuetype). > > > > > > One issue with whatever encoding we choose is that extraction from the any > > > would be cumbersome if it were necessary to treat null values specially. > > > This problem can be solved by ensuring that the insertion and extraction > > > operations for IDL anys provided by language bindings interoperate well > > > with RMI-IIOP java.lang.Object null values. Ideally, the following should > > > be true: > > > > > > 1. When nulls are sent from IDL to RMI-IIOP, the same insertion operations > > > for anys that are used for non-null values should work for null values > > > as well. This means that all the following anys when received by RMI-IIOP > > > as the value of a java.lang.Object should be unmarshalled as null: > > > tk_value+null > > > tk_value_box+null > > > tk_objref+nil > > > tk_abstract_interface+null > > > > > > 2. When nulls are sent from RMI-IIOP to IDL, the encoding of null sent by > > > RMI-IIOP should be extractable using the same extraction operations > > > that would be used for non-null values. For example, in IDL/Java, both > > > the following should work on null values sent by RMI-IIOP: > > > myValue = myAny.extract_Value(); > > > myObjRef = myAny.extract_Object(); > > > So, if we say that tk_abstract_interface is the correct RMI-IIOP encoding > > > for a null, then both extract_Value() and extract_Object() should be able > > > to handle a null tk_abstract_interface type in the any. The same should > > > be true for other languages. > > > > > > Note 1: it is not clear from either the Java language binding spec or the > > > C++ language binding spec whether a value (not just a null value) that was > > > inserted using a tk_abstract_interface TypeCode can be extracted using the > > > normal extract operations for valuetype or object reference. If this does > > > work (and I think it should), then this would automatically take care of > > > handling nulls encoded as tk_abstract_interface. > > > > > > Note 2: Issues like the one described in Note 1 above should not be up to > > > all the language mapping RTFs to resolve. The core should define semantics > > > for anys that the language bindings are required to support. > > > > > > There is one more issue with my original proposal. For readAny I was proposing > > > that the any received must be of type tk_value, tk_value_box, or tk_objref. > > > We need to extend this to include tk_abstract_interface because of case d) > > > above, so that RMI-IIOP can handle the case where an IDL abstract interface type > > > is sent from another language as the value of a ::java::lang::_Object parameter. > > > > > > Simon > > > > > > Vijaykumar Natarajan wrote: > > > > > > > > That is true, but when Util.writeAny is called with a null, we don't know the type and > > > > cannot classify it as a null value. The only information we have is a java.lang.Object > > > > which has null in it. ie. No type assumptions whatsoever. It could contain an object > > > > reference, an array, an IDL type or a value. Why would we then encode this as a null value? > > > > > > > > Vijay > > > > > > > > Simon Nash wrote: > > > > > > > > > Vijay, > > > > > I believe tk_null indicates a null typecode rather than a typecode with > > > > > a null value. However, the CORBA spec is not very clear about the meaning > > > > > of tk_null. Perhaps we should raise a Core RTF issue to clarify this. > > > > > > > > > > Any comments from the Core folks on the purpose of tk_null would be appreciated. > > > > > > > > > > Simon > > > > > > > > > > Vijaykumar Natarajan wrote: > > > > > > > > > > > > Simon, > > > > > > > > > > > > I don't see why that is required at all. An any is perfectly capable of dealing w/ a > > > > > > null w/ no type information.If an object is null, the any can be marshaled w/ a > > > > > > tk_null typecode and no data. That is a clear and accurate way of representing a null > > > > > > in an > > > > > > any. Why do we need to invent a new format for null? > > > > > > > > > > > > Vijay > > > > > > > > > > > > Simon Nash wrote: > > > > > > > > > > > > > The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL > > > > > > > mapping spec are not very precise and don't say how null values should be handled. > > > > > > > These methods are currently described in section 1.5.1.4 as follows: > > > > > > > > > > > > > > > The writeAny method writes the Java object obj to the output stream out in the > > > > > > > > form of a GIOP any. The readAny method reads a GIOP any from the input stream > > > > > > > > in and unmarshals it as a Java object, which is returned. > > > > > > > > > > > > > > Proposed resolution: > > > > > > > > > > > > > > Replace the above paragraph in section 1.5.1.4 by the following: > > > > > > > > > > > > > > The writeAny method writes the Java object obj to the output stream out in the > > > > > > > form of a GIOP any. The contents of the GIOP any are determined by applying > > > > > > > the Java to IDL mapping rules to the actual runtime type of obj. If obj is null, > > > > > > > then it is written as follows: the TypeCode is tk_value, the repository ID is > > > > > > > "IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is > > > > > > > VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value > > > > > > > is a null valuetype (0x00000000). > > > > > > > > > > > > > > The readAny method reads a GIOP any from the input stream in and unmarshals it > > > > > > > as a Java object, which is returned. The following TypeCodes are valid for > > > > > > > the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything > > > > > > > other than these, a MARSHAL exception is thrown. > > > > > > > > > > > > > > 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 > > > > > > > > > > -- > > > > > 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 > > > > > > -- > > > 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 > > -- > 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 -- 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 19:38:27 -0800 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Vijaykumar Natarajan , java2idl-rtf@omg.org Subject: Re: Issue 3857 proposed resolution References: <39B56B68.3BE08EFB@hursley.ibm.com> <39D3EAAB.92586EEA@inprise.com> <39DDF5BC.95AFB707@hursley.ibm.com> <39DE0513.F96035E1@inprise.com> <39FF0EC2.8A4CE62F@hursley.ibm.com> <3A007937.AE628A37@inprise.com> <3A01ACB0.8BD904BF@hursley.ibm.com> <3A11B07C.9C0ADAE4@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pZm!!H[A!!?Zpd9C5a!! I see your point. Let's stick w/ your proposal. Thanks, Vijay Simon Nash wrote: > Vijay, > Are you OK with this explanation? I would like to put a consensus > proposal > up for voting, if we can agree on what it should be. > > Simon > > Simon Nash wrote: > > > > Viajy, > > The problems with using tk_null are: > > 1. It fails to distinguish between an any with no value and an > any with > > a null value. > > 2. It won't work transparently when extracting RMI-IIOP nulls in > IDL > > (see point 2 in my note). Every extraction call will need to > be preceded > > by a separate test to see if the type of the any is tk_null > before doing > > the extraction. With my proposal, the extraction operation > can handle > > the null case itself. > > 3. Even if tk_null were used by writeAny, readAny would still > have to accept > > all the other forms of null, including the one for > tk_abstract_interface > > (see point 1 in my note). Therefore using tk_null requires > extra code > > in readAny to be able to handle receiving a tk_null. > > > > Simon > > > > Vijaykumar Natarajan wrote: > > > > > > Simon, > > > > > > I still don't understand. Why take such a complex approach when > a null can be very succinctly > > > represented as a tk_null. It is far more compact than any of > these other things anyway and can > > > reasonably deal with all the cases described by you. What is > your issue with using tk_null. How > > > does it break anything? > > > > > > Vijay > > > > > > Simon Nash wrote: > > > > > > > Vijay, > > > > I think there are only four possibilities for the type (in IDL > terms) of > > > > an RMI-IIOP java.lang.Object. It could be > > > > a) an object reference, > > > > b) an RMI array (which is mapped to IDL as a boxed > valuetype), > > > > c) an IDL valuetype, > > > > d) an IDL abstract interface, > > > > e) some other IDL entity (which is mapped to IDL as a boxed > valuetype), or > > > > f) an RMI value (which is mapped to IDL as a regular > valuetype). > > > > > > > > As far as the wire encoding of a null value is concerned, > cases b) c) e) > > > > and f) would be encoded as a null valuetype, a) would be > encoded as a nil > > > > object reference, and d) would be encoded as a null abstract > interface. > > > > > > > > This observation leads to another possibility for encoding > these nulls. > > > > The abstract interface CDR type can encode either an object > reference or > > > > a valuetype. The CDR spec already deals with the issue of how > to encode > > > > nulls for abstract interfaces by specifying that these should > be encoded > > > > as null valuetypes. This suggests that a suitable encoding > for this null > > > > java.lang.Object case would be a TypeCode of > tk_abstract_interface and a > > > > value of null (encoded as a boolean discriminant of false > followed by > > > > a null valuetype). > > > > > > > > One issue with whatever encoding we choose is that extraction > from the any > > > > would be cumbersome if it were necessary to treat null values > specially. > > > > This problem can be solved by ensuring that the insertion and > extraction > > > > operations for IDL anys provided by language bindings > interoperate well > > > > with RMI-IIOP java.lang.Object null values. Ideally, the > following should > > > > be true: > > > > > > > > 1. When nulls are sent from IDL to RMI-IIOP, the same > insertion operations > > > > for anys that are used for non-null values should work for > null values > > > > as well. This means that all the following anys when > received by RMI-IIOP > > > > as the value of a java.lang.Object should be unmarshalled > as null: > > > > tk_value+null > > > > tk_value_box+null > > > > tk_objref+nil > > > > tk_abstract_interface+null > > > > > > > > 2. When nulls are sent from RMI-IIOP to IDL, the encoding of > null sent by > > > > RMI-IIOP should be extractable using the same extraction > operations > > > > that would be used for non-null values. For example, in > IDL/Java, both > > > > the following should work on null values sent by RMI-IIOP: > > > > myValue = myAny.extract_Value(); > > > > myObjRef = myAny.extract_Object(); > > > > So, if we say that tk_abstract_interface is the correct > RMI-IIOP encoding > > > > for a null, then both extract_Value() and extract_Object() > should be able > > > > to handle a null tk_abstract_interface type in the any. > The same should > > > > be true for other languages. > > > > > > > > Note 1: it is not clear from either the Java language > binding spec or the > > > > C++ language binding spec whether a value (not just a null > value) that was > > > > inserted using a tk_abstract_interface TypeCode can be > extracted using the > > > > normal extract operations for valuetype or object > reference. If this does > > > > work (and I think it should), then this would automatically > take care of > > > > handling nulls encoded as tk_abstract_interface. > > > > > > > > Note 2: Issues like the one described in Note 1 above > should not be up to > > > > all the language mapping RTFs to resolve. The core should > define semantics > > > > for anys that the language bindings are required to > support. > > > > > > > > There is one more issue with my original proposal. For > readAny I was proposing > > > > that the any received must be of type tk_value, tk_value_box, > or tk_objref. > > > > We need to extend this to include tk_abstract_interface > because of case d) > > > > above, so that RMI-IIOP can handle the case where an IDL > abstract interface type > > > > is sent from another language as the value of a > ::java::lang::_Object parameter. > > > > > > > > Simon > > > > > > > > Vijaykumar Natarajan wrote: > > > > > > > > > > That is true, but when Util.writeAny is called with a null, > we don't know the type and > > > > > cannot classify it as a null value. The only information we > have is a java.lang.Object > > > > > which has null in it. ie. No type assumptions whatsoever. It > could contain an object > > > > > reference, an array, an IDL type or a value. Why would we > then encode this as a null value? > > > > > > > > > > Vijay > > > > > > > > > > Simon Nash wrote: > > > > > > > > > > > Vijay, > > > > > > I believe tk_null indicates a null typecode rather than a > typecode with > > > > > > a null value. However, the CORBA spec is not very clear > about the meaning > > > > > > of tk_null. Perhaps we should raise a Core RTF issue to > clarify this. > > > > > > > > > > > > Any comments from the Core folks on the purpose of tk_null > would be appreciated. > > > > > > > > > > > > Simon > > > > > > > > > > > > Vijaykumar Natarajan wrote: > > > > > > > > > > > > > > Simon, > > > > > > > > > > > > > > I don't see why that is required at all. An any is > perfectly capable of dealing w/ a > > > > > > > null w/ no type information.If an object is null, the > any can be marshaled w/ a > > > > > > > tk_null typecode and no data. That is a clear and > accurate way of representing a null > > > > > > > in an > > > > > > > any. Why do we need to invent a new format for null? > > > > > > > > > > > > > > Vijay > > > > > > > > > > > > > > Simon Nash wrote: > > > > > > > > > > > > > > > The descriptions of readAny and writeAny in section > 1.5.1.4 of the Java to IDL > > > > > > > > mapping spec are not very precise and don't say how > null values should be handled. > > > > > > > > These methods are currently described in section > 1.5.1.4 as follows: > > > > > > > > > > > > > > > > > The writeAny method writes the Java object obj to > the output stream out in the > > > > > > > > > form of a GIOP any. The readAny method reads a GIOP > any from the input stream > > > > > > > > > in and unmarshals it as a Java object, which is > returned. > > > > > > > > > > > > > > > > Proposed resolution: > > > > > > > > > > > > > > > > Replace the above paragraph in section 1.5.1.4 by the > following: > > > > > > > > > > > > > > > > The writeAny method writes the Java object obj to the > output stream out in the > > > > > > > > form of a GIOP any. The contents of the GIOP any are > determined by applying > > > > > > > > the Java to IDL mapping rules to the actual runtime > type of obj. If obj is null, > > > > > > > > then it is written as follows: the TypeCode is > tk_value, the repository ID is > > > > > > > > "IDL:omg.org/CORBA/ValueBase:1.0", the name string is > "", the ValueModifier is > > > > > > > > VM_NONE, the concrete base is tk_null, the member > count is 0, and the any's value > > > > > > > > is a null valuetype (0x00000000). > > > > > > > > > > > > > > > > The readAny method reads a GIOP any from the input > stream in and unmarshals it > > > > > > > > as a Java object, which is returned. The following > TypeCodes are valid for > > > > > > > > the GIOP any: tk_value, tk_value_box, and tk_objref. > If the TypeCode is anything > > > > > > > > other than these, a MARSHAL exception is thrown. > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > -- > > > > > > 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 > > > > > > > > -- > > > > 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 > > > > -- > > 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 > > -- > 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