That's not what Thomas said.  The wildcard type ? super Manager can be
resolved to Manager or any supertype.  Remember that even without
wildcards, you could still pass in an Executive reference to a function
that expects a Manager, because a reference of type Executive is
assignable to the more general type Manager.  Therefore, it's safe to
pass in an Executive to a function expecting <? super Manager>
specifically because the function can't be expecting anything more
specific than Manager.

super and extends are exact opposites in wildcard expressions.  One
establishes an upper bound, while the other establishes a lower bound.

...

...

...

...

Notice that there are three kinds of types being used here.

Take this example:
Set<? super Manager> someSet = new HashSet<Employee>();
someSet.add(new Executive("John Smith");

You can see Set<? super Manager> as a kind of "type pattern".
It is not a type of a value in itself, but rather it specifies a
set of possible types { Set<X> | X is a supertype of Manager }
(where supertypes of Manager in this example are only Manager itself,
Employee and Object - for simplicity we include a class as a trivial
supertype of itself :).

You can assign any value to someSet that has a type in this set.
HashSet<Employee> is one possible value. HashSet<Manager> is another.

Notice that you cannot write
new HashSet<? super Manager>
The type parameter must be an actual type, not just a set of types.
This is somewhat similar to how you can't call a method with a type
as argument, only with an actual value of that type.


The choice of parameter type for HashSet also affects the signatures of
its methods. One example is the put method, which for HashSet<Employee>
has signature
 void put(Employee value)

Since Executive is a subclass of Employee, an instance of Executive
can be used as parameter of type Employee. This is the fundamental
substitution property of class based languages: an instance of a
subclass can be used everywhere the superclass can be.

In the above example, we don't know the exact type of the variable
someSet, only the set of types that it might have. So we don't know
the exact signature of "put", just that it is
 void put(T value)
where T is some supertype of Manager. So we don't know exactly what
objects can be used as parameters to it. We do know that the type
is a supertype of Manager, so any instance of Manager, or any subtype
of Manager, must be elements of that type. This is why the compiler
only allows objects that are Managers.

It seems a little backwards: the type must be a superclass, so the
value must be of a subclass. But when you understand it, it's really
the only thing that makes sense :)

/L 'what is the type of a type parameter?'