Re: InetAddress.equals() Anomoly?
From: Bruno Jouhier [MVP] (bjouhier_at_club-internet.fr)
Date: 01/09/05
- Next message: alex: "System.Drawing.Bitmap to java.awt.Image?"
- Previous message: Pete Loveall: "Re: InetAddress.equals() Anomoly?"
- In reply to: Pete Loveall: "Re: InetAddress.equals() Anomoly?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 9 Jan 2005 17:23:32 +0100
"Pete Loveall" <psl@ametx.com.NO_SPAM> a écrit dans le message de news:
ObDpbPl9EHA.2876@TK2MSFTNGP12.phx.gbl...
> "Bruno Jouhier [MVP]" <bjouhier@club-internet.fr> wrote in message
> news:O1zEqCj9EHA.1188@tk2msftngp13.phx.gbl...
>>
>> If the specs says that then:
>>
>> 1) The J# implementation is buggy because it does not follow the specs.
>>
>> 2) The specs are bad because they violate the normal semantics of
>> "equals".
>>
>> But I agree with you, point 1) should prevail then and the J# guys should
>> fix the implementation so that it conforms to the specs (even if the
>> specs are wrong).
>
> The specs are not "wrong", they are simply in conflict with what your
> think they should be. The Java spec for object equality was written in
> the very earliest of development of the Java language to be able to handle
> specific issues such as this.
>
> The original specification for InetAddress says nothing about the format
> of the toString() method. For that matter, different JVM's have
> implemented toString() in a variety of ways. J# is the only "JVM", by the
> way, which converts DNS names to conical DNS names if the DNS server
> returns that, and does reverse DNS lookups on every connection.
> InetAddress is exactly what its name implies: a holder for an Internet
> address, otherwise known as an IP address. All of the members relate to
> the IP address, not the DNS (or reverse DNS) name. Even getHostName()
> will return the local computer's "name" if the InetAddress does not have a
> DNS name stored in it. This focus on IP address has made it possible for
> Sun to derive IPv4 and IPv6 classes which can be used interchangeably in
> existing or new programs written with no IPv4 vs. IPv6 awareness. Quite
> forward thinking, if you ask me.
I was completely wrong here. I have only worked occasionnaly with the
java.net API and I naively thought that InetAddress was keeping track of the
IP/Name combination (and I was misled by the toString() example). So, this
is why I thought that giving focus on the IP side for equals was wrong. If
the intent of INetAddress is only to encapsulate the IP side, then it makes
perfect sense to override equals as defined by the specs.
>
> The Java language accounted for variances in class use, such as this, and
> in the process made a very flexible programming language. If the creator
> of a class says "this is what this class is for", then the creator can
> make all relevant overrides to reflect that. Should the class have some
> ancillary capabilities which do not affect the primary purpose of the
> class, then those ancillary capabilities can safely be ignored when
> considering object equality. It is a different viewpoint from yours, but
> it is the viewpoint that is written into the Java specification and should
> be readily understood and accepted by anyone writing Java or J#
> applications.
Ok. Again, I was under the impression that INetAddress was encapsulating an
IP/Name combination, and it is not, it is just an IP (and the fact that the
name is added by toString() is just a convenience).
>
> Peter Loveall
>
- Next message: alex: "System.Drawing.Bitmap to java.awt.Image?"
- Previous message: Pete Loveall: "Re: InetAddress.equals() Anomoly?"
- In reply to: Pete Loveall: "Re: InetAddress.equals() Anomoly?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
