Re: InetAddress.equals() Anomoly?

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

  • Next message: Pete Loveall: "Re: InetAddress.equals() Anomoly?" 
    Date: Sat, 8 Jan 2005 12:15:52 -0600

    As shown in my follow-up post, this is not a matter of opinion! ALL Java
    API documents (including Microsoft's) state:

    Compares this object against the specified object. The result is true if and
    only if the argument is not null and it represents the same IP address as
    this object.
    Two instances of InetAddress represent the same IP address if the length of
    the byte arrays returned by getAddress is the same for both, and each of the
    array components is the same for the byte arrays.

    This says nothing about toString(). In fact, it specifically states that
    ONLY the IP address is to be considered when doing the comparison, NOT the
    DNS name or any other mangled name that the JVM might come up with.

    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.

  • Next message: Pete Loveall: "Re: InetAddress.equals() Anomoly?"

    Relevant Pages

    • Re: InetAddress.equals() Anomoly?
      ... > Compares this object against the specified object. ... The J# implementation is buggy because it does not follow the specs. ... The specs are bad because they violate the normal semantics of "equals". ... >> If you consider that two InetAddress should be equal as soon as they have ...
      (microsoft.public.dotnet.vjsharp)
    • Re: About vector.contains()
      ... in this case the objects in the Vector are arrays, ... default Object.equalsimplementation which compares identity. ... the equals() method of the objects in the ...
      (comp.lang.java.programmer)
    • Re: compare two byte[] s
      ... Possibly because there are so many different equivalence relations that could be candidates for "equality." ... static method of Arrays. ... I think it's pretty poor that [].equals doesn't do proper equality testing, but what i find absolutely appalling is that *Arrays.equals doesn't either*. ... Hobbit while listening to Radiohead's Hail to the Thief. ...
      (comp.lang.java.programmer)
    • Re: equals vs ==
      ... == compares identity, equalscompares equality. ... references referring to it. ... equals() will return also true if the ... String overrides it by comparing the contents of the string. ...
      (comp.lang.java.programmer)
    • Re: String comparison with "==" is not reliable?
      ... .equalscompares the actual string value ... By default, equals() compares references, not values of the objects themselves ("string" or otherwise). ... Only if equalsis overridden does its behavior change, and then to that of the override, which is entirely up to the programmer. ...
      (comp.lang.java.programmer)