Paul Benedict wrote:
If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:
http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
My biggest complaint about String.valueOf(Object) is that it will
actually return "null" for null objects. I can't stand that. If I have
no data, I don't want any printable data back. While my preference
might be too narrow for the JDK, the second overloaded version of
ObjectUtils#toString(String, String) seems like a winner to me. Allow
a default String to be provided when it is null:
public static String toString(Object o, String defaultStr) {
return (o != null) ? : String.valueOf(o) : defaultStr;
}
I agree that this variant should be on Objects. To me, that strongly
implies that the variant without the second argument should also be
there (and yes, I'd prefer it to return "" instead of "null" for null).
BTW, I don't accept the argument that one and only one way to do
something is part of the JDK. In key places there are multiple options.
NIO Path vs File and Calendar vs Date are examples. (Most code is
written using IDEs these days, so having a predictable place to start
from for autocomplete is important. Hence having equals/hashCode/compare
but not toString would be very unintuitive to the Objects API).
Stephen
