如何确保只使用covariantly类型参数？

Question

Suppose I have a generic interface Source<T> which is a pure producer of T objects. Being a pure producer is part of the contract of the interface. So it is a reasonable expectation that whatever you can do with a Source<Foo> , should be also possible to do if you have a Source<? extends Foo> Source<? extends Foo> .

Now I need to enforce this restriction in the body of Source , so that someone does not accidentally use T in a way that contradicts that contract.

An example from the JDK

As @Miserable.Variable points out, ArrayList<Integer> and ArrayList<? extends Integer> ArrayList<? extends Integer> are not equivalent. That's because ArrayList is not covariant as a generic type. Or in other words, ArrayList<T> is not a pure producer of T ; specifically, the ArrayList method add(T) consumes a T .

But there are generic types that are pure producers, like Iterator or Iterable . Whatever you can do with an Iterator<Integer> you can also do with an Iterator<? extends Integer> Iterator<? extends Integer> . There is no method like ArrayList.add(T) in Iterator<T> .

I just want to make sure that my interface Source<T> is like Iterator<T> rather than like ArrayList<T> . If someone in the future adds a T -consuming method (like add(T) ) to my interface, I want them to get an explicit error.

A more complex example

Simply banning parameters of type T from appearing in the interface is not a full solution. One should also note that T might be used as argument to other generic types. For example, the following method should not be allowed in Source<T> :

public void copyTo(List<T> destination);

because an sneaky subclass may try to read from the list, it is considered a T -consumer; you cannot call this method on a Source<? extends Foo> Source<? extends Foo> . On the other hand, this one should be allowed:

public void copyTo(List<? super T> destination);

(There is also another rule that says methods in Source<T> cannot return a List<T> , but can return a List<? extends T> .)

Now, the actual interface can be arbitrarily complex with lots of methods, and the rules are pretty complex themselves. It is very easy to make a mistake. So I want to automate this check.

Is there a unit-testing trick, static analyzer, compiler/IDE plugin, annotation processor (for example with an @Covariant annotation on T ), or any other technique or tool that can ensure this for me?

Answer 1

This is not an answer, but too long to fit in a comment.

So it is a reasonable expectation that whatever you can do with a Source<Foo> , should be also possible to do if you have a Source<? extends Foo> Source<? extends Foo>

No, it is not a reasonable expectation. You linked to an entire pdf and it goes to a top level page so it is unclear how you determined this is reasonable, but in general you cannot arbitrarily replace a Foo<T> with a Foo<? extends T> Foo<? extends T> . Foe example, if you have an ArrayList<Integer> a you can call a.Add(Interger.valueOf(5)) but you cannot do that if a is ArrayList<? extends Integer> a ArrayList<? extends Integer> a .

It is also unclear what are Consumer<T> and sendTo . Is the latter a method in Source<T> >?

Without these clarifications, I am afraid he question is ambiguous.

Answer 2

Well, if you don't want to have any put() method in your interface, all you have to do is not to write any and leave a comment to that effect somewhere in the code; preferably with a lot of asterixes around it.

Honestly, I don't understand at all the usefulness of having a feature that would give a language the possibility of blocking some contravariant methods to a class or an interface. This is the responsability of the programer, not the compilator.

It's the same thing as if you would ask for a feature that would give you the possibility of blocking the addition of any function that would accept an Integer as one of its parameter or as its return value. Having such a feature in a language would be totally useless in my opinion.

Answer 3

Maybe not the answer you are looking for, but I guess you could enforce it in your interface declaration.

Enfoce Contravariant Use

public interface Consumer<T, S extends T> {
   public void consume(S item);
}

public static class ConsumerImpl<T, S extends T> implements Consumer<T, S> {

   private List<? super S> items = new ArrayList<T>();

   public void consume(S item) {
      this.items.add(item);
   }

}

Then you could use it like this:

Consumer<Object, String> consumer = new ConsumerImpl<Object, String>();
consumer.consume("Whatever");
consumer.consume("Another");

Enforce Covariant Use

The contrary, of course, is also possible:

public interface Producer<T, S extends T> {
   public T produce();
}

public static class ProducerImpl<T, S extends T> implements Producer<T,S> {

   private Deque<? extends T> items = new ArrayDeque<S>();

   public ProducerImpl(Deque<S> items) {
      this.items = items;
   }

   public T produce() {
      return items.pop();
   }

}

And you could use it like this:

Deque<Integer> myInts = new ArrayDeque<Integer>();
myInts.push(1);
myInts.push(2);

Producer<Number, Integer> producer = new ProducerImpl<Number, Integer>(myInts);
Number n1 = producer.produce();
Number n2 = producer.produce();

In both cases I have enforced that the underlying structure is either contravariant or covariant.