> One point I didn't see mentioned in the thread above was that its arguable
> that object graphs containing cycles aren't going to occur very naturally
> with XML* (?) - ie by going with the
> straightforward implementation of equals and hashCode you'd probably make
> 90% of users happy (and those who get StackOverflowErrors would likely be
> aware that they were dealing with cyclic
> data structures and be able to diagnose this quickly).
In fact the problem of dealing with cycles were the primary reason why
it's so hard to get this implementation right.
Defining equality over cyclic graphs is possible, by the way. It's just
isomorphism between two labeled graphs.
>
> Has anyone tried the workarounds suggested? Performance isn't an issue so
> I'm happy to use Jakarta's reflective EqualsBuilder but wasn't sure that
> all fields in JAXB generated classes should be processed by this. If all
> fields should not be included as a definition of equality, is there some
> automatic way to determine which should?
I can't think of any case where you cannot compare all the fields.
>
> *eg. if I understand correctly then unmarshalling couldn't produce an
> object graph with cycles?
Actually it can, if you think about ID/IDREF.
> If a user creates an object graph with cycles and
> tries to marshall it then its reasonable for the marshaller to go into a
> loop - what else might the user mean?
Again, it depends on the kind of cycles. And the marshaller will detect
a cycle and complains, instead of dying with StackOverflowError.
regards,
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net