Re: InetAddress.equals() Anomoly?
From: Pete Loveall (psl_at_ametx.com.NO_SPAM)
Date: 01/09/05
- Previous message: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- In reply to: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- Next in thread: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- Reply: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 9 Jan 2005 08:02:31 -0600
"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.
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.
Peter Loveall
- Previous message: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- In reply to: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- Next in thread: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- Reply: Bruno Jouhier [MVP]: "Re: InetAddress.equals() Anomoly?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|