The JLS third edition being written is taking an approach to wildcard capture
that makes its use pervasive in rvalue contexts even when no generic method is
being called.  This solves a number of thorny problems both in the specification
and in existing APIs that want to take advantage of generics.  See, for example,
4916563, 4976895, 4916650.
See also <http://forum.java.sun.com/thread.jsp?forum=316&thread=499114>.
See also <http://forum.java.sun.com/thread.jsp?forum=316&thread=512445>.

However, javac implements a much simpler scheme
based on substitution and rewriting member types.  javac must be changed to
obey the specification and support the general wildcard capture mechanism,
also known informally as snapshotting.

In addition to those three bugs, there is one case of a signature in
java.util.Collections that is more complex than necessary to work around
this problem.  We have

public static <T> void copy(List<? super T> dest, List<? extends T> src);

With the addition of support for snapshotting, this can be rewritten

public static <T> void copy(List<T> dest, List<? extends T> src);

A method with the former signature should be able to call one with the latter
signature - the call is typesafe - and snapshotting should allow the compiler
to support this.

If this can be implemented in time for Tiger, the signature for
Collections.copy should be simplified.

The following program should compile with no errors:

import java.util.*;

class C {
    public static <T> void copy1(List<? super T> dest, List<? extends T> src) {
        copy1(dest, src);
        copy2(dest, src); // oops
        copy3(dest, src); // oops
    }
    public static <T> void copy2(List<T> dest, List<? extends T> src) {
        copy1(dest, src);
        copy2(dest, src);
        copy3(dest, src); // oops
    }
    public static <T> void copy3(List<? super T> dest, List<T> src) {
        copy1(dest, src);
        copy2(dest, src); // oops
        copy3(dest, src);
    }
}