[jdom-interest] Namespace.hashcode patch

[Bryan Thale]

Jason Hunter wrote:

> ns1 != ns2, because they're not the same object
> ns1.equals(ns2), because they can be seen as equivalent
> ns1.hashCode().equals(ns2.hashCode()), follows on from above
>
> Of course, now that I'm really thinking about it, if ns.equals() is not
> based on == and based just on a uri comparison, that will cause issues
> if the getAdditionalNamespaces() method returns a live List.  For
> example, you might try (in pseudocode)
> remove(Namespace("foo","http://foo")) and really perform a
> remove(Namespace("bar","http://foo")).  Since it's legal and not
> uncommon to have two namespace prefixes on an elt with the same URI,
> this could conceivably come up.
>
> So do we make getAdditionalNamespaces() return a non-live list (breaking
> our pattern elsewhere), or do we make Namespace.equals() behave as ==?

I apologize if this has been beaten to death before, but doesn't this tend to
indicate that the marriage between prefix and URI is a little too tight?  The
relationship between prefix and URI is many to one, not the one to one the Namespace
class seems to represent.  Would a better approach be to use two maps?  One mapping
prefix -> Namespace and one mapping URI -> Namespace?  Actually, I think one map
would do since prefixes can't contain colons or slashes and would thus always be
distinguishable from URIs as keys so both sets of mappings could be stored in the
same HashMap.  getAdditionalNamespaces() could return a list of prefixes instead of
Namespaces.  Prefixes could be removed from such a list with impunity and total
accuracy.  Isn't that what remove(Namespace("foo","http://foo")) actually means;
that you're removing the prefix, not necessarily the namespace from the element?

That's probably too much work at this stage.  Could we make .equals() mean == again
and add a .matches() or a .equalsIgnorePrefix() or something to the Namespace
interface to test for "xml equality"?  It's a kludge but it would work and not
impact the rest of JDOM much.

Bryan.

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