What methods should go into a java.util.Objects class in JDK 7? (original) (raw)

Stephen Colebourne scolebourne at joda.org
Wed Oct 7 08:10:19 UTC 2009

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

More information about the core-libs-dev mailing list