I have run into problems because of the (non)implementation of equals & hashcode in the 'rmi nodes'. The code created collections of nodes and manipulated them with 'contains()', removeAll(), retainAll(), etc.. This worked for the 'local' nodes, but when using RMI it didn't.
According to the javadoc for UnicastRemoteObject: ------- Objects that require remote behavior should extend RemoteObject, typically via UnicastRemoteObject. If UnicastRemoteObject is not extended, the implementation class must then assume the responsibility for the correct semantics of the hashCode, equals, and toString methods inherited from the Object class, so that they behave appropriately for remote objects. ------- I think no changes in interfaces are required, only an implementation for those 3 methods. (I would be 'happy' with an equals that compares nodenumbers for 'real' nodes in equals, returns false for 'virtual nodes', and a hashCode method that does something predictable ) Edwin van der Elst Finalist IT Group -----Oorspronkelijk bericht----- Van: Michiel Meeuwissen [mailto:[EMAIL PROTECTED] Verzonden: maandag 4 oktober 2004 10:31 Aan: [EMAIL PROTECTED] Onderwerp: Re: RMMCI Node.equals , Node.hashCode , Node.toString Pierre van Rooden wrote: > >The rmmci implementation of the bridge fills the contract defined > >by the interfaces. if the interface doesn't define the equals method > >(and thereby doesn't wrap the method) then is't the test case that is > >wrong > > True. The question is therefor: should the interface have the equals() > method defined? > I would say 'yes', but I would like other people's opinions. I would say yes too, but I think a more interesting question is how it should be implemented. (It should probably call MMObjectNode.equals, but what should _that_ implement then?) Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
