Issue 2609: Issues with ObjectImpl implementations (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: I have some issues with the defined implementation of methods on org.omg.CORBA.portable.ObjectImpl. First, document 98-10-14 says the definitive place to find the implementation for this class is in some zip file which I haven"t been able to find. Is it available somewhere? Since I couldn"t find the zip file, I"m depending on 98-10-14 for the implementation. Second, given that all ObjectImpl methods delegate their implementation to a locally contained Delegate, if any given ObjectImpl subclass has not been connected to an ORB, then it does not have a delegate, and calling any of these methods causes a NullPointerException to be thrown. Is there a "friendlier" way to fail? Or at least a more intuitively obvious exception? Finally, toString, hashCode, and equals are methods common to ALL Java Objects. These methods should ALWAYS behave as expected, ie., no exceptions should be thrown. These were NOT defined to be implemented on ObjectImpl in CORBA 2.2. They are defined to be implemented by document 98-10-14. These methods should either: not be implemented at all on ObjectImpl; or be implemented in such a way that they do not throw NullPointerException. Resolution: Close, no change Revised Text: Actions taken: April 15, 1999: received issue February 27, 2001: closed issue Discussion: Close, no change. All the points made in the issue are addressed in the current specification. If Delegate is not set, BAD_OPERATION is thrown. The implementations of toString, hashCode, and equals test for null Delegate and do reasonable things if it is. (Perhaps this one got resolved earlier and somehow didn't get marked as closed?) End of Annotations:===== From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: java-rtf@omg.org Date: Thu, 15 Apr 1999 07:47:49 -0500 Subject: Issues with ObjectImpl implementations Content-Disposition: inline I have some issues with the defined implementation of methods on org.omg.CORBA.portable.ObjectImpl. First, document 98-10-14 says the definitive place to find the implementation for this class is in some zip file which I haven't been able to find. Is it available somewhere? Since I couldn't find the zip file, I'm depending on 98-10-14 for the implementation. Second, given that all ObjectImpl methods delegate their implementation to a locally contained Delegate, if any given ObjectImpl subclass has not been connected to an ORB, then it does not have a delegate, and calling any of these methods causes a NullPointerException to be thrown. Is there a 'friendlier' way to fail? Or at least a more intuitively obvious exception? Finally, toString, hashCode, and equals are methods common to ALL Java Objects. These methods should ALWAYS behave as expected, ie., no exceptions should be thrown. These were NOT defined to be implemented on ObjectImpl in CORBA 2.2. They are defined to be implemented by document 98-10-14. These methods should either: not be implemented at all on ObjectImpl; or be implemented in such a way that they do not throw NullPointerException. However, changing the implementation isn't so easy. I believe toString and equals can use the following logic: if (_delegate == null) super.XXX (...); else __delegate.XXX (...); But what about hashCode? If this logic were used there, the object would have a different hash code depending on whether it is or is not connected to an ORB. A hashcode of an object should not change during the life of that object. Since hashCode is problemmatic, my preference would be to remove the implementation of these 3 methods from ObjectImpl. Russell X-Sender: andrew@emerald.omg.org Message-Id: Mime-Version: 1.0 Date: Mon, 13 Sep 1999 16:46:39 -0400 To: java-rtf@omg.org From: Andrew Watson Subject: Issue 2609: formal/99-06-02 is missing Cc: Paul H Kyzivat Content-Type: text/plain; charset="us-ascii" X-UIDL: 0a9356cee5a872323939436dfb7c4ddd Dear Java RTF members, I would like to draw your attention to Issue # 2609, which points out that an essential part of the CORBA 2.3 Java language mapping (published in formal/99-07-53) is missing. This is the set of sources for the org.omg.* packages. As the specification says, this file contains the authoritative statement of the contents of org.omg.* - to quote section 1.1.1 of the mapping: 1.1.1 org.omg.* Packages The Java language mapping is highly dependent upon the specification of a set of standard Java packages contained in org.omg.*. The complete and exact contents (the Java sources) of all portions of the Java mapping which cannot be mapped using the rules for mapping IDL to Java are specified in an associated zip file, which is available on the OMG's public server as document formal/99-06-02. This includes Java classes for all PIDL, native types, and ORB portability interfaces. The zip file is the definitive statement of the exact contents of the packages. While every attempt has been made to assure that the text contained in this document is accurate, there may be some minor discrepancies. The zip file is the authoritative statement of the specification because it contains the actual Java code. I have been offered a couple of candidates for this file in the past, notably by Simon Nash, of IBM. However, the file Simon sent falls short in two regards: 1. It's copyrighted by Sun, and OMG apparently doesn't have permission to modify it. However, when signing an LOI, submitters agree to give OMG permission to distribute derivative works from their submission. 2. It doesn't actually contain the correct definitions - according to Simon it only includes definitions for APIs in the org.omg.CORBA.* packages, not the org.omg.CORBA_2_3.* packages. The published APIs in the IDL/Java mapping spec include the CORBA_2_3 APIs as well as the CORBA APIs. So, while I hate to seem ungrateful, this isn't the file we need. :-) We're receiving a steady stream of requests for this file from potential implementors of the Java/IDL language mapping. Please can you put together a version that meets the requirements (both in content and copyright) and send it to OMG staff as soon as possible. Thanks, Andrew From: "Peter Walker" To: "Andrew Watson" , Cc: "Paul H Kyzivat" Subject: RE: Issue 2609: formal/99-06-02 is missing Date: Mon, 13 Sep 1999 13:54:56 -0700 Message-ID: <000201befe2a$3c3154a0$88fb9081@pacific.eng.sun.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: c1653028705a311ab451ef7b0d6007c3 Andrew, Not sure why Simon would be passing documents to you containing Sun copyrighted material (I'll sought that one out privately). If that document is indeed close to being the "right one" we will of course observe the usual copyright waiving for the purposes of the OMG. I will pursue this one with David Heisser who is our RTF member. Peter. > I have been offered a couple of candidates for this file in the past, > notably by Simon Nash, of IBM. However, the file Simon sent falls short in > two regards: > > 1. It's copyrighted by Sun, and OMG apparently doesn't have permission to > modify it. However, when signing an LOI, submitters agree to give OMG > permission to distribute derivative works from their submission. > Date: Mon, 13 Sep 1999 17:27:15 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Andrew Watson CC: java-rtf@omg.org Subject: Re: Issue 2609: formal/99-06-02 is missing X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 581715dad0a38c5d7921098da704ae62 Andrew - Hopefully this will be quickly resolved. If not, it seems that technically we don't have a valid specification of the CORBA 2.3 Java language mapping. To avoid misleading people, you perhaps should withdraw the Java language mapping chapter until it can be posted in complete form. Paul Andrew Watson wrote: > > Dear Java RTF members, > > I would like to draw your attention to Issue # 2609, which points > out > that an essential part of the CORBA 2.3 Java language mapping > (published in formal/99-07-53) is missing. This is the set of > sources > for the org.omg.* packages. As the specification says, this file > contains the authoritative statement of the contents of org.omg.* - > to quote section 1.1.1 of the mapping: > > 1.1.1 org.omg.* Packages [snip] > I have been offered a couple of candidates for this file in the past, > notably by Simon Nash, of IBM. However, the file Simon sent falls > short in two regards: > > 1. It's copyrighted by Sun, and OMG apparently doesn't have > permission to modify it. However, when signing an LOI, > submitters agree to give OMG permission to distribute > derivative works from their submission. > > 2. It doesn't actually contain the correct definitions - according to > Simon it only includes definitions for APIs in the org.omg.CORBA.* > packages, not the org.omg.CORBA_2_3.* packages. The published > APIs in the IDL/Java mapping spec include the CORBA_2_3 APIs as > well as the CORBA APIs. > > So, while I hate to seem ungrateful, this isn't the file we need. :-) > > We're receiving a steady stream of requests for this file from > potential implementors of the Java/IDL language mapping. Please can > you put together a version that meets the requirements (both in > content and copyright) and send it to OMG staff as soon as possible. > > Thanks, > > Andrew Peter Walker wrote: > > Andrew, > > Not sure why Simon would be passing documents to you containing Sun > copyrighted material (I'll sought that one out privately). If that > document is indeed close to being the "right one" we will of course > observe the usual copyright waiving for the purposes of the OMG. > > I will pursue this one with David Heisser who is our RTF member. > > Peter. From: Jeffrey Mischkinsky Message-Id: <199909132304.QAA13297@wheel.dcn.davis.ca.us> Subject: Re: Issue 2609: formal/99-06-02 is missing To: paulk@roguewave.com (Paul H Kyzivat) Date: Mon, 13 Sep 1999 16:04:35 -0700 (PDT) Cc: andrew@omg.org, java-rtf@omg.org In-Reply-To: <37DD6C33.30EE4EBF@roguewave.com> from "Paul H Kyzivat" > at Sep 13, 99 05:27:15 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-UIDL: 03dbb86683c4a6ac527eed81564f4e5e 'Paul H Kyzivat' writes: > > Andrew - > > Hopefully this will be quickly resolved. > > If not, it seems that technically we don't have a valid > specification of > the CORBA 2.3 Java language mapping. To avoid misleading people, you > perhaps should withdraw the Java language mapping chapter until it > can > be posted in complete form. All the is contained in the spec. It's just not very convenient to retype a bunch of java code from pdf files. > > Paul > > Andrew Watson wrote: > > > > Dear Java RTF members, > > > > I would like to draw your attention to Issue # 2609, which points > out > > that an essential part of the CORBA 2.3 Java language mapping > > (published in formal/99-07-53) is missing. This is the set of > sources > > for the org.omg.* packages. As the specification says, this file > > contains the authoritative statement of the contents of org.omg.* > - > > to quote section 1.1.1 of the mapping: > > > > 1.1.1 org.omg.* Packages > > [snip] > > > I have been offered a couple of candidates for this file in the > past, > > notably by Simon Nash, of IBM. However, the file Simon sent falls > > short in two regards: > > > > 1. It's copyrighted by Sun, and OMG apparently doesn't have > > permission to modify it. However, when signing an LOI, > > submitters agree to give OMG permission to distribute > > derivative works from their submission. > > > > 2. It doesn't actually contain the correct definitions - according > to > > Simon it only includes definitions for APIs in the > org.omg.CORBA.* > > packages, not the org.omg.CORBA_2_3.* packages. The published > > APIs in the IDL/Java mapping spec include the CORBA_2_3 APIs as > > well as the CORBA APIs. > > > > So, while I hate to seem ungrateful, this isn't the file we > need. :-) > > > > We're receiving a steady stream of requests for this file from > > potential implementors of the Java/IDL language mapping. Please > can > > you put together a version that meets the requirements (both in > > content and copyright) and send it to OMG staff as soon as > possible. > > > > Thanks, > > > > Andrew > > Peter Walker wrote: > > > > Andrew, > > > > Not sure why Simon would be passing documents to you containing > Sun > > copyrighted material (I'll sought that one out privately). If that > > document is indeed close to being the "right one" we will of > course > > observe the usual copyright waiving for the purposes of the OMG. > > > > I will pursue this one with David Heisser who is our RTF member. > > > > Peter. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Jeffrey Mischkinsky Message-Id: <199909132303.QAA13225@wheel.dcn.davis.ca.us> Subject: Re: Issue 2609: formal/99-06-02 is missing To: pwalker@Eng.Sun.COM (Peter Walker) Date: Mon, 13 Sep 1999 16:03:08 -0700 (PDT) Cc: andrew@omg.org, java-rtf@omg.org, paulk@roguewave.com In-Reply-To: <000201befe2a$3c3154a0$88fb9081@pacific.eng.sun.com> from "Peter Walker" at Sep 13, 99 01:54:56 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-UIDL: e3e3fb0e92b3ed730dffd80fd30fdaf1 'Peter Walker' writes: > > Andrew, > > Not sure why Simon would be passing documents to you containing Sun > copyrighted material (I'll sought that one out privately). If that > document > is indeed close to being the "right one" we will of course observe > the usual > copyright waiving for the purposes of the OMG. > > I will pursue this one with David Heisser who is our RTF member. I am the guily party here. I've got a "clean" version which i need to do one more final check on. The person i'm working with this on has been out of the country for the last several weeks. He was supposed to be back 2 weeks ago, but is having some visa problems. By the end of the week.... jeff > > Peter. > > > > I have been offered a couple of candidates for this file in the > past, > > notably by Simon Nash, of IBM. However, the file Simon sent falls > short in > > two regards: > > > > 1. It's copyrighted by Sun, and OMG apparently doesn't have > permission to > > modify it. However, when signing an LOI, submitters agree to > give OMG > > permission to distribute derivative works from their > submission. > > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Mon, 13 Sep 1999 19:58:18 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Jeffrey Mischkinsky CC: andrew@omg.org, java-rtf@omg.org Subject: Re: Issue 2609: formal/99-06-02 is missing X-Priority: 3 (Normal) References: <199909132304.QAA13297@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 76bdf87dc37a2edba0291a356f234b6d Jeffrey Mischkinsky wrote: > > All the is contained in the spec. It's just not very convenient to > retype a bunch of java code from pdf files. Is this true? I'm just a go-between on this subject, but I have been led to believe that there is stuff missing. *If* this is merely a matter of applying the standard language mappings to the CORBA IDL, then I have less of a problem here. From: Bill Binko To: "'Paul H Kyzivat'" , Jeffrey Mischkinsky Cc: andrew@omg.org, java-rtf@omg.org Subject: RE: Issue 2609: formal/99-06-02 is missing Date: Tue, 14 Sep 1999 10:40:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0fc7d5fbd67f7ab9429dd96aeb1b3f3b Paul, I don't think this is a case of just applying the mapping to the IDL. In the spec (section 1.1.1.), it reads: 1.1.1 org.omg.* Packages The Java language mapping is highly dependent upon the specification of a set of standard Java packages contained in org.omg.*. The complete and exact contents (the Java sources) of all portions of the Java mapping which cannot be mapped using the rules for mapping IDL to Java are specified in an associated zip file, which is available on the OMG's public server as document formal/99-06-02. This includes Java classes for all PIDL, native types, and ORB portability interfaces. The zip file is the definitive statement of the exact contents of the packages. While every attempt has been made to assure that the text contained in this document is accurate, there may be some minor discrepancies. The zip file is the authoritative statement of the specification because it contains the actual Java code. While I don't think there's anything wrong with waiting until the end of the week, I don't think this should be trivialized: it IS the official mapping. Bill -----Original Message----- From: Paul H Kyzivat [ mailto:paulk@roguewave.com ] Sent: Monday, September 13, 1999 7:58 PM To: Jeffrey Mischkinsky Cc: andrew@omg.org; java-rtf@omg.org Subject: Re: Issue 2609: formal/99-06-02 is missing Jeffrey Mischkinsky wrote: > > All the is contained in the spec. It's just not very convenient to > retype a bunch of java code from pdf files. Is this true? I'm just a go-between on this subject, but I have been led to believe that there is stuff missing. *If* this is merely a matter of applying the standard language mappings to the CORBA IDL, then I have less of a problem here. Sender: jis@fpk.hp.com Message-ID: <37DE6B9B.DB56A005@fpk.hp.com> Date: Tue, 14 Sep 1999 11:36:59 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Paul H Kyzivat CC: Jeffrey Mischkinsky , andrew@omg.org, java-rtf@omg.org Subject: Re: Issue 2609: formal/99-06-02 is missing References: <199909132304.QAA13297@wheel.dcn.davis.ca.us> <37DD8F9A.9C8680A8@roguewave.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2f51fe7363ce73745090012e6375eb6f Paul H Kyzivat wrote: > > Jeffrey Mischkinsky wrote: > > > > All the is contained in the spec. It's just not very convenient to > > retype a bunch of java code from pdf files. > > Is this true? I'm just a go-between on this subject, but I have been > led > to believe that there is stuff missing. *If* this is merely a matter > of > applying the standard language mappings to the CORBA IDL, then I > have > less of a problem here. I think what Jeff meant is that the parts that are not based on standard language mapping are spelled out line by line in the various sections of the spec. It needs to be typed in tediously to obtain the corresponding Java file. I think in the future we will have to tighten up on RTF output acceptance by the AB to ensure that the new IDL file is actually part of the material submitted by the RTF with the report and edited chapters, for recommendation to adopt by the *TC. That appears to be the only way to fix this problem going forward. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Sun, 05 Dec 1999 20:00:19 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: java-rtf@omg.org Subject: Proposal for issue 2609 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Um>!!*Lf!!f%'!!Z=f!! We need to fix the problem with the ObjectImpl toString(), hashCode(), and equals() methods throwing exceptions when the ObjectImpl is not connected to a Delegate. I think the best solution is for toString(), hashCode(), and equals() for unconnected stubs to have the default behavior of the Delegate class, even though there is no Delegate object. So my proposal is that these ObjectImpl methods be changed to: public String toString() { if (__delegate != null) return __delegate.toString(this); else return getClass().getName() + ": no delegate set"; } public int hashCode() { if (__delegate != null) return __delegate.hashCode(this); else return System.identityHashCode(this); } public boolean equals(java.lang.Object obj) { if (__delegate != null) return __delegate.equals(this, obj); else return (this==obj); } 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