I have commited the correction on the 2.0 branch this morning. Regards, Bruno GERODOLLE Anne FTRD/DTL/GRE wrote: > Bruno, > > I am using jonathan 2.0 (according to org.objectweb.jonathan.Release) and > StdStubFactory. > I found the definition of a method called hashcode() somewhere in the > jeremie.libs.stub_factory.stdRefImpl class > renaming this method to hashCode() seems to correct the problem. > > Anne > > >-----Message d'origine----- > >De: Bruno Dumant [mailto:[EMAIL PROTECTED]] > >Date: vendredi 4 mai 2001 12:20 > >�: GERODOLLE Anne FTRD/DTL/GRE > >Cc: [EMAIL PROTECTED] > >Objet: Re: hashCode on stubs > > > > > > > > > >GERODOLLE Anne FTRD/DTL/GRE wrote: > > > >> Hello, > >> > >> I have a small question concerning Jeremie stubs. > >> > >> As far as I have experienced, two stubs corresponding to the > >same remote > >> object are considered "equals", but do not return the same hashCode. > >> > >> Note that two different java.rmi stubs to the same remote > >object return the > >> same hashcode. > >> > >> Is that a bug ? > > > >Apparently, yes. Two equal objects must have the same hashcode. > > > >Actually, the main difficulty is to check that two stubs > >correspond to the same > >remote object, because it requires comparing remote > >identifiers that are not > >necessarily comparable. In old versions of Jonathan, two stubs were not > >considered equal. But this was corrected quite a long time ago > >because Jonas > >needed it (to store objects in hashtables), through the > >implementation of an > >ad-hoc conservative mechanism, that ensures that if the > >equals() method returns > >yes, then the target objects are certainly equal. But, to my > >knowledge, the > >hashcode was always coherent with the result of the equals() method. > > > >If I remember well, the equals and hashcode methods are computed by the > >Reference object designated by the stub, not by the stub > >itself. Two different > >Reference implementations are available in Jeremie : one is > >present in the > >StdStubFactory (used by JIOP, thus in the classical > >client/server case), the > >other in the EventChannelFactory. In which case did you > >experience the problem > >? > > > > > >> What would be the best method if I want to build a hashtable > >> associating some values to remote objects ? > > > >Jonas already does something like that, and it works... > > > >> I can imagine some methods, like > >> using a key that is a "stub wrapper" : > >> class StubWrapper{ > >> Object contents; > >> public boolean equals(Object other) { > >> if (! (other instanceof StubWrapper)) return false; > >> if ( > >((StubWrapper)other).contents.equals(contents)) return > >> true; > >> return false; > >> } > >> public int hashCode(){ return 0;} > >> } > >> > >> but it does not look very nice... > > > >Indeed... > > > >I will have a look at your problem anyway. Which version of > >Jonathan are you > >using ? > > > >Bruno > >
begin:vcard n:Dumant;Bruno tel;cell:06 75 20 76 64 tel;fax:33 1 49 26 09 76 tel;work:33 1 42 44 40 74 x-mozilla-html:FALSE url:www.kelua.com org:Kelua SA adr:;;55 rue Sainte Anne;Paris;;75002;France version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;1 fn:Bruno Dumant end:vcard
