Re: InetAddress.equals() Anomoly?

From: Pete Loveall (psl_at_ametx.com.NO_SPAM)
Date: 01/08/05 

Date: Sat, 8 Jan 2005 12:37:15 -0600

BTW, the quote in my post was taken from the MSDN Online Library for
InetAddress.equals()
http://msdn.microsoft.com/library/en-us/vjref98/html/java.net.InetAddress007.asp
If J# is to be compatible with Java 1.1.4 (Microsoft's JVM), then areas of
direct incompatibility such as this are bugs in J#. They break working
programs.

It is a major mistake to think that comparing toString() methods (or any
other method, for that matter) for any object provides proper equals()
operation. If the Java API implements equals() for an object, then J# must
use the same general implementation or it risks (as in this case) breaking
working programs with incorrect results.

Your "definition" of two objects being equal has no basis in the Java API.
I refer you to any Java API documenet on Object.equals() for a proper
definition
http://msdn.microsoft.com/library/en-us/vjref98/html/java.lang.Object005.asp
hashCode() must also obey the same rules as equals() with the exception that
two objects with the same hashCode can fail equals(), but two objects that
pass equals() MUST have the same hashCode. In the case of InetAddress, the
hashCode appears to be computed correctly by J#.

Pete Loveall

> "Bruno Jouhier [MVP]" <bjouhier@club-internet.fr> wrote in message
> news:OvNeuxV9EHA.2568@TK2MSFTNGP11.phx.gbl...
>>I don't agree.
>>
>> Two objects are equal if they can be used interchangeably and if they
>> produce the same results when any arbitrary method is applied to them.
>>
>> In your case:
>> dnsaddr.toString() produces firenet.us/12.34.75.101
>> ipaddr.toString() produces grande.rivcom.net/12.34.75.101
>>
>> So, the objects are not equal because they don't produce the same result
>> when you apply toString() to them.
>>
>> If you consider that two InetAddress should be equal as soon as they have
>> the same IP, you take a biased view, you consider that your equals method
>> should take the IP part into account and completely ignore the name side
>> of the INetAddress object. This is wrong. If you start overriding equals
>> to give it "partially equals" semantics, you are going to run into some
>> trouble.
>>
>> So, this is not a bug in the JDK. If you want to use the IP as a hash
>> key, you should use the IP (formatted as a string, or as an integer) as
>> key, you should not use InetAddress because this is a richer object that
>> carries more information than an IP.
>>
>> Bruno.
>
>

Relevant Pages

  • Re: A better cloning mechanism
    ... > So it seems that if equals() were removed from Object, ... that do not need object semantics. ... I have often in the past argued that, in fact, the '==' operator in Java ... answer and you are only doing the reference comparison for performance. ...
    (comp.lang.java.programmer)
  • Re: A better cloning mechanism (was: Why not cloneable by default?)
    ... > I take it that you mean to say that not everything that is a Java ... > why that should have consequences for the use of the equals() method. ... In truth, of course, mutable objects are fine *except* when they ... this concept by saying that List.contains seems safe to use with mutable ...
    (comp.lang.java.programmer)
  • Re: Hidden features of java
    ... unless you decide not to use equals() at all. ... Most programmers don't realize it, ... In addition to using Java in a procedural way, ... For starters, if you find object equality and identity, and more to the point, the ability to define what equality is for a given object class, to *not* be OOP, you should go out and tell all the language designers that they are stunned and don't know what they're doing. ...
    (comp.lang.java.programmer)
  • Re: AspectJ: solution to Javas repetitiveness?
    ... While I'm very impressed with the Eclipse IDE for Java and the ... equal, toString(), toXML, fromString, fromXMLfor all of them. ... Perhaps for very simple classes whose instance variables are ... equals() and hashCode... ...
    (comp.lang.java.programmer)
  • Re: String based hashCode
    ... and any object in java can be used as a key or stored as a ... equals and hashCode implemented in accordance with the contract ... using a HashMap as a key for a HashMap it uses as a key. ... unimplementable hashCode. ...
    (comp.lang.java.programmer)
Loading