[jdom-interest] Namespace.hashcode patch

[Bryan Thale]

> > I'm not sure I follow you.  == is object equality.  .equals
> > is semantic
> > equality.  We have that with the current implementation.
>
> I see Jason just updated this.  So what we have now is
> Namespace ns1 = Namespace.getNamespace("yyy", "http://ffff");
> Namespace ns2 = Namespace.getNamespace("xxx", "http://ffff");
>
> but
> ns1 == ns2
>
> I thought what we settled on was that semantic equality, "are these the same
> namespace?" in the xml sense was covered by .equals() only.  "Are these the
> same object?" is covered by == and what a java programmer would expect.
> There is some precedence for this of course.

Correct, but the contract defined by java.lang.Object requires that whenever you
override .equals() you pretty much have to do the same to .hashCode() as well.  The
contract states that if two objects satisfy the .equals() relationship then
.hashCode() must return the same integer value for both objects.  Since .equals()
now only tests the URIs, .hashCode() should return a value based only on the URIs as
well.

I don't think this impacts on == at all so

ns1.equals(ns2) and ns1.hashCode() == ns2.hashCode() even though ns1 != ns2

Bryan.

--
Bryan Thale
Motorola Labs, Networking and Infrastructure Research
mailto:thale at labs.mot.com