Issue 1621: Stub methods for hashCode, equals and toString (java2idl-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: RMI/JRMP stubs provide overridden implementations for the hashCode, equals, and toString methods of java.lang.Object. The stub hashCode method returns the same hash code for different stubs that refer to the same remote object. The stub equals method returns true when stubs that refer to the same remote object are compared. These methods allow remote objects to be held in Java collections. The stub toString method returns a string containing information about the remote object, not the local stub. RMI/IIOP stubs should provide equivalent methods. The easiest way to do this is to add implementations of these three methods to the javax.rmi.CORBA.Stub base class. I propose that the definition of javax.rmi.CORBA.Stub in section 7.2.5 be modified to add these methods. Resolution: Revised Text: Actions taken: June 30, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Tue, 30 Jun 1998 12:28:48 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: java2idl-rtf@omg.org Cc: issues@omg.org Subject: Stub methods for hashCode, equals and toString RMI/JRMP stubs provide overridden implementations for the hashCode, equals, and toString methods of java.lang.Object. The stub hashCode method returns the same hash code for different stubs that refer to the same remote object. The stub equals method returns true when stubs that refer to the same remote object are compared. These methods allow remote objects to be held in Java collections. The stub toString method returns a string containing information about the remote object, not the local stub. RMI/IIOP stubs should provide equivalent methods. The easiest way to do this is to add implementations of these three methods to the javax.rmi.CORBA.Stub base class. I propose that the definition of javax.rmi.CORBA.Stub in section 7.2.5 be modified to add these methods. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Sender: "George Scott" Date: Mon, 27 Jul 1998 18:10:36 -0700 From: "George M. Scott" Organization: Inprise Corporation To: java-rtf@omg.org Subject: Stub delegation of toString, hashCode, and equals Here is a more detailed proposal for the stub delegation of the toString, hashCode, and equals methods as we discussed today. The proposal is compatible with the old mapping in that equals and hashCode will work exactly as they did before, however toString will have different output. I think this is acceptable in that it allows ORB vendors to provide better output via toString and allows one to define semantics of equal and hashCode to take IORs into account. Add the following three methods to ObjectImpl: public String toString() { return _get_delegate().toString(this); } public int hashCode() { return _get_delegate().hashCode(this); } public boolean equals(java.lang.Object obj) { return _get_delegate().equals(this, obj); } Add the following methods to Delegate: public String toString(org.omg.CORBA.Object self) { return self.getClass().getName() + ":" + this.toString(); } public int hashCode(org.omg.CORBA.Object self) { return System.identityHashCode(self); } public boolean equals(org.omg.CORBA.Object self, java.lang.Object obj) { return (self == obj); } George Return-Path: Date: Tue, 28 Jul 1998 08:16:32 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: "George M. Scott" Cc: java-rtf@omg.org Subject: Re: Stub delegation of toString, hashCode, and equals References: <35BD250C.F8B2C51A@inprise.com> George, The problem with this is that it is underspecified. Previously, the behavior of hashCode and equals for stubs was well-defined (even if "wrong" :-) With this proposal, different vendors can implement whatever they like in their Delegate, including but not necessarily limited to the semantics we agreed yesterday for RMI stubs. I would like to fix this problem by adding the words from the Java/IDL mapping spec to the IDL/Java spec as the definition of how these methods shall be implemented by compliant ORBs. One more thought. What about stubs created by different ORBs that represent the same remote object? Should these compare equal? ORB vendors could ensure this by using object_to_string as the basis for comparison. Simon George M. Scott wrote: > > Here is a more detailed proposal for the stub delegation of > the toString, hashCode, and equals methods as we discussed today. > The proposal is compatible with the old mapping in that equals > and hashCode will work exactly as they did before, however toString > will have different output. I think this is acceptable in that it > allows ORB vendors to provide better output via toString and allows > one to define semantics of equal and hashCode to take IORs into > account. > > Add the following three methods to ObjectImpl: > > public String toString() { > return _get_delegate().toString(this); > } > > public int hashCode() { > return _get_delegate().hashCode(this); > } > > public boolean equals(java.lang.Object obj) { > return _get_delegate().equals(this, obj); > } > > Add the following methods to Delegate: > > public String toString(org.omg.CORBA.Object self) { > return self.getClass().getName() + ":" + this.toString(); > } > > public int hashCode(org.omg.CORBA.Object self) { > return System.identityHashCode(self); > } > > public boolean equals(org.omg.CORBA.Object self, java.lang.Object > obj) { > return (self == obj); > } > > George -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Sender: raz@arrakis.com.au Date: Tue, 28 Jul 1998 11:50:12 -0300 From: Roland Turner Organization: - To: java-rtf@omg.org Subject: Re: Stub delegation of toString, hashCode, and equals References: <35BD250C.F8B2C51A@inprise.com> George M. Scott wrote: > Add the following methods to Delegate: > > public String toString(org.omg.CORBA.Object self) { > return self.getClass().getName() + ":" + this.toString(); Should this not perhaps be return this.getClass().getName() + ":" + super.toString() ? Perhaps the intended behaviour should be explained in words also? - Raz Return-Path: Sender: raz@arrakis.com.au Date: Tue, 28 Jul 1998 14:12:34 -0300 From: Roland Turner Organization: - To: java-rtf@omg.org Subject: Re: Stub delegation of toString, hashCode, and equals References: <35BD250C.F8B2C51A@inprise.com> <35BD7AD0.BE537D90@mailserver.hursley.ibm.com> Simon Nash wrote: > One more thought. What about stubs created by different ORBs > that represent the same remote object? Should these compare > equal? > ORB vendors could ensure this by using object_to_string as the > basis for comparison. As you are no doubt aware, you are treading very unsafe ground here. Guaranteeing such equality in the general case is infeasible (NP-hard), so all that could be specified is a best effort comparison perhaps with some number of clearly specified special/common cases (e.g. require stubs attached to the same local object reference to compare equal). Many people seem to have real difficulty understanding best effort semantics. - Raz Return-Path: Sender: "George Scott" Date: Tue, 28 Jul 1998 19:30:06 -0700 From: "George M. Scott" Organization: Inprise Corporation To: nash@hursley.ibm.com CC: java-rtf@omg.org Subject: Re: Stub delegation of toString, hashCode, and equals References: <35BD250C.F8B2C51A@inprise.com> <35BD7AD0.BE537D90@mailserver.hursley.ibm.com> Simon Nash wrote: > > George, > The problem with this is that it is underspecified. Previously, > the behavior of hashCode and equals for stubs was well-defined > (even if "wrong" :-) With this proposal, different vendors can > implement whatever they like in their Delegate, including but not > necessarily limited to the semantics we agreed yesterday for RMI > stubs. > > I would like to fix this problem by adding the words from the > Java/IDL mapping spec to the IDL/Java spec as the definition of how > these methods shall be implemented by compliant ORBs. I completely agree. I assumed from the last conference call that we were going to make this change, and I was just providing the code for Jeff which provided the most compatibility for ORBs which didn't implement those methods. > One more thought. What about stubs created by different ORBs > that represent the same remote object? Should these compare equal? > ORB vendors could ensure this by using object_to_string as the > basis for comparison. I think equals, should actually be defined to be exactly the same as the CORBA Object _is_equivalent method. George Return-Path: Sender: "George Scott" Date: Tue, 28 Jul 1998 19:35:14 -0700 From: "George M. Scott" Organization: Inprise Corporation To: Roland Turner CC: java-rtf@omg.org Subject: Re: Stub delegation of toString, hashCode, and equals References: <35BD250C.F8B2C51A@inprise.com> <35BDE524.47B823ED@arrakis.com.au> Roland Turner wrote: > > George M. Scott wrote: > > > Add the following methods to Delegate: > > > > public String toString(org.omg.CORBA.Object self) { > > return self.getClass().getName() + ":" + this.toString(); > > Should this not perhaps be > > return this.getClass().getName() + ":" + super.toString() > > ? > > Perhaps the intended behaviour should be explained in words also? No, I meant what I originally said. What I'm trying to accomplish is to provide as much compatibility with the current toString() output of a stub if one does not override the toString() method. This of course depends on the VM implementation, but normally prints out the class name followed by an "@" sign and then an object id in the VM. Unfortunately there is no way to get this exact output, because there is no call like System.identityHashCode() for toString(). So instead I just print out the class name of the stub followed by the delegate's name and object id. Expected output for a Foo stub would be: _FooStub:Delegate@af323f or something like that. It is really intended that vendors who provide an implementation of Delegate print out useful information based on the IOR to which the stub is bound. We are not specifying the output, but merely allowing vendors to provide output as an additional debugging mechanism. The default output isn't intended to be particularly useful. George