What methods should go into a java.util.Objects class in JDK 7? (original) (raw)
Rémi Forax forax at univ-mlv.fr
Wed Oct 7 12:37:58 UTC 2009
- Previous message: What methods should go into a java.util.Objects class in JDK 7?
- Next message: What methods should go into a java.util.Objects class in JDK 7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: What methods should go into a java.util.Objects class in JDK 7?
- Next message: What methods should go into a java.util.Objects class in JDK 7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]