First round of java.util.Objects for code review (bug 6797535)
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
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.
Lasu aka Marek Kozieł
More information about the core-libs-dev