Java中Generic类的两种不同特化之间的比较

Question

I am implementing a priority queue of custom objects. The custom object class looks like below, would it be recommended to implement it as a generic class, where T simply is a payload associated with the messageId?

public class PriQMsgPayload <T> implements Comparable<PriQMsgPayload<T>>{


    private Integer mMsgNum;
    private T ExtraDataForMsg = null;

    public PriQMsgPayload(T extra, PluginConfig.PriQMessage msg)
    {
        mMsgNum= msg;
        ExtraDataForMsg = extra;
    }

    @Override
    public int compareTo(PriQMsgPayload<T> another) {
        return mMsgNum.compareTo(another.mMsgNum);
    }
}

My doubt: in below mentioned case, I first insert the P1 specialized for Integer and when I insert another object P2 which is specialized for MyClass, would the comparator not get confused?

PriQMsgPayload<Integer> P1 = new PriQMsgPayload<Integer>(2, 1);
PriQMsgPayload<MyClass> P2 = new PriQMsgPayload<MyClass>(new MyClass(), 2);

Answer 1

I don't think there's any point. The problem comes when you try to put the objects into the queue - there is no fully-cooked type that the queue can have which allows it to contain both of these!

Consider:

PriorityQueue queue; // works, but is raw
PriorityQueue<PriQMsgPayload> queue; // works, but is partially raw
PriorityQueue<PriQMsgPayload<Object>> queue; // won't accept either object

You can put them into a queue of this type (i initially said you couldn't, but @newacct kindly corrected me) :

PriorityQueue<PriQMsgPayload<?>> queue; // won't accept either object

But that involves throwing away the type information about what kind of extra data you have.

None of the queue types which let you add both objects preserve the type of the extra data; that means that when you got the objects out again, you would have lost all type information. There's no way to write code that safely extracts the object as a PriQMsgPayload<Integer> rather than a PriQMsgPayload<MyClass> .

Answer 2

Well, ideally, you shouldn't be able to compare a PriQMsgPayload<Integer> with a PriQMsgPayload<String> -- since a PriQMsgPayload<Integer> implements Comparable<PriQMsgPayload<Integer>> , and thus its compareTo method takes a PriQMsgPayload<Integer> , so it does not expect a PriQMsgPayload<String> .

What happens when you try to do this, both at compile time and at runtime, depends on how your priority queue class is declared, and how it works. You did not tell us what implementation of priority queue you are using.

Suppose you had a generic priority queue class that is declared like this:

class MyPriorityQueue<E extends Comparable<? super E>> { ... }

ie it requires its type parameter is comparable to itself. Then it would be impossible to declare a priority queue that you would be able to insert both PriQMsgPayload<Integer> and PriQMsgPayload<String> into; because eg MyPriorityQueue<PriQMsgPayload<?>> would not be allowed because PriQMsgPayload<?> does not satisfy the bounds.

If you are using java.util.PriorityQueue , the problem is that the PriorityQueue class (along with TreeSet and TreeMap , etc.) are not type-safe. You could create a new PriorityQueue<Object>() , and then insert whatever kinds of objects into it (completely non-comparable ones), and it would not catch anything at compile time, failing only at runtime (or it might happen to work, depending on the types of objects).

What happens at runtime in this case? Well, after type erasure, at runtime, the class is equivalent to this:

public class PriQMsgPayload implements Comparable {
    // ....
    public int compareTo(Object another) {
        return compareTo((PriQMsgPayload)another);
    }
    public int compareTo(PriQMsgPayload another) {
        return mMsgNum.compareTo(another.mMsgNum);
    }
}

It simply compares the integers, and so in this case, at runtime, it will work fine.

Why is PriorityQueue not type safe? Well, if you look at the class, it's designed to be used in one of two ways: you can provide a custom Comparator , or it will use the "natural ordering" of the objects. If the latter, you are supposed to provide things that are comparable to themselves, but this is not enforced at compile time in any way. Because you can use it with a custom comparator (way #1), which works for any type, they cannot put any bounds on the type parameter of the class, like we did with MyPriorityQueue above.

Actually, there is a way to make PriorityQueue type-safe, and still be able to support both custom comparators and natural ordering modes. Simply remove the constructors that use natural ordering (leaving the ones that use a comparator, since those are type-safe), and instead replace them with factory methods. For example, the constructor

PriorityQueue(int initialCapacity)

can be replaced by the factory method

public static <T extends Comparable<? super T>> PriorityQueue<T> construstUsingNaturalOrdering(int initialCapacity) {
    return new PriorityQueue<T>(initialCapacity, new NaturalOrderingComparator<T>());
}

That way, the generics bound on the factory method ensures that natural ordering priority queues can only be constructed for types that are comparable to themselves. I don't know why the Java library designers didn't do it this way.

Answer 3

What exactly do you mean?

You cannot call compareTo() on P1 passing P2 as an argument (or vice versa); that would give you a compile error, because P1.compareTo() expects a PriQMsgPayload<Integer> , so you cannot pass a PriQMsgPayload<MyClass> .