Or better yet, the toString() method (overriding either the hashCode or the toString method should work in this case since the default toString is just the class name followed by the hashCode).
Still, identical hashCode does not mean identical objects. A better idea would be to expect a List (or Set, Array, whatever) of Serializable objects.
A better idea would be to expect a List (or Set, Array, whatever) of Serializable objects.
What would be the benefit of serializable objects.
I think you are right, with the hashCode and toString-method. This would be a better way to identity the objects.
Still, identical hashCode does not mean identical objects.
Well you, could argument, that the normally identical objects don't need to be sorted. I think the trick would be, to implement the hashcode/toString-methode in a way, that the objects to differ. Maybe with a unique objectID.
Serializables can theoretically be serialized into Strings. If you use that as CDATA, it could then be deserialized into the object.
Theoretically, yes. But still: "What would be the benefit of serializable objects?" On the other hand, you have got a lot of server-client-trafiic.
Like I said above, it makes the converter simple, just serialize and deserialize. Plus no worries about matching hashCode() for non equals() objects. No need for it to keep a copy of any lists either.
Yes, it can add a bit to the initial loading of the items but if you are worried about that just create your own converter. Most of mine just return the PK from the database record (very small) and "deserialize" by retrieving the record from hibernate with the given PK. Also, my hashCode overrides usually just return PK too, so it *is* unique (but that's just me).
so let's say both ways have there ups and downs. ;-) I can agree to you, that you could use your DB-PK to "deserialize" the object. But this only is an option for already persisted objects. But this can't be done with backingbeans placed in the users session. These backingbeans can become quite large and multiple references. So I don't think deserializing these objects is a reliably way to identified the returned order.
By the way. What do the RF-people think? Did you have this throught already?