[jdom-interest] Inconsistancy in Namespace.hashCode().

GB/DEV - Philip Nelson philip.nelson at omniresources.com
Mon Mar 5 06:24:28 PST 2001

 > I suppose you can argue that two Namespace objects are not equal if
> they describe different prefixes. Maybe that makes sense, but it
> makes me deeply uncomfortable.

Right, since the namespace class also has a prefix attribute so it's not
really a representation of an xml namespace.  What we have is a Namespace +
Prefix class.

>>Hmm... I can see both sides.  The counterargument to yours is that for
>>all other objects in JDOM we define equals() as ==, for good reasons
>>that I'll vigorously defend.  Thus two <foo/> elements are not equals()
>>unless they're the same element object instance.  Same with attributes. 
>>Why should Namespace be different?  

Yes, this would seem very unnatural to me:

Namespace a = Namespace.getNamespace("prefix1", "http://foo");
Namespace b = Namespace.getNamespace("prefix2", "http://foo");

a == b --> true

a.equals(b) --> false 

because from Namespace.equals()

	// Compare URIs
	if (ns.getURI().equals(uri) && ns.getPrefix().equals(prefix)) {
		return true;

even if you made both hashcode and equals consistent, I would seem unnatural
for me to say

Namespace a = Namespace.getNamespace("prefix1", "http://foo");
Namespace b = Namespace.getNamespace("prefix2", "http://foo");

and then see a.equals(b) as true.  

Perhaps we should
- rename the Namespace class so it's not confused as an api for
representation of an xml namespace (which we don't really need)
- add a method to compare Namespace instances as xml namespaces like

More information about the jdom-interest mailing list