[jdom-interest] Attribute constructor removal [eg]

[GB/DEV - Philip Nelson]

> Here's an item hanging in the TODO that I'd like to have 
> closure on.  In
> Attribute we have the following constructors:
> 
> public Attribute(String name, String value, Namespace namespace)
> public Attribute(String name, String prefix, String uri, String value)
> public Attribute(String name, String value)
> 
> The parameter order of the second constructor clearly doesn't 
> follow the
> right pattern.  I'd like to propose removing the constructor
> (deprecating it for one beta cycle).  I don't think it 
> provides any real
> value considering we have the first.  I doubt anyone uses it, 
> or else we
> would have gotten complaints about the order.  :-)

It got me when writing tests though :-(
> 
> Rearranging parameter order is an option, but it'd cause odd problems
> for people because the old and new sigs would be identical but the
> behavior would change.

Would it be possible to hold off just a little bit longer on this?  I have
been writing tests to help with a problem first reported by Jochen Strunk
where it's difficult or impossible to correctly use the default namespace
from a parent element and also to further explore that issue with namspace
hashcode/==.  I think I'm close to something to try but may not get to it
until next week. That second constructor may be useful for one of the ideas
I am thinking about.  

The hashcode issue also came up for me while profiling one of my apps.
Turns out, that if you have a fair number of attributes in your elements,
String.equals() is pretty much the #1 thing JDOM does besides calling a
parser, in the Element.getAttribute(string, Namespace) method.  Being able
to use == instead on the Namespace could reduce this due to the way
Element.getAttribute works, however *only* if hashcode works the way
Elliotte suggests it should (there is that use case for comparing
Namespaces).

Verifier.checkAttributeName is the other place where String.equals was being
called a lot but I haven't pursued that yet.