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
