Why does Collections.sort(List<T>) have the signature :
public static <T extends Comparable<? super T>> void sort(List<T> list)
and not :
public static <T extends Comparable<T>> void sort(List<? extends T> list)
I understand that they both would serve the same purpose; so why did the framework developers use the first option?
Or are these declarations really different?
Your proposed signature would probably work in Java-8. However in previous Java versions type inference was not so smart. Consider that you have List<java.sql.Date>. Note that java.sql.Date extends java.util.Date which implements Comparable<java.util.Date>. When you compile
List<java.sql.Date> list = new ArrayList<>();
Collections.sort(list);
It perfectly works in Java-7. Here T is inferred to be java.sql.Date which is actually Comparable<java.util.Date> which is Comparable<? super java.sql.Date>. However let's try your signature:
public static <T extends Comparable<T>> void sort(List<? extends T> list) {}
List<java.sql.Date> list = new ArrayList<>();
sort(list);
Here T should be inferred as java.util.Date. However Java 7 specification does not allow such inference. Hence this code can be compiled with Java-8, but fails when compiled under Java-7:
Main.java:14: error: method sort in class Main cannot be applied to given types;
sort(list);
^
required: List<? extends T>
found: List<Date>
reason: inferred type does not conform to declared bound(s)
inferred: Date
bound(s): Comparable<Date>
where T is a type-variable:
T extends Comparable<T> declared in method <T>sort(List<? extends T>)
1 error
Type inference was greatly improved in Java-8. Separate JLS chapter 18 is dedicated to it now, while in Java-7 the rules were much simpler.
// 0
public static <T extends Comparable<? super T>> void sort0(List<T> list)
// 1
public static <T extends Comparable<T>> void sort1(List<? extends T> list)
These signatures differ because they impose different requirements on the relationship between type T and the type argument to Comparable in the definition of T.
Suppose for example that you have this class:
class A implements Comparable<Object> { ... }
Then if you have
List<A> list = ... ;
sort0(list); // works
sort1(list); // fails
The reason sort1 fails is that there is no type T that is both comparable to itself and that is, or is a supertype of, the list's type.
It turns out that class A is malformed, because objects that are Comparable need to meet certain requirements. In particular reversing the comparison should reverse the sign of the result. We can compare an instance of A to an Object but not vice-versa, so this requirement is violated. But note that this is a requirement of the semantics of Comparable and is not imposed by the type system. Considering only the type system, the two sort declarations really are different.
They differ because ? super T is less restrictive than T. It is a Lower Bounded Wildcard (the linked Java Tutorial says, in part)
The term List<Integer> is more restrictive than List<? super Integer> because the former matches a list of type Integer only, whereas the latter matches a list of any type that is a supertype of Integer.
Replace Integer with T and it means a T or a java.lang.Object.
Related
I was working on a problem involving Stacks on HackerRank (See Here). One of the parts of the question asked to provide the max value within the Stack. I thought an easy way to do this was to just write an extended Stack class with a max() method (see below). That worked but I thought an even easier way might be to just take advantage of Java's Collections methods. So I built the craftyMax() method (also seen below).
class MyStack<T> extends Stack<T> {
public T craftyMax() {
return Collections.max(this);
}
public T max() {
Integer max = Integer.MIN_VALUE;
for (T item: this) {
max = Math.max((Integer)item, max);
}
return (T) max;
}
}
Of course this did not work as the compiler replied with:
Solution.java:6: error: no suitable method found for max(MyStack<T#1>)
return Collections.max(this);
^
method Collections.<T#2>max(Collection<? extends T#2>) is not applicable
(inferred type does not conform to upper bound(s)
inferred: T#1
upper bound(s): Comparable<? super T#1>,Object)
method Collections.<T#3>max(Collection<? extends T#3>,Comparator<? super T#3>) is not applicable
(cannot infer type-variable(s) T#3
(actual and formal argument lists differ in length))
where T#1,T#2,T#3 are type-variables:
T#1 extends Object declared in class MyStack
T#2 extends Object,Comparable<? super T#2> declared in method <T#2>max(Collection<? extends T#2>)
T#3 extends Object declared in method <T#3>max(Collection<? extends T#3>,Comparator<? super T#3>)
Note: Solution.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
Since, I have tried a few different things and been looking around but I can't seem to find if what I am trying to do here is possible or not. So my question is:
Is it possible to use the provided Java Collections methods, like max, min, sort, ect..., on / within a Stack? Or am I expecting a little too much?
public static <T extends Object & Comparable<? super T>> T max(Collection<? extends T> coll)
only works for Collections whose element type implements the Comparable interface.
Therefore, your code will work with the proper type bound:
class MyStack<T extends Comparable<T>> extends Stack<T> {
public T craftyMax() {
return Collections.max(this);
}
}
I'm not sure about your second method (max()), though. You are casting T to Integer. If you are certain T is an Integer, why not define MyStack as class MyStack extends Stack<Integer>?
You can only call Collections.max with a single argument on types that implement the Comparable interface. Change your type declaration to
class MyStack<T extends Comparable<T>> extends Stack<T> {
and it should work. Or, as an alternative, you can take the two-argument max that takes a Comparator as the second argument.
you can override the comparator to match your functionality like below.
if (!MyStack.isEmpty()) {
Integer max = Collections.min(MyStack, new Comparator<Integer>() {
#Override
public int compare(Integer o1, Integer o2) {
return o2.compareTo(o1);
}
});
}
TreeSet(Collection<? extends E> c) constructor was defined as:
Constructs a new tree set containing the elements in the specified collection, sorted according to the natural ordering of its elements. All elements inserted into the set must implement the Comparable interface. Furthermore, all such elements must be mutually comparable: e1.compareTo(e2) must not throw a ClassCastException for any elements e1 and e2 in the set.
Is it possible syntactically enforce that E in Collection<? extends E> implements Comparable? In above JavaDoc this check postponed to execution time...
Yes, but not with constructors; you'd have to expose a factory method, which can impose constraints on the collection type beyond those imposed by the class as a whole. For example, they could've written
public class TreeSet<E> { ...
public static <E extends Comparable<? super E>> TreeSet<E>
create(Collection<? extends E> collection) {
TreeSet<E> set = new TreeSet<E>();
set.addAll(collection);
return set;
}
...
}
You can make your project require this by using a factory method like this:
public static <T extends Comparable<? super T>> SortedSet<T> safeSortedSet() {
return new TreeSet<T>();
}
Then is code:
Set<String> pass = safeSortedSet();
Set<Foo> fail = safeSortedSet();
Second line produces compile error:
Error:(99, 38) java: incompatible types: inference variable T has incompatible bounds
equality constraints: Test.Foo
upper bounds: java.lang.Comparable
From Tavian Barnes comment:
They could have done class TreeSet<E extends Comparable<? super E>>, but then you wouldn't have been able to use custom comparators for unorderable types. I can't think of a good way to enforce this only on a single constructor
So it is possible with <E extends Comparable<? super E>> syntax, but unfortunately each generic extends / super syntax make ultimate restriction on any other type declaration with E.
In case TreeSet look to Creating a TreeSet with a non-Comparable class: why a run-time exception, rather than compile-time error?
Thanks for all who helps with answer!
I have the following Java class definition:
import java.util.*;
public class Test {
static public void copyTo(Iterator<? extends Number> it, List<? extends Number> out) {
while(it.hasNext())
out.add(it.next());
}
public static void main(String[] args) {
List<Integer> in = new ArrayList<Integer>();
for (int i = 1; i <= 3; i++) {
in.add(i);
}
Iterator<Integer> it = in.iterator();
List<Number> out = new ArrayList<Number>();
copyTo(it, out);
System.out.println(out.size());
}
}
That's it, I define the method copyTo using wildcards in Java. I define List<Number> out but Iterator<Integer> it. My thinking is I can define the iterator as Iterator<? extends Number> and that would type match. However that's not the case:
Test.java:13: error: no suitable method found for add(Number)
out.add(it.next());
^
method List.add(int,CAP#1) is not applicable
(actual and formal argument lists differ in length)
method List.add(CAP#1) is not applicable
(actual argument Number cannot be converted to CAP#1 by method invocation conversion)
method Collection.add(CAP#1) is not applicable
(actual argument Number cannot be converted to CAP#1 by method invocation conversion)
where CAP#1 is a fresh type-variable:
CAP#1 extends Number from capture of ? extends Number
1 error
So I went ahead and I defined yet another definition for the copyTo method:
static public void copyTo(Iterator<? super Integer> it, List<? super Integer> out) {
while(it.hasNext())
out.add(it.next());
}
It doesn't work either. What would be the correct say of using wildcards in this case?
First of all you want to impose a constraint by adding a type variable to the method itself since by using wildcards you can't impose a constraint between the two arguments, then you must thing about variance of the types involved in your method:
you want as an input an Iterator<X> where X is at least the type of the numeric type you want to copy (or a subtype)
you want as output a List where Y is at most the type of the numeric type (or a super type)
These constraints are different and must be expressed differently:
static public <T> void copyTo(Iterator<? extends T> it, List<? super T> out) {
while(it.hasNext())
out.add(it.next());
}
Which is basically "I accept an Iterator of T or a subtype of T and I output to a List of T or a supertype of T"
If a method signature involves two or more wildcards, and the logic of your method requires them to be the same, you need to use a generic type parameter instead of wildcards.
static public <T extends Number> void copyTo(Iterator<? extends T> it, List<? super T> out) {
while(it.hasNext())
out.add(it.next());
}
Here I have used PECS (producer extends, consumer super). out is consuming Ts (so super), whereas the iterator is producing Ts, so extends.
EDIT
As #Cinnam correctly points out in the comments, you can get away with
static void copyTo(Iterator<? extends Integer> it, List<? super Integer> out)
These signatures are effectively equivalent because Integer is final, so any class that is a super class of some class extending Integer must be a super class of Integer.
However, the two signatures are not equivalent as far as the compiler is concerned. You can test this by trying
static <T extends Number> void copyTo1(Iterator<? extends T> it, List<? super T> out) {
copyTo2(it, out); // doesn't compile
}
static void copyTo2(Iterator<? extends Integer> it, List<? super Integer> out) {
copyTo1(it, out);
}
This does not compile, showing that as far as the compiler is concerned, the version with the type parameter is more general.
We have made in a tutorial an example with the following signture (as part of an interface)
<T> List<Comparable<T>> sort(Collection<Comparable<T>> c, boolean ascending);
We have found it nearly impossible to implement that method without warnings:
public <T> List<Comparable<T>> sort(Collection<Comparable<T>> c, boolean ascending) {
List<T> list = new ArrayList<T>();
Collections.sort(list);
return list;
}
The error in the line Collections.sort(list) we get is:
Bound mismatch: The generic method sort(List<T>) of type Collections is not
applicable for the arguments (List<T>). The inferred type T is not a valid
substitute for the bounded parameter <T extends Comparable<? super T>>
However, it works for the following signature:
<T extends Comparable<T>> List<T> sort(Collection<T> c, boolean ascending);
With that signature, the code above (implementation of sort) just works as expected. I would like to know what is the reason for that.
A list of Comparable<T>s is a list of objects which are comparable with Ts. One could not say if these objects themselves are Ts. Thus it's impossible to compare two elements with each other.
Ts, which happen to be comparable with other Ts, can be compared with each other. And so sorting a list of such Ts is possible.
Collections.sort expects a List<T extends Comparable<? super T>>, i.e. the compiler needs to be able to tell that the element type T of the list it is sorting extends Comparable<E> where E is T, a superclass of T or an interface implemented by T. Your first signature with public <T> List<Comparable<T>> sort doesn't enforce this, so you can't Collections.sort a List<T>. You could make it work by saying
List<Comparable<T>> list = new ArrayList<Comparable<T>>();
to match the type that your sort method returns, but the problem with this is that it's rather inflexible - it can only sort a Collection<Comparable<Foo>>, not a Collection<Bar> where Bar implements Comparable<Foo>. The most flexible approach would be to stick with the new ArrayList<T>() but use a signature like
<T extends Comparable<? super T>> List<T> sort(Collection<T> c, boolean ascending);
which places the minimum restriction on T to make the sort valid - it would work with Bar extends Foo implements Comparable<Foo>, which your second signature doesn't allow (that would require Bar implements Comparable<Bar>).
I can't find any example where wildcards can't be replaced by a generic.
For example:
public void dummy(List<? extends MyObject> list);
is equivalent to
public <T> void dummy(List<T extends MyObject> list);
or
public <T> List<? extends T> dummy2(List<? extends T> list);
is equivalent to
public <T, U> List<U extends T> dummy(List<U extends T> list);
So I don't undertand why wildcard was created as generics is already doing the job. Any ideas or comments?
Nope, it is not always replaceable.
List<? extends Reader> foo();
is not equivalent to
<T> List<T extends Reader> foo();
because you don't know the T when calling foo() (and you cannot know what List<T> will foo() return. The same thing happens in your second example, too.
The demonstration of using wildcards can be found in this (my) answer.
An easy answer is that, deeper level wildcards can't be replaced by a type variable
void foo( List<List<?>> arg )
is very different from
<T>
void foo( List<List<T>> arg)
This is because wildcard capture conversion is only applied to 1st level wildcards. Let's talk about these.
Due to extensive capture conversion, in most places, compiler treats wildcards as if they are type variables. Therefore indeed programmer can replace wildcard with type variables in such places, a sort of manual capture conversion.
Since a type variable created by compiler for capture conversion is not accessible to programmer, this has the restricting effect mentioned by #josefx. For example, compiler treats a List<?> object as a List<W> object; since W is internal to compiler, although it has a method add(W item), there's no way for programmer to invoke it, because he has no item of type W. However, if programmer "manually" converts the wildcard to a type variable T, he can have an item with type T and invoke add(T item) on it.
Another rather random case where wildcard can't be replaced type variable:
class Base
List<? extends Number> foo()
class Derived extends Base
List<Integer> foo()
Here, foo() is overriden with a covariant return type, since List<Integer> is a subtype of List<? extends Number. This won't work if the wildcard is replaced with type variable.
There is a usage difference for your examples.
public <T> List<? extends T> dummy2(List<? extends T> list);
returns a list that can contain an unknown subtype of T so you can get objects of type T out of it but can't add to it.
Example T = Number
List<? extends Number> l = new ArrayList<Integer>(Arrays.asList(new Integer(1)));
//Valid since the values are guaranteed to be a subtype of Number
Number o = l.get(0);
//Invalid since we don't know that the valuetype of the list is Integer
l.add(new Integer(1));
So the wildcard can be used to make some operations invalid, this can be used by an API to restrict an interface.
Example:
//Use to remove unliked numbers, thanks to the wildcard
//it is impossible to add a Number
#Override public void removeNumberCallback(List<? extends Number> list){
list.remove(13);
}