Re: ObjectId and objEntityName

From: Craig Miskell (cmiskel..lbatross.co.nz)
Date: Thu Nov 14 2002 - 22:28:54 EST

  • Next message: Andrus: "Re: Flattened relationship support"

    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