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

[Reinier Zwitserloot]

Late to the thread, so many one-liners to various ideas uttered on the  
list:

--

This is great stuff folks. As long as I get my String.join (or  
Collections.join, or Arrays.join, or Whatever.join, as long as there's  
a join!), of course :)

--

The compareTo methods for Integer/Short/Byte/Long (Character?) should  
clearly go in the respective wrapper classes for consistency's sake,  
but there's nothing in the way of ALSO making a utilities class of  
sorts that contains all the primitive compareTo methods as well, if  
that seems useful.

--

A trick I'm reverting to rather a lot of late is to find my own jar  
file by getting a URL to my own class file as a resource, resolved  
against my own class, and then parsing this URL for the jar bit of it.  
(MyClassName.class.getResource("MyClassName.class")). There are a  
bunch of caveats here, mostly revolving around the notion that you may  
not have been loaded as a jar file, but as a directory, or via the  
network, or from a database, or who knows how? - but that's what  
returning "null" is for, surely. Something to consider, though I'm not  
entirely convinced this hack should be made legitimate by turning it  
into a library method. I doubt it's a good fit for Objects, in any case.

--

Whatever hashCode() implementation is decided on, it should probably  
mirror the way IDEs generate it when you ask them to. Specifically:

Use deepHashCode for object arrays. Yes, this means you'll get  
StackOverflows if an array contains itself. This is either (A) the  
correct action, or (B) ArrayList is broken, as it has the same  
behaviour.

Split up longs via XOR, and doubles via toLongBits -> XOR. There's  
loads of alternative algorithms that purport to be more efficient, but  
without specific domain knowledge, xor is hard to beat.

Project Lombok sticks to this plan, which is mostly derived from  
Effective Java, IIRC. Same goes for equals and toString.

--

How does Joe Average Java Programmer tell the difference between  
Objects.equals(), which simply adds null friendliness, and a  
reflection-based pseudo-automagical hashCode builder?

--

Changing Arrays.deepEquals and friends to varargs has the same problem  
as Arrays.asList for 'list literals': What do list literals and null- 
friendly equals/hashCode/toString implements have to do with arrays?  
Nothing. There's a reason google went out of their way to dress up  
"ImmutableList.of(a, b, c);" as a library, after all. Even without the  
Collections.unmodifiableList() wrapper call, Arrays.asList() is  
unwieldly and a pretty bad implementation leakage - you're trying to  
build an immutable list; the fact that you're doing so by varargsing  
your arguments into an array and turning THAT into a list is not  
something you should be confronted with when reading code. I'd much  
prefer a solution that did not involve java.util.Arrays.

--

toString() is not supposed to be something you ever rely upon, and I  
furthermore have a rather hard time imagining anybody can possibly be  
relying on the random-esque default toString() implementation, which  
combines a memory pointer with a class name. So, would it be an option  
to change toString()'s implementation to do the sane thing?  
Arrays.toString (deepToString? That can cause StackOverflows...) for  
arrays, and some reflection-based magic otherwise? Changing equals()  
and hashCode() is not so simply modified without causing serious  
backwards compatibility issues, unfortunately.


  --Reinier Zwitserloot


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