<< Unit Tests Are Not Enough | Home | Reintroducing Jini 2.1 >>

Friday Java Quiz: Object Identity

Kevin IM-ed me yesterday with the following question:

How come foo.getBar() == expectedBar is true yet foo.getBar().equals(expectedBar) is false?

I'll make that today's Java quiz: Have you encountered a situation in non-play code where obj1 == obj2 is true yet obj1.equals(obj2) is false?

By non-play code I mean a code base where all equals() and hashCode() overrides honor their contracts. In other words, there are no silly code like

public boolean equals(Object other) {
  return false;
}
Tags :
Responses[13] RSS feed for responses to this blog entry
Posted by Weiqi Gao on September 28, 2007 6:06:16 AM CDT #


Reply

Re: Friday Java Quiz: Object Identity

Comment from Philipp Meier on September 28, 2007 6:33:48 AM CDT #

WATCHOUT: SPOILER!

Think of i n h e r i t a n c e

Reply

Separate class proxies considered harmful

Comment from Bob Lee on September 28, 2007 6:27:39 PM CDT #
This can happen if you create a *separate* proxy out of a concrete class and the proxied equals method accesses fields. I think both Spring and Hibernate do this. Technically, the user's equals method abides by the contract, but evil frameworks can break it. Note that making the proxy and your object the same instance (like Guice does) doesn't have this problem, nor does proxying interfaces.
Reply

Separate class proxies considered harmful

Comment from Bob Lee on October 1, 2007 11:38:16 AM CDT #
Note also that a framework could check for == in the generated proxy, but this won't work if proxy could forward to multiple different objects.
Reply

Re: Friday Java Quiz: Object Identity

Comment from Artur Karazniewicz on September 28, 2007 7:03:59 AM CDT #
This simply breaks equals contract. Please bear in mind that proper equals method should be reflexive, symmetric and transitive. Reflexive means that a.euals(a) should return true. Your example breaks this very rule.
Reply

Re: Friday Java Quiz: Object Identity

Comment from Dan Lewis on September 28, 2007 7:04:54 AM CDT #
The implementation of Foo must be suspect, e.g.: 
class Foo {
  boolean equals(Object o) {
    return false;
  }
}
Reply

Re: Friday Java Quiz: Object Identity

Comment from Anonymous on September 28, 2007 8:08:59 AM CDT #
It's gotta be something to do with autoboxing.
Reply

Re: Friday Java Quiz: Object Identity

Comment from Anonymous on September 28, 2007 2:52:30 PM CDT #
A mutable class with the value-based equality semantics in a concurrent environment?
Reply

Re: Friday Java Quiz: Object Identity

Comment from Anonymous on September 28, 2007 7:47:15 PM CDT #
It's quite common to start equals() with checking the class membership, e.g., if(!otherObject instanceof MyClass) {return false;}. This becomes problematic if MyClass is loaded by sibling class loaders (such as, two Web apps) and the call is made across the classloader boundary.
Reply

Re: Friday Java Quiz: Object Identity

Comment from Bob Lee on October 1, 2007 11:36:02 AM CDT #
In that case, == wouldn't work either.
Reply

Re: Friday Java Quiz: Object Identity

Comment from Anonymous on October 1, 2007 4:15:31 PM CDT #
Sure would... Say, some code in CL1 calls method areEqual(obj1, obj2) where both variables point to the same actual instance created in CL2. The instance(s) are passed through a reference to java.lang.Object OTOH, == is "JVM global". What am I missing?
Reply

Re: Friday Java Quiz: Object Identity

Comment from Bob Lee on October 3, 2007 11:01:19 AM CDT #
That's not how it works. No matter what, you have a single instance which can only have one class (the class loaded in CL2).
Reply

Re: Friday Java Quiz: Object Identity

Comment from Josh Bloch on September 28, 2007 8:21:46 PM CDT # 
int y = 1;
Long x = 1L;
System.out.println(x == y);
System.out.println(x.equals(y));
Reply

Re: Friday Java Quiz: Object Identity

Comment from Anonymous on September 28, 2007 10:23:40 PM CDT #
I'd go with the for the classloader exp. Is Bob implying that that proxy equals modifies the fields ?

Add a comment Send a TrackBack