Issue 4802: Should a holder class for ProtectingEntity get generated (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: >There is something that is unclear in your CORBA spec that I think is causing incompatibility problems between various IDL compilers. >> > >> >Given the following IDL: >> > >> >------------------------------------------------- >> >struct Protection >> >{ >> > string str; >> >}; >> > >> >typedef Protection ProtectedEntity; >> > >> >typedef sequence<ProtectedEntity> ProtectedEntityList; >> > >> >typedef ProtectedEntityList ProtectingEntity; >> >------------------------------------------------- >> > >> >Should a holder class for ProtectingEntity get generated? I ask this because some IDL compilers generate it and others do not (very frustrating!). >> > >> >In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this: "Holder classes are generated for sequence and array typedefs only. The "unwound" type's Holder class is used for the other cases.". >> > >> >Since this is a typedef of a typedef, but the original item was a sequence, should the ProtectingEntityHolder.java file get generated or not? Resolution: Incorporate change and close issue Revised Text: Replace the second paragraph of section 1.18.2 with: Holder classes are generated for sequence and arrays typedefs only. The unwound type's Holder class is used for the other cases. No Holder class is generated for a typedef of a typedef. That is, given the IDL typedef XXX A ; typedef A B ; no Holder is generated for B. A holder is generated for A only if XXX is a sequence or an array. When a holder for B is needed, one of two cases occurs: XXX is an array or sequence. In this case, AHolder exists and is used. XXX is not an array or sequence. In this case, XXXHolder exists and is used. Actions taken: January 9, 2002: received issue December 11, 2002: closed issue Discussion: End of Annotations:===== X-Sender: juergen@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Jan 2002 11:48:50 -0500 To: issues, java-rtf From: Juergen Boldt Subject: issue 4802 -- Java RTF issue This is issue # 4802 darrin.SMITH@fnc.fujitsu.com Should a holder class for ProtectingEntity get generated >There is something that is unclear in your CORBA spec that I think is causing incompatibility problems between various IDL compilers. >> > >> >Given the following IDL: >> > >> >------------------------------------------------- >> >struct Protection >> >{ >> > string str; >> >}; >> > >> >typedef Protection ProtectedEntity; >> > >> >typedef sequence ProtectedEntityList; >> > >> >typedef ProtectedEntityList ProtectingEntity; >> >------------------------------------------------- >> > >> >Should a holder class for ProtectingEntity get generated? I ask this because some IDL compilers generate it and others do not (very frustrating!). >> > >> >In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this: "Holder classes are generated for sequence and array typedefs only. The "unwound" type's Holder class is used for the other cases.". >> > >> >Since this is a typedef of a typedef, but the original item was a sequence, should the ProtectingEntityHolder.java file get generated or not? ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org URL: www.omg.org ================================================================ Date: Fri, 19 Apr 2002 16:23:55 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Issue 4802 To: java-rtf@omg.org Cc: ken.cavanaugh@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Issue 4802 asks whether an IDL compiler for Java should generate a Holder class for a typedef of a typedef of a sequence? For example, given the IDL ------------------------------------------------------- struct Protection { string str; } ; typedef Protection ProtectedEntity ; typedef sequence ProtectedEntityList ; typedef ProtectedEntityList ProtectingEntity ; -------------------------------------------------------- should ProtectingEntityHolder be generated? Section 1.18.2 of the current IDL to Java mapping (ptc/02-01-22) says: "Typedefs for types that are neither arrays nor sequences are unwound to their original type until a simple IDL type or user-defined IDL type (of the non typedef variety) is encountered. Holder classes are generated for sequence and arrays typedefs only. The unwound type's Holder class is used for the other cases" >From the original source of this message (it was reported to me through Sun's licensee engineering initially), it appears that some ORB vendors ship IDL compilers that do not generate the Holder in question (Sun and IBM do not), while others ship compilers that do generate the Holder. I interpret the intent of section 1.18.2 to be to avoid generation of extraneous Holder classes when we can simply reuse the Holder class for the unwound type. This makes sense from the point of view of reducing the footprint of the code generated by the mapping, at the cost of making it more difficult for the user of the generated code. Also, I think the correct interpretation of the second paragraph of 1.18.2 says this. In the example, Holder classes should be generated for Protection and ProtectedEntityList, and not generated for ProtectedEntity and ProtectingEntity. However, the fact that a question arose indicates that we should consider improving the wording here. I think we could add a simple statement that no Holder is generated for a typedef of a typedef. ------------------------------------------ Proposed Resolution: Replace the second paragraph of section 1.18.2 with: "Holder classes are generated for sequence and arrays typedefs only. The unwound type's Holder class is used for the other cases. No Holder class is generated for a typedef of a typedef. That is, given the IDL typedef XXX A ; typedef A B ; no Holder is generated for B. A holder is generated for A only if XXX is a sequence or an array. When a holder for B is needed, one of two cases occurs: 1. XXX is an array or sequence. In this case, AHolder exists and is used. 2. XXX is not an array or sequence. In this case, XXXHolder exists and is used." Ken. Date: Mon, 29 Apr 2002 07:11:43 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en To: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: Issue 4802 Ken, Looks good to me. Simon Ken Cavanaugh wrote: > > Issue 4802 asks whether an IDL compiler for Java should generate a Holder class for > a typedef of a typedef of a sequence? For example, given the IDL > > ------------------------------------------------------- > > struct Protection { > string str; > } ; > > typedef Protection ProtectedEntity ; > > typedef sequence ProtectedEntityList ; > > typedef ProtectedEntityList ProtectingEntity ; > > -------------------------------------------------------- > > should ProtectingEntityHolder be generated? > > Section 1.18.2 of the current IDL to Java mapping (ptc/02-01-22) says: > > "Typedefs for types that are neither arrays nor sequences are unwound to their > original type until a simple IDL type or user-defined IDL type (of the non typedef > variety) is encountered. > > Holder classes are generated for sequence and arrays typedefs only. The unwound > type's Holder class is used for the other cases" > > >From the original source of this message (it was reported to me through Sun's > licensee engineering initially), it appears that some ORB vendors ship IDL > compilers that do not generate the Holder in question (Sun and IBM do not), > while others ship compilers that do generate the Holder. > > I interpret the intent of section 1.18.2 to be to avoid generation of extraneous > Holder classes when we can simply reuse the Holder class for the unwound type. > This makes sense from the point of view of reducing the footprint of the code > generated by the mapping, at the cost of making it more difficult for the user > of the generated code. Also, I think the correct interpretation of the second > paragraph of 1.18.2 says this. In the example, Holder classes should be generated > for Protection and ProtectedEntityList, and not generated for ProtectedEntity and > ProtectingEntity. > > However, the fact that a question arose indicates that we should consider improving > the wording here. I think we could add a simple statement that no Holder is > generated for a typedef of a typedef. > > ------------------------------------------ > > Proposed Resolution: > > Replace the second paragraph of section 1.18.2 with: > > "Holder classes are generated for sequence and arrays typedefs only. The unwound > type's Holder class is used for the other cases. No Holder class is generated for > a typedef of a typedef. > > That is, given the IDL > > typedef XXX A ; > > typedef A B ; > > no Holder is generated for B. A holder is generated for A only if XXX is a sequence > or an array. When a holder for B is needed, one of two cases occurs: > > 1. XXX is an array or sequence. In this case, AHolder exists and is used. > > 2. XXX is not an array or sequence. In this case, XXXHolder exists and is used." > > Ken. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 03 May 2002 10:43:49 +0800 From: Cuie Zhao Subject: Re: Vote 1 in the current RTF To: Ken Cavanaugh Cc: java-rtf@omg.org X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en Borland votes: Yes on issue 3665. No on issue 4802. -- For ORBs that have been generating BHolders all along and customers that have been using BHolders, the proposed resolution of this issue will introduce code portablity problem. Yes on issue 4805. Thanks, Cuie Ken Cavanaugh wrote: > This is Vote 1 of the IDL to Java 2002 RTF. Your votes are due > May 6, 2002 at 5 pm PST. Here are the proposed resolutions > (all changes are to be made to ptc/02-01-22): > > ------------------------------------------------------------------------------------ > > Issue 3665: (ORBid questions): > > Close no change as previously discussed. > > ------------------------------------------------------------------------------------ > > Issue 4802 (clarification on typedef of typedef): > > Replace the second paragraph of section 1.18.2 with: > > Holder classes are generated for sequence and arrays typedefs only. > The unwound > type's Holder class is used for the other cases. No Holder class is > generated for > a typedef of a typedef. > > That is, given the IDL > > typedef XXX A ; > > typedef A B ; > > no Holder is generated for B. A holder is generated for A only if > XXX is a sequence > or an array. When a holder for B is needed, one of two cases > occurs: > > 1. XXX is an array or sequence. In this case, AHolder exists and is > used. > > 2. XXX is not an array or sequence. In this case, XXXHolder exists > and is used. > > ------------------------------------------------------------------------------------ > > Issue 4805 (support for Object::_repository_id): > > In section 1.19.11, add the following method to Object after > _get_interface_def: > > string _repository_id() ; > > In section 1.20.2.1, add the following method to LocalObject after > _get_interface_def: > > public String _repository_id() { > String[] ids = _ids() ; > return ids[0] ; > } > > In section 1.20.2.2, add the following method to Servant after > _get_interface_def: > > public String _repository_id() { > return _get_delegate().repository_id(this) ; > } > > Also in section 1.20.2.2, add the following paragraph after the > section > on _get_interface: > > _repository_id > > Servant provides a default implementation of > _repository_id() that > can be overridden by derived servants if the default > behavior is > not adequate. As defined in the CORBA 3.0 specification, > section 11.3.1, the default behavior of _repository_id is to > return the most derived interface of a static servant or the > most derived interface retrieved from a dynamic servant. > This behavior shall be supported by the Delegate that > implements > the servant. > > In section 1.21.6.3, add the following method to ObjectImpl after > _get_interface_def(): > > public String _repository_id() { > return _get_delegate().repository_id(this) ; > } > > In section 1.21.7, add the following method to Delegate after > get_interface_def: > > public abstract String repository_id( > org.omg.CORBA.Object self) ; > > In section 1.21.8, add the following method to Delegate after > get_interface_def: > > String repository_id( Servant self ) ; > > ------------------------------------------------------------------------------------ > > I do not quite have a proposal ready for 4710, so I'll delay that to > a later > vote. > > Thanks, > > Ken.