pair in java generics
Perhaps I have missed something, but as far as I can tell, there is no pair template in the generic data structure classes provided with the jdk
C++ has pair<T1, T2> which is quite useful. The closest java type I can find is Map.Entry, but of course, you can't construct one of these.
Is there a generic Pair class for java that I have somehow overlooked? If not, why has such a basic generic type been excluded from the library?
# 1
Well, first of all, Java doesn't have Templates. But you are right, there is no parametrized Pair or KeyValue class in the JDK (except from Corba stuff). But it is actually not difficult to write one. And, if you like, you can make it implement Map.Entry<T1, T2>, too.
# 2
> Perhaps I have missed something, but as far as I can
> tell, there is no pair template in the generic data
> structure classes provided with the jdk
>
> C++ has pair<T1, T2> which is quite useful. The
> closest java type I can find is Map.Entry, but of
> course, you can't construct one of these.
public class Pair<L, R>
{
private final L left;
private final R right;
public L getRight()
{
return right;
}
public L getLeft()
{
return left;
}
public Pair(final L left, final R right)
{
this.left = left;
this.right = right;
}
public final boolean equals(Object o)
{
if (!(o instanceof Pair)) return false;
other = (Pair) o;
if (getLeft() != null && !getLeft().equals(o.getLeft())) {
return false;
} else if (getLeft() == null && o.getLeft() != null) {
return false;
} else if (getRight() != null && !getRight().equals(o.getRight())) {
return false;
} else if (getRight() == null && o.getRight() != null) {
return false;
} else {
return true;
}
}
public int hashCode()
{
int hLeft = getLeft() == null ? 0 : getLeft().hashCode();
int hRight = getRight() == null ? 0 : getRight().hashCode();
return hLeft + (57 * hRight);
}
}
Don't never say I didn't never gave you nothing.
> Is there a generic Pair class for java that I have
> somehow overlooked?
In 1.6 there's AbstractMap.SimpleEntry
> If not, why has such a basic
> generic type been excluded from the library?
That's a good question.
# 3
Just fixed some errors and added a factory method for convenience:
public class Pair<L, R> {
private final L left;
private final R right;
public R getRight() {
return right;
}
public L getLeft() {
return left;
}
public Pair(final L left, final R right) {
this.left = left;
this.right = right;
}
public static <A, B> Pair<A, B> create(A left, B right) {
return new Pair<A, B>(left, right);
}
public final boolean equals(Object o) {
if (!(o instanceof Pair))
return false;
final Pair<?, ?> other = (Pair) o;
return equal(getLeft(), other.getLeft()) && equal(getRight(), other.getRight());
}
public static final boolean equal(Object o1, Object o2) {
if (o1 == null) {
return o2 == null;
}
return o1.equals(o2);
}
public int hashCode() {
int hLeft = getLeft() == null ? 0 : getLeft().hashCode();
int hRight = getRight() == null ? 0 : getRight().hashCode();
return hLeft + (57 * hRight);
}
}
# 4
> Just fixed some errors and added a factory method for> convenience:Out of curiosity, what errors and how is the factory more convenient?
# 5
Your getRight's return type is L instead R and in equals, o gets casted and assigned to other (which is never defined btw.), but in the following, o is still used (which does not work as of being Object rather than Pair).
The factory method saves you from explicitely stating the types of parameters. It's only reducing a bit of redundancy, which I found quite useful in many situations.Pair<Integer, String> pair = Pair.create(anInteger, aString);
// versus
Pair<Integer, String> pair = new Pair<Integer, String>(anInteger, aString);
# 6
> Your getRight's return type is L instead R and in
> equals, o gets casted and assigned to other (which is
> never defined btw.), but in the following, o is still
> used (which does not work as of being Object rather
> than Pair).
Yeah, I didn't compile it. Thanks.
> The factory method saves you from explicitely stating
> the types of parameters. It's only reducing a bit of
> redundancy, which I found quite useful in many
> situations
Right. I Forgot about that.
