Hi,
I asked jaxb-comments why the equals() method only has the default
implementation (in Object, only object equality), and not, which
I would have expected, an implementation comparing each attribute
using equals() down the object graph.
I got the answer that it's hard to implement, and that there were
some performance issues. The thread on this list with the subject
"hashCode" seems to end with the same answer.
But why is it hard to implement? And what are the performance issues?
Putting these objects in a Map will be slower, as hashCode() will be
more expensive. Is there something else that will be slower? Off
course, equals() will be slower, but if you need compare the value
of the objects you need to compare the value of the objects. If
you don't you probably better off using ==. And if equals/hashCode
only is generated if the user asks for it, off by default, you can
take the performance hit only if you need to have value-based semantics
in equals().
After all, what's being generated is Data Transfer Objects (aka Value
Objects), and (god forgive) have no behaviour, then a equals()
with value-based semantics would be what most people expects.
What workaround are available? Hand coded equals (one per generated
class) will be tidious and error-prone, and will duplicate
knowledge already present in the XSD files (and will reintroduce
one the of the problems that JAXB originally tries to solve, as
far as I see). As the classes are JavaBeans, I guess one could
write a generic equals(), using reflection? Or should I unmarshal
both objects and compare the strings?
Is there some way to force the generated classes to subclass from
some class? That would be handy if you could find some clean way to
write a generic equals().
Kind regards,
Mattias