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

Ulf Zibis Ulf.Zibis at gmx.de
Mon Oct 26 16:54:08 UTC 2009

Am 09.09.2009 22:40, Joe Darcy schrieb:

Hello.

For JDK 7, I think it is high-time the platform included a class like java.util.Objects to hold commonly-written utility methods. For example, a two-argument static equals method that returned true if both arguments are null, returns false is one argument is null, and otherwise returns the result of calling arg1.equals(arg2) (6797535 "Add shared two argument static equals method to the platform"). A static hashCode method returning 0 for null and the value of arg.hashCode() has also been suggested. A set of static int compareTo(int, int) static int compareTo(long, long) .... methods probably belongs somewhere in the platform too. What other utility methods would have broad enough use and applicability to go into a common java.util class?

Maybe a little late, but as I said regarding suggested "Strings" class:

Imagine, you could just write

int result = compare(x, y);
int hash = hashCode(x);

in any class, without having to statically import java.util.Objects.*. This smartness would be possible, if those few static methods in Objects would be moved to java.lang.Object.

Introducing a static helper class 'ClassNames' consequently for each "normal" class 'ClassName' we would end up in don't having any static method in a normal class, and so we could drop this language concept completely from Java and instead introduce a kind of "static" class, where all method's are static by definition, similar to abstract class, where all methods are abstract.

I assume, the first of the '...s'-classes was 'Arrays', introduced, because array object's and there members (e.g. length) are not defined via normal class syntax.

IMO, introducing '...s'-classes for whatever class is a bad idea, and would satirize the existence of static methods at all, whose worthy task it is , to provide helper functions to instances of objects, where they are defined.

But I think, it's not too late, to change it in JDK 7.

-Ulf

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20091026/4fed6974/attachment.html>

More information about the core-libs-dev mailing list