Re: InetAddress.equals() Anomoly?

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Bruno Jouhier [MVP] (bjouhier_at_club-internet.fr)
Date: 01/09/05 

Date: Sun, 9 Jan 2005 11:40:41 +0100

One more note on this equals issue:

The JDK is rather inconsistent in the way it treats "equals".

In most cases, it implements a very strict form of equals, i.e., one that
follows my definition (all methods will return the same result if two
objects are equal). The typical example is "Double":

+0.0d == -0.0d is true
but new Double(+0.0d).equals(new Double(-0.0d)) is false!

You have to do this if you want all methods, including
Double.doubleToLongBits(d.doubleValue()) to return the same result when two
objects are equal. But they could have chosen a looser version in which new
Double(0.0d) and new Double(-0.0d) are equal, without breaking the
Object.equals specs.

So, I was wrong in assuming too quickly that the JDK was always using the
strict interpretation of equals. This is obviously not the case with
INetAddr.

Also, in all my implementations around hashtables, I avoid mutable keys and
keys with "partially equals" semantics because they are a source of
confusions (and bugs, think of what happens if a mutable key is modified
after being stored in the hash table). I stick to "immutable" objects with
very strict equals and hashcode semantics (String, Integer or immutable
classes of my own). So, I never hit this kind of problem.

Bruno.