What is the difference between being shallowly and deeply equal? How is this applied to caching?

Asked 2011-04-18T13:27:15.370

Found the following in my notes, but I am unable to make sense of it:

Primitive type wrapper classes implement caching for a limited number of values.
This guarantees that a limited number of deeply equal wrapper objects are also shallowly equal: If o1.equals( o2 ) then o1 == o2.
For example, new Integer( 0 ) == new Integer( 0 ).
In general this does not always work.
For example, new Integer( 666 ) == new Integer( 666 )
may not hold.
The reason for caching is that it saves memory.
In general caching works for “small” primitive values.

I don't understand what is meant by this, or what the difference is between a deep (.equals()) and shallow(==) equals. I know in practice, .equals must be used to objects and == for Integral values, but the actual reasoning for this alludes me.

I assume by the names that shallow maybe just checks that both the values are of the same type and name, which deep checks that both variables point to the same object? I don't see how the caching would come into play here though, or why it would be useful.

Edit Report

2 Answers

When you do == you are comparing the references for equality. This means you're saying "is the address in memory the same for both Objects?"

When you do .equals() you are comparing the Objects themselves for equality. This means you're saying "do these two Objects consider themselves equal?"

The example that was given was poor. The only caching done for these numbers that's mandated by the JLS is the .valueOf() method. The constructor is not cached.

Furthermore, the JLS only specifies the minimum you must cache [-128:127]. JVM implementations may cache more if they so choose. This means Integer.valueOf(500) == Integer.valueOf(500) may be false on some machines, but true on others.

class biziclop {

    public static void main(String[] args) {
        System.out.println(new Integer(5) == new Integer(5));
        System.out.println(new Integer(500) == new Integer(500));

        System.out.println(Integer.valueOf(5) == Integer.valueOf(5));
        System.out.println(Integer.valueOf(500) == Integer.valueOf(500));
    }
}

Results in:

C:\Documents and Settings\glow\My Documents>java biziclop
false
false
true
false

C:\Documents and Settings\glow\My Documents>

See a more detailed answer here (the comments are a gem!): Why do people still use primitive types in Java?

answered 2011-04-18T13:30:45.730

Well, actually shallow/deep dissection is different from ==/equal dissection:

== compares for object identity, that is you checking whether operands are the same in fact (two references to the same area of memory), whereas equals compares for object equivalence, that is "logical" value of two, possibly not identical objects, is the same. If for two objects
```
a == b
```
then it's true that
```
a.equals(b) // if a != null
```
, but opposite isn't true in all cases.
shallow/deep distinction makes sense only for equals comparison. Shallow means that you compare only immediate contents of two objects to find whether they "equal" in your sense, whereas deep means that you compare contents of your objects recursively until all you need to compare is primitive fields. If you define equals method of your objects as sequence of calls to equals on instance fields of these objects, you use deep comparison. If you define equals using == operator to compare compound types, such as Strings, then you use shallow comparison -- and that's incorrect in Java.

Morale of all of this is that you must never use == to compare two compound objects, unless you consider them equal only if they are the same.

answered 2011-04-18T13:43:28.143

What is the difference between being shallowly and deeply equal? How is this applied to caching?

2 Answers

Your Answer