Yes, you got it, except for two improvements. Firstly, you can get rid of the two extra type parameters when you declare the bounds on the actual method parameters using wildcards. Secondly,
Collection is already too limiting. You only iterate over them, so you only need
Iterable.
Here's how you tackle problems like these. Start with the return type. Usually it doesn't make much sense to have type bounds in your return type, so you can use it as an anchor to reason about other stuff:
Now, let's fill in the missing type arguments. We'll work from the inside out.
The only thing we do with
values is get elements of type
V out of it. That means that we don't care what type
values is exactly, as long as we can get *some* type out of it that extends
V:
Iterable<? extends V>.
What kind of
Entry are we working with? We get keys out of it, and we really don't care about what type of key, as long as it is *some* subtype of
K. As for the type of the value, we've seen that we need
Iterable<? extends V>. Must it be exactly
Iterable? We don't care, it might be a
Set or
List or *anything* else, as long as it extends
Iterable. The final result is
Entry<? extends K, ? extends Iterable<? extends V>>.
The map obviously has the same type arguments as the entry. What's left is the comparator. We want to compare values, but does it really matter that we must compare elements of type
V exactly? If we have a way of comparing any class of objects that
V falls under, we're happy as well. So we want a
Comparator of *any* type, as long as that type is a supertype of
V. The final result:
It's pretty much the same answer you got, except it gets rid of the extra type parameters in favor of wildcards. The reason you can't use type parameters with a lower bound is because the language designers figured their use was so limited that it wasn't worth the time and effort of implementing them.
As a bonus, this is how I would do it with
Java 8: