On Fri, 2002-11-15 at 16:12, Andrus wrote:
> At 03:30 PM 11/15/2002 +1300, you wrote:
> >Done. WRT equals and hashCode, I used the name of the class for both,
> >under the assumption that we want ObjectId's to be equal/hash correctly
> >even if the Class'es are loaded from different ClassLoaders.
> >
> >Certainly the unit tests passed with flying colours, so I'm sure it
> >works in the normal case.. do you think that that is a valid assumption
> >for all cases?
>
>
> I think it is a pretty safe assumption in the view of our recent changes.
>
> How about serialization though? I wonder what is Java default behavior when
> serializing a field of type Class?
An interesting question. I burrowed into the documentation, and Java
uses a class called ObjectStreamClass for serializing a "Class". It
turns out that the name and the serialVersionUID is written out. This
might turn out to be an issue if the uid changes, but for most classes
(that don't specify their own), it is generated from
"a hash computed from the class's name, interfaces, methods, and
fields". If fields have changed, then the object can't be deserialized
anyway. It's a minor pain with respect to methods, but again, if
methods have changed it's probably time that the serialized object was
thrown away anyway. Serialization of DataObjects is not, IMHO, for
long-term storage/retrieval/storage, it's for use in HttpSessions and
the like, or for other short term uses.
The Class might be deserialized into a different class loader, but that
shouldn't affect the objectId equality/hashing (based on the assumptions
I made originally)
Should be fine then. :-)
Craig
This archive was generated by hypermail 2.0.0 : Thu Nov 14 2002 - 22:28:32 EST