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
