[jdom-interest] hashCode() and equals()

[philip.nelson at omniresources.com]

> If someone could summarize the ~20 messages on this thread, 
> I'd appreciate
> it.
> 

Pretty simple.  Bryan Thale correctly reported that our hashcode
implementation breaks the java contract for hashcode and .equals.  Hashcode
was based on prefix + uri but .equals is based on uri only.  Jason changed
it but now there's a potential problem with getAdditionalNamespaces, a live
List.  This is because two different instances with the same uri and
different prefixes will appear the same to the list remove(Object) method
now that the hashcode is based on the uri only.

I thought we were OK by having the hashcode represent the same instance in
the list and by having hashcode essentially mean the same thing as ==, a
class instance rather than the more abstract idea of what a namespace
represents (and codified in .equals).  

So it seems we have some choices
1 - break the java hashcode .equals contract
2 - create a different method that means equal namespace like
equalsNoPrefix() and then make equals and hashcode and == all based on
prefix and uri
3 - make the list returned by getAdditionalNamespaces not live (undead?) and
let the chips fall where they may.
4 - split up Namespace and prefix into separate classes and reinvent the
namespace api