To resurrect this topic, I also have a pressing need for comparing two jaxb-generated objects by value. Other than the Map/hashCode issue presented by Mattias below and an increase in the size of the generated code, I cannot see any negatives to implementing this feature. I support the idea of a generator option in switching it on/off.
EqualsBuilder, mentioned below, presents a static reflective method for inspecting two objects for equals(), but of course this comes with a performance penalty (and design inelegance).
Are there any other answers from the jaxb developers and community?
Best regards,
Craig
On Tue, 28 Jan 2003 12:44:38 -0500, Marc Dumontier <dumontier_at_mshri.on.ca> wrote:
>If anyone decides to write in this functionality, and is willing to make
>it available..I think it would be very useful.
>
>MD
>
>Gary Gregory wrote:
>
>> You could try using the EqualsBuilder class from the Apache Jakarta
>> Commons Lang project. See
>> http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/EqualsBuilder.html
>>
>> Gary
>>
>> -----Original Message-----
>> From: Mattias R?nnblom [mailto:mattias.ronnblom_at_ericsson.com]
>> Sent: Tuesday, January 28, 2003 2:28 AM
>> To: JAXB-INTEREST_at_JAVA.SUN.COM
>> Subject: JAXB and equals
>>
>>
>> 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
>>