Joe,
I understand your point, and that's why I countered with my String and
StringBuilder points. Those two classes are used underneath the covers
for inline concatenation, but, again, java.util.Objects has grander
intentions than string concatenation. This class is for all objects,
and however String/StringBuilder work with nulls is totally irrelevant
to how this class should behave. You are taking one use from one class
and making it the utility behavior for any object.
Paul
On Thu, Oct 8, 2009 at 1:30 PM, Joseph D. Darcy <joe.da...@sun.com> wrote:
> Paul Benedict wrote:
>>>>
>>>> Why would you choose to return "null" for any null object?
>>>>
>>>
>>> Because that is how the platform has always treated null in string
>>> concatenation.
>>>
>>
>> If you were defining new operations for String, StringBuilder, or
>> StringBuffer, I would agree with your choice. Since you are now
>> defining a global utility method for all objects, I think having
>> "null" being the de-facto string representation of null is simply
>> taking it too far.
>>
>
> System.out.println("" + referenceOfAnyType);
>
> will print "null" if referenceOfAnyType is null.
>
> This is what the platform has done since the beginning.
>
> -Joe
>
>
