Stephen Colebourne a écrit :
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;
}
Hi Stephen,
[...]
In key places there are multiple options. NIO Path vs File and
Calendar vs Date are examples.
As you know, Path (resp. Calendar) is just an attempt to correct the
mess introduced by File (resp. Date).
So yes, there is duplication but this duplication is done to correct a
wrong design.
(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
Rémi
