What is the best way to represent a composite key (key containing two values) of a Class and a Boolean

Question

HashMap<Pair<Class<T>,Boolean>,String> abc = new HashMap<Pair<Class<T>,Boolean>,String>();

What is the best way to represent Pair here... Does Java offer anything?

My key will always be a {class,boolean} pair.

Thanks!

Answer 1

I'd create a new wrapper class and use that as the key

class CustomKey
{
   String cls;
   boolean booleanValue;    
   // override equals and hashcode
}

Answer 2

There isn't a Pair class in the Java library. There may be one in JDK7. Many large code bases end up with one.

However, are you sure a Pair is really what you want. A nicely encapsulated class with appropriate behaviour may be more appropriate. Both Boolean and Pair and notable for not having specific meaning.

If you really want efficiency, you might want to go for two IdentityHashMap<Class<T>,String>s.

FWIW, AFAIK, the closest to Pair<Class<T>,Boolean> in the Java library is java.util.concurrent.atomic.AtomicMarkableReference, but you'll need to extend it to override equals and hashCode

Answer 3

At this time Java does not have a Pair type or anything similar. I also did not find one in the Apache commons, although it is possible that I missed someting. In any case usually in this case a small immutable data class is created:

public class Key<T> {
  private final Class<T> cls;
  private final boolean flag;

  public Key(Class<T> cls, boolean flag) {
    this.cls = cls;
    this.flag = flag;   }

  public Class<T> getClass() {
    return cls;   }

  public boolean getFlag() {
    return flag;   }

  // equals and hashCode *must* be implemented -- see Effective Java for examples
}

Some people in this case will use public final methods instead -- it is a matter of taste plus how likely the class will get more complicated.

I have seen a couple of Pair or Tuple classes implemented if there is a need for the class outside of a single case (or if the developers have a functional background).

Answer 4

There is no class called Pair in Java; but there is the Map.Entry<K,V> interface, and there are two public implementations of it: AbstractMap.SimpleEntry and AbstractMap.SimpleImmutableEntry.

If you find it ugly to use nested classes directly in your code, you could always create a Pair class:

public class Pair<Type1, Type2> extends AbstractMap.SimpleEntry<Type1, Type2> {
    public Pair(Type1 t1, Type2 t2) {
        super(t1, t2);
    }
}

Or you could write your own like this:

public final class Pair<Type1, Type2> {
    public final Type1 first;
    public final Type2 second;

    public Pair(Type1 first, Type2 second) {
        this.first = first;
        this.second = second;
    }

    /**
     * Factory method to ease the pain of generics.
     */
    public static <T1, T2> Pair of(T1 first, T2 second) {
        return new Pair<T1, T2>(first, second);
    }

    @Override
    public boolean equals(Object obj) {
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;

        final Pair other = (Pair) obj; // no generics needed here
        if (this.first != other.first &&
            (this.first == null || !this.first.equals(other.first)))
            return false;
        if (this.second != other.second &&
            (this.second == null || !this.second.equals(other.second)))
            return false;
        return true;
    }

    @Override
    public int hashCode() {
        int hash = 7;
        hash = 37 * hash + (this.first != null ? this.first.hashCode() : 0);
        hash = 37 * hash + (this.second != null ? this.second.hashCode() : 0);
        return hash;
    }
}

Answer 5

I have two approaches here... create a key{class, Boolean} -> {string} or i could also do this.

{class} -> {Boolean, string}

the first approach has 1 level of indirection which the second approach has 2... what are the pros and cons here? Is the second approach bad?