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