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

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.


-------------- 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