JAXBElement to implement equals and hashCode

[glassfishrobot]

Hi.

javax.xml.bind.JAXBElement currently does not override equals(...) and
hashCode() methods. Since this class is used to wrap "real" values, it is
desirable to implement these methods so that they take hashCode() and
equals(...) of the wrapped value into an account.

Basically, hashCode() and equals(...) should operate with name, declaredType,
scope, nil AND value fields.

I can implement these methods, but I need to know, where to find the jaxb-api
project sources...

Bye.
/lexi

Environment

Operating System: All
Platform: All

Affected Versions

[2.0 EA1]

[glassfishrobot]

Reported by lexi

[glassfishrobot]

Was assigned to snajper

[glassfishrobot]

ryan_shoemaker said:
The actual CVS repository for the API sources is private and owned by the
JSR-222 expert group, so you can't have access to it. However, there should be
an API src bundle included with the weekly builds under lib/jaxb-api-src.zip.

Feel free to crack open the source and submit a patch. I'll make sure that the
spec guys review it.

[glassfishrobot]

lexi said:
Created an attachment (id=30)
My version of JAXBElement

[glassfishrobot]

File: JAXBElement.java
Attached By: lexi

[glassfishrobot]

lexi said:
Created an attachment (id=31)
Unit test for JAXBElement

[glassfishrobot]

File: JAXBElementTest.java
Attached By: lexi

[glassfishrobot]

lexi said:
I've attached the patched JAXBElement and a unit test.
Would you let me know about the progress?

[glassfishrobot]

ryan_shoemaker said:
I'll have one of the spec guys review your proposal and get back to you

[glassfishrobot]

@jfialli said:
Unsure what the goal is for defining hashCode() for JAXBElement.
From an xml infoset view, an XML element is identified uniquely via
JAXBElement properties declaringScope and name. If defining the
hashCode is to assist in quick hash lookup by element name, it seems the hashCode
would be unique enough by computing the hash based on name and declaringScope
properties.

[glassfishrobot]

lexi said:
The goal for hashCode() is to make it consistent with equals(...).
At least, we have to take the value field into an account.

[glassfishrobot]

kohsuke said:
I believe the reason behind this proposal is to implement the value-based
equality between JAXB object trees.

The equals and the hashCode methods can be generated for the beans, which only
leaves the equals/hashCode methods for the JAXBElement class.

[glassfishrobot]

@jfialli said:
Currently, the JAXB 2.0 specification does not specify the generation
of hashCode() and equals() for schema-derived classes.
In order to make it meaningful for JAXBElement
to be calling hashCode() and equals() on schema-derived classes
set into JAXBElement value property, the specification should
define the generation of hashCode() and equals()
for value classes. I was trying to lessen the dependency by suggesting
that JAXBElement.hashCode() not be defined to call hashCode() on
its value so it would not be required to define hashCode() for
a value class.

The contract between hashCode() and equals() is if two instances
are equal(), they must have the same hashCode() value. This contract
can be kept if hashCode() only looked at the uniquely identifying
components of a JAXBElement, not all components of JAXBElement need
to be involved in computing its hashcode.

[glassfishrobot]

lexi said:

Currently, the JAXB 2.0 specification does not specify the
generation of hashCode() and equals() for schema-derived classes.

Therefore we are free to implement whatever equality semantics we want.

In order to make it meaningful for JAXBElement
to be calling hashCode() and equals() on schema-derived
classes set into JAXBElement value property, the specification
should define the generation of hashCode() and equals()
for value classes.

Not necessarily. By default equals() does identity comparison which seems
perfectly meaningful to me. Let me remind you, right now JAXBElements are
compared by identity in equals(). If this is meaningful, then calling equals()
on values is meaningful as well - no matter if schema-driven classes override
equals()/hashCode() or not.

I was trying to lessen the dependency by suggesting
that JAXBElement.hashCode() not be defined to call hashCode()
on its value so it would not be required to define hashCode()
for a value class.

What I need and what I think to be quite logical is that JAXBElement DOES value
comarison.
JAXBElement is essentially a value-wrapping class therefore I think it would be
quite logical to ask values if they are equal, when comparing two JAXBElement
instances.

[glassfishrobot]

@jfialli said:
Status for this request:

Preference is for javax.xml.bind.JAXBElement and schema derived generated value
classes to follow the same methodology for equals.

Note that under certain circumstances, JAXB 2.0 RI is generating schema-derived
value classes annotated with @XmlRootElement. Independent of whether a JAXB
element is represented either as an instance of javax.xml.bind.JAXBElement or it
is generated as a value class annotated with @XmlRootElement, the current status
quo ensures both are using identity for equality comparisons.

I would be fine with both JAXBElement and @XmlRootElement class using values for
comparisons, but the feedback that I am receiving from RI team is they don't
want to see the specification specify value based equality for schema-derived
classes.

Minimally, if JAXBElement.equals was to implement value equality, JAXB 2.0 would
need to provide a customization to control whether schema-derived value classes
had equality by value or by identity. Otherwise, the JAXB 2.0 specification is
inconsistent by default and user has no ability to make it consistent:
JAXBElement.equal being by value, schema-derived classes being by identity and
only with a non-specified customization, does schema-derived value classes
generate a value-based equals that is equivalent to JAXBElement.equal.

[glassfishrobot]

kohsuke said:
Moving it to the spec...

[glassfishrobot]

kohsuke said:
Given that JAXB 2.0 is finalized without this, I think it's nearly impossible to
add this in future JAXB releases at this point, since such a change would be
likely to break compatibility.

I guess for the purpose of the equals() plugin, the bean that refers to
JAXBElement needs to take care of this.

[glassfishrobot]

skaffman said:
This issue was rejected as WONTFIX 3 years ago, just as the 2.0 spec was being
finalized. Now that the 2.2 spec is in EA, I think it's time to revisit the
question, and have equals() and hashcode() get sensible definitions in JAXBElement.

[glassfishrobot]

lexi said:
+1 from me.

I still think hashCode() and equals() must be defined for JAXBElement. However
this can be also worked around using the hashCode and equals plugins from the
JAXB2 Basics plugin package.

http://confluence.highsource.org/display/J2B/Equals+plugin
http://confluence.highsource.org/display/J2B/HashCode+plugin

[glassfishrobot]

This issue was imported from java.net JIRA JAXB-57