Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Type safe enums, class loaders and equals

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Bill de hÓra <bill AT dehora.net>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Type safe enums, class loaders and equals
  • Date: Fri, 24 Jan 2003 22:57:16 +0000

Elliotte Rusty Harold wrote:

On further reflection, I've figured out a relatively clean way to do this. As well as comparing the class and package names, I have to compare the hash codes. I have to use the hashCode() because I need a method in Object that's guaranteed to be available to both versions of the Attribute.Type class.

I just hope none of my students catch me doing this. Every semester I take off lots of points on homework from students who implement equals by comparing the results of either hahsCode() or toString() instead of implementing the equals() method directly. :-)

Because equal hashCodes don't entail object equality, though all equal objects have equal hashCodes (a neccessary but not sufficient condition).

IMO this is one of the places where Java is plain broken; it's right up there with being able to assign a value to a String literal, Object[] weirdeness and the memery model. The only way I know to deal with this problem is a fall back to a value type check where instanceof chucks. This may seem inelegant and defeat the point of a enum, but is that more important that having bogus semantics for equals()? Becuase hashCode isn't correct. You can at least hide the fallback value field as private and use reflection to get a handle on it, but it sure makes for a weird looking equals(). Bizarrely, the DOM crowd probaly got this one right on accident for Java.

Bill de hÓra





Archive powered by MHonArc 2.6.24.

Top of Page