Keeping the notions of "equal value" and "refer to same object" separate
is good. But I sometimes wonder if the operators could have been
allocated in such a way as to cause least confusion to learners.

e.g. == for the extremely commonly meant 'has same string value as' and
.sameObject() for the far less used 'are both references to the same thing'.

   I don't think the wallet is the greatest example, but you could imagine
that your wallet and Eric's wallet are identical in every respect (colour,
number of protons, electrons and neutrons that compose it, etc.), but the
two wallets are still distinct.

   Maybe this example will be better:

   Alice and Bob are speaking:

Alice: "I'm thinking of a specific friend."
Bob: "I too am thinking of a specific friend."
Alice: "My friend is 28 years old."
Bob: "My friend is also 28 years old."
Alice: "My friend has brown eyes, blond hair."
Bob: "Mine too."
Alice: "My friend's name is Charlie."
Bob: "So is mine!"
[etc. This goes on, Alice listing a whole bunch of attributes about her
friend, and Bob saying those same attributes apply to his friend.]

   So, are Alice and Bob thinking about the same person? It might be, or it
might not be. It's possible that they are speaking about two completely
different people who are remarkably similar, or it might be that they are in
fact speaking about the exact same person, not knowing that they had a
common friend.

Alice: "Well, my friend Charlie's cell phone number is 12345678901."
Bob: "Oh, well I don't know what my Charlie's cell phone number is. However,
his house number is 19876543210."
Alice: "Hmm, I don't know what my friend's Charlie's home number is."

   Just like a person can have multiple phone numbers, so can objects in
Java have multiple references pointing to them. The fact that you have two
different references doesn't nescessarily mean you have two different
objects!

Alice: "Well, my friend Charlie lives alone at 22 Baker Street."
Bob: "Ah, so does mine. So we must be talking about the same person."

   One way to think of it is that references are sort of like pointers
which hold the address of the objects they are refering to. When you use the
== operator on two reference, it's comparing the addresses that each
reference points to, to see if they are identical. When you invoke the
.equals() method, you're invoking it on a specific object, and that method
is free to do anything the programmer designed it to do. In fact, it can
even "lie" to you and return false when you check if an object is equal to
itself, or it can be programmed to erase all the files on your haddrive,
etc.

   Usually, you assume that the programmer who wrote the equals is not
malicious, and you can just read the documentation for the equals() method
to find out exactly how it determines equality between two objects, or
failing that, read the source code itself.

   I think this "assigning a default property (.value) to a String object"
explanation may be very misleading. The JVM never creates fields out of
nowhere. If a object has a field, it's because the class that defines that
object declared the field. If you look at the source code for the String
class, it actually has 4 fields:

   private final char value[];
   private final int offset;
   private final int count;
   private int hash;

If you check the source code for the equals() method in String, you'll see
it essentially does a character-by-character scan from value[offset] to
value[offset + count - 1] to check if two string objects are equal. So it's
possible that two String object have completely different field values, but
are evaluated to be equal! For example if the two String's field values are:

StringOne {
 value[] = {'A', 'B', 'C', '1', '2', '3'}
 offset = 3;
 count = 3;
 hash = 42;
}

and

StringTwo {
 value[] {'1', '2', '3', 'X', 'Y', 'Z'}
 offset = 0;
 count = 3;
 hash = 69;
}

StringOne.equals(StringTwo) would return true, because of the way it's
programmed.

   I think what you were missing was the fact that the .equals() method can
be programmed to do anything the programmer wishes.

   - Oliver

David Segall wrote On 07/31/06 12:20,:

   Sleight of hand, prestidigitation, trickery and ruses,
scams and frauds -- if I can grab other peoples' wallets,
it's all worth while! ;-)

   I'm not at all sure what you mean by a "default" property.
The String.equals() method makes a computation, just as other
equals() methods -- other anything() methods -- make their
computations.  String.equals() takes one set of things into
account; BigInteger.equals() computes things differently;
neither seems (to me) to "default" to anything.

   Here I must disagree, although it's risky: I've used only
a couple dozen programming languages, well short of "most."
But among those I've used that support the notion of "reference"
as a first-class value, I cannot think of any that make Java
seem at all unusual in this regard.  All of them made a clear
distinction between the reference and the thing referred to.

   In C, consider

    char *p = "Hello, world!";
    char *q = malloc(strlen(p) + 1);  /* assume success */
    strcpy (q, p);

This fragment points p at a character string, then points q
at an exact copy of that string.  At this point p and q are
not == because they point to different string instances, yet
strcmp(p, q) reports that the strings compare equal.  This
should seem eerily similar to Java's behavior with

    String p = "Hello, world!";
    String q = new String(p);

   And if you find two notions of "equality" confusing, it's
a good thing you never encountered Lisp!  My Lisp days are far
behind me and my memory of them has gone a bit foggy, but I
recall that Common Lisp supports at least four different notions
of equality, maybe five.

   I don't think the conclusion follows from the premise.