First round of java.util.Objects for code review (bug 6797535) (original) (raw)

Marek Kozieł develop4lasu at gmail.com
Fri Oct 9 10:58:09 UTC 2009

2009/10/9 Eamonn McManus <Eamonn.McManus at sun.com>:

The spec, you mention, refers to the instance method equals(), but here we are talking about static helpers. The difference between Marek's suggestion and Joe's is what happens when the equals(Object) method of a or b returns true for a null argument, and that is what I was saying violates the spec. Éamonn McManus · JMX Spec Lead · http://weblogs.java.net/blog/emcmanus

Hello,

Try to understand my point of view. Fist of all we need to notice that returning true for double null-s are not correct for 100% cases. Depending from logic, null might mean 'no object' or 'unknown object' so any way at this point implementation take most common usage.

At second hand if we establish that null == Any Object is false we do not gain anything while suggested implementation:

  1. It allow to detects if called equals(Object o) is null safe, So there will be no problem if some will use equals(Object o1,Object o2) and then start to use a.equals(b) because it will be called this way in suggested implementation.
  2. If some one will need include null in equal logic (is not important now what is the reason) he will be able to do it without re-implementing this part of code.

So with suggested implementation we do not lose anything because specification of equals(Object o) is still valid, it just allow to extend it with null support which is main reason why it should be called from Objects.

-- Regards. Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/

More information about the core-libs-dev mailing list