jaxb-api
jaxb-api copied to clipboard
jakartaee
JAXBElement to implement equals and hashCode
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]
- Issue Imported From: https://github.com/javaee/jaxb-v2/issues/57
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: @glassfishrobot
@glassfishrobot Commented 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 Commented lexi said: Created an attachment (id=30) My version of JAXBElement
@glassfishrobot Commented lexi said: Created an attachment (id=31) Unit test for JAXBElement
@glassfishrobot Commented lexi said: I've attached the patched JAXBElement and a unit test. Would you let me know about the progress?
@glassfishrobot Commented ryan_shoemaker said: I'll have one of the spec guys review your proposal and get back to you
@glassfishrobot Commented @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 Commented 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 Commented 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 Commented @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 Commented 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 Commented @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 Commented 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 Commented 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 Commented 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 Commented This issue was imported from java.net JIRA JAXB-57
@lukasj Issue very old with a very obvious solution (generate with every field), is it necessary to maintain this? Regards, Antonio.
