What methods should go into a java.util.Objects class in JDK 7?

[Stephen Colebourne]

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