There are a number of question on Stack Overflow about sorting Generics; however, I am interested in sorting Generics in the simplest way: nothing nested. The code I have below is an attempt to sort a generic set - or, list - of elements.
List<E> l = new LinkedList<>(arbSet);
Collections.sort(l);
arbSet is just a set of elements: Set<E> arbSet.
Clearly, this is problematic - it shouldn't work. To make sure I know this, Eclipse gives me the following for my attempt to call .sort:
Bound mismatch: The generic method sort(List < T >) of type Collections is not applicable for the arguments (List < E >). The inferred type E is not a valid substitute for the bounded parameter < T extends Comparable < ? super T >>
So, I do a bit of documentation consultation, looking at sort's specifications.
As a result, I attempt to ensure that sort knows E extends Comparable:
The first line now looking like:
List<E extends Comparable<? super E>> l = new LinkedSet<>(arbSet);
Now, Eclipse states :
Syntax error on token "extends", , expected
What am I missing? I feel like this is a very basic example and that I am just missing something "palm-to-face" esque. Just to simplify it even further, all arbSet elements are elements which implement the Comparable interface.
You can use Collections.sort() only if you provide a custom Comparator or if the elements you are trying to sort implement the Comparable interface. So it depends on what elements are stored in arbSet.
For example, if you wanted to create a method that accepts a set, and returns a list with the set elements sorted, you would do something like this:
static <E extends Comparable<E>> List<E> sortedListFrom(Set<E> set) {
List<E> l = new LinkedList<>(set);
Collections.sort(l);
return l;
}
Edit:
If you want to do this inside a constructor you have two options:
Declare the type E just before the constructor. Of course, this won't do much, since list is lost after the constructor finishes.
class Test {
<E extends Comparable<E>> Test(Set<E> arbSet) {
List<E> list = new LinkedList<>(arbSet);
Collections.sort(list);
System.out.println(list);
}
}
Declare the type E in the class, so you can store the result in a attribute.
class Test<E extends Comparable<E>> {
List<E> list;
Test(Set<E> arbSet) {
this.list = new ArrayList<>(arbSet);
Collections.sort(this.list);
System.out.println(this.list);
}
}
Related
The code i did do not work for collection. is there other way to sort an object arraylist? or how to sort it using collection.sort?
Object [] objects = BookAnalyser.array.toArray();
ArrayList<Object> uniqueword = new ArrayList<Object>();
for (Object h: BookAnalyser.WordList.findUnique(objects, objects)){
if(h != null ) {
uniqueword.add(h);
}
}
Collections.sort((uniqueword)); //Error: The method sort(List<T>) in the type Collections is not applicable for the arguments (ArrayList<Object>)
for(Object j : uniqueword) {
System.out.print(j+ " ");
}
It shows The method sort(List) in the type Collections is not applicable for the arguments (ArrayList). Normally it would work just fine.
You are trying to sort a List<T> where T is Object.
The definition of Collections.sort is
static <T extends Comparable<? super T>> void sort(List<T> list)
which means the type parameter must implement Comparable<? super T>, which Object does not.
Two solutions:
Make uniqueword a list of some type implementing Comparable, such as String
Provide your own custom Comparator<Object>, but you'll have to downcast to something that can be compared, so the first option (List<String> for example) is much preferred.
having
class BaseClass implements IData ();
class ChildClassA() extends BaseClass;
class ChildClassB() extends BaseClass;
since cannot do
List<BaseClass> aList = new ArrayList<ChildClassA>()
so there is a
List<? extends IData> aList
for pointint to either
ArrayList<ChildClassA>(),
or
ArrayList<ChildClassB>()
the aList is built by other routing at runtime, and that part of code has a function to take a List<IData> from the the aList
the question is if the List<? extends IData> aList is point to ArrayList<ChildClassA>() or ArrayList<ChildClassB>(),
can it do ListData<IData> outputList = (List<IData>) aList? something like below:
(seems it is working, but not sure if there is better way to assign the generics array other than casting.)
Edit: the output of the List<IData> outputList is for read only use (immutable), no insert/delete on it, it will only iterate the IData to react on what the IData really is.
List<? extends IData> aList = new ArrayList<ChildClassA>();
ListData<IData> outputList = (List<IData>)aList
List<? extends IData> aList = new ArrayList<ChildClassB>();
ListData<IData> outputList = (List<IData>)aList
tl;dr Use Collections#unmodifiableList:
List<IData> outputList = Collections.unmodifiableList(aList);
For more information on this topic, you might want to get familiar with the PECS principle.
It's not possible, because the two types are incompatible.
A List<BaseClass> is just what it is declared, a list of BaseClass objects. More precisely, it makes two guarantees:
objects retrieved from it are assignable to BaseClass
every object that is assignable to BaseClass can be added to it (and no other)
A List<? extends BaseClass> is a more loose declaration. Precisely, it simply does not make the second guarantee. However, not only the guarantee is gone, but it is now impossible to add items to it, since the exact generic type of the list is undefined. It might even change for the same list declaration (not the same list object) at runtime.
As a consequence, a List<? extends BaseClass> is not assignable to a List<BaseClass>, since the latter makes a guarantee the first is unable to fulfill.
Practically speaking, consider the following method:
public List<BaseClass> makeList() {
// TODO implement method
return null;
}
If someone implements this method, returning a List<? extends BaseClass>, a client using this method would be unable to add items to it, although its declaration indicates otherwise.
Because of that, such an assignment results in a compilation error.
To fix the example problem the loose declaration can be added to the method:
public List<? extends BaseClass> makeList() {
// TODO implement method
return null;
}
This will signal every client, that the list returned from this method is not meant for adding items to it.
Now let's get back to your use case. In my opinion the most appropriate fix is to the rephrase the function that
take[s] a List from the the aList.
As it seems it is currently declared as
public void useList(List<BaseClass> list);
but since it does not add items to the list, it should be declared as
public void useList(List<? extends BaseClass> list);
However, if that method is part of a currently unchangeable API, you can still do:
List<? extends BaseClass> list;
....
List<BaseClass> tmp = Collections.unmodifiableList(list);
useList(tmp);
No, it is unsafe.
After that cast it would be legit to add to the list that is supposed to contain only ChildClassA typed elements, element of the other child type ChildClassB type and vice-versa.
We can simply your code a bit to make it more obvious why this should not be allowed:
List<ChildClassA> aList = new ArrayList<ChildClassA>();
aList.add(a1);
aList.add(a2);
//...
List<IData> iDataList = (List<IData>) aList;
iDataList.add(b1);
iDataList.add(b2);
//...
for (ChildClassA a : aList) {
// a some point a is going to be assigned b1 or b2 and they results in cast
// exception.
}
Note that iDataList makes reference to the very same list object as aList.
If that cast was allowed then you would be able to add elements to aList that are not ChildClassA instances.
The best solution is on the details.
If the problem is that a third-party library requires a List<IData> typed reference and as long as it is only for reading you can use a unmodifiable proxy as returned by Collections.unmodifiableList:
import java.util.Collections;
//...
final List<ChildClassA> aList = new ArrayList<>();
//... add stuff to aList
final List<IData> readOnlyIDataList = Collections.unmodifiableList(aList);
//... read only access operations readOnlyIDataList
This is part of the Java (1.6) Collection interface:
public interface Collection<E> extends java.lang.Iterable<E> {
/* ... */
boolean containsAll(java.util.Collection<?> objects);
boolean addAll(java.util.Collection<? extends E> es);
boolean removeAll(java.util.Collection<?> objects);
boolean retainAll(java.util.Collection<?> objects);
/* ... */
}
Why does addAll have <? extends E> while removeAll has <?>
I did not know, I googled. I got this explaination here: http://www.ibm.com/developerworks/java/library/j-jtp01255/index.html
Copying the part:
One element of the generifed Collections API that is often confusing at first is the signatures of containsAll(), removeAll(), and retainAll(). You might expect the signatures for remove() and removeAll() to be:
interface Collection<E> {
public boolean remove(E e); // not really
public void removeAll(Collection<? extends E> c); // not really
}
But it is in fact:
interface Collection<E> {
public boolean remove(Object o);
public void removeAll(Collection<?> c);
}
Why is this? Again, the answer lies in backward compatibility. The interface contract of x.remove(o) means "if o is contained in x, remove it; otherwise, do nothing." If x is a generic collection, o does not have to be type-compatible with the type parameter of x. If removeAll() were generified to only be callable if its argument was type-compatible (Collection<? extends E>), then certain sequences of code that were legal before generics would become illegal, like this one:
// a collection of Integers
Collection c = new HashSet();
// a collection of Objects
Collection r = new HashSet();
c.removeAll(r);
If the above fragment were generified in the obvious way (making c a Collection<Integer> and r a Collection<Object>), then the code above would not compile if the signature of removeAll() required its argument to be a Collection<? extends E>, instead of being a no-op. One of the key goals of generifying the class libraries was to not break or change the semantics of existing code, so remove(), removeAll(), retainAll(), and containsAll() had to be defined with a weaker type constraint than they might have had they been redesigned from scratch for generics.
For any collection containing elements of type E, addAll must be able to deal with input collections not just of E, but all of its subclasses as well. Hence <? extends E>. Without this, you could not add all elements of a List<Integer> to a List<Number>, which would clearly not be right.*
For removal, the limits need not be so strictly set, and there is no harm in trying to remove elements of a collection of some totally unrelated type. E.g. you can have a collection of Numbers, about which you happen to know that it only contains Integers, so passing it to removeAll on a List<Integer> should work fine, and it would be stupid for the compiler to disallow this.
Note that according to the Javadoc, removeAll may optionally throw a ClassCastException, depending on implementation.
*The reason behind this is that in Java, generics are invariant. For more details, see e.g. this thread.
<?> is less restrictive than <? extends E>.
There is nothing wrong with removing an orange from a collection of apples; there are a lot of things wrong with adding an orange to a collection of apples.
When you add item to your collection you want to be sure that they do have a certain type.
When you remove them, only those in the collection are removed. Regardless of their type.
Java implements generics through erasure. These info are only for compilation time only. I guess the java collection designers did this to retain more ascendent compatibility with pre-generics java version.
when you add an object, it needs to be a subclass (or sub-subclass, etc.) of the main type. When you remove an object, it returns it as the type oc the collection. This is a good example of polymorphism in action.
A simple example to illustrate what has been said:
public class Test {
public static void main(String[] args) {
List<String> l = new ArrayList<String>();
System.out.println(l.remove(new Object())); //false
System.out.println(l.contains(new Object())); //false
// l.add(new Object()); // does not compile
}
}
Who cares what you try to remove ?
Adding is something else; we wouldn't want to end up with something strange in our collection.
as requested; an example:
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
public class Main {
private static class A {
}
public static void main(String[] args) {
Collection<A> collection_A = new ArrayList<A>();
Collection<String> collection = new ArrayList<String>();
// no problem to try and remove things that wouldn't be there in the first place; either way, they are gone afterwards
collection.removeAll(collection_A);
// we can't allow this; you would end up with things in your collection that don't belong there
collection.addAll(collection_A);
}
}
To remove restriction is not needed, so only <?>, but while adding we have to check and then add for type safety, so addAll is with restriction <? extends E>
With addAll you want to be able to add all elements that are a subtype of the generic type. This includes adding all elements of a List<String> to a List<Object>. We use ? extends E to accept any Collection that contains the type stored in this collection or any subtype.
boolean addAll(java.util.Collection<? extends E> es);
List<Number> numbers = ...;
List<Integer> integers = ...;
numbers.addAll(integers);//works
boolean addAll(java.util.Collection<E> es);
numbers.addAll(integers);//does not work E != Integer
we can't use ? as that would remove any security provided by generics.
boolean addAll(java.util.Collection<? extends E> es);
List<Number> numbers = ...;
List<Integer> integers = ...;
List<String> strings = ...;
numbers.addAll(integers);//works
numbers.addAll(strings);//error
boolean addAll(java.util.Collection<?> es);
numbers.addAll(strings);//works - now we have strings in our Number collection
We can use ? to remove objects since trying to remove a String from List of Numbers wont affect a List<Number>.
boolean removeAll(java.util.Collection<?> objects);
List<Objects> objects = ...;
List<Integer> integers = ...;
List<Number> numbers = ...;
numbers.removeAll(objects);//works
numbers.removeAll(integers);//works
boolean removeAll(java.util.Collection<? extends E> objects);
numbers.removeAll(objects);//does not work
numbers.removeAll(integers);//works
boolean removeAll(java.util.Collection<? super E> objects);
numbers.removeAll(objects);//works
numbers.removeAll(integers);//does not work
I'm wondering how to iterate over a List with mixed contents using foreach. See the example code below.
public class GenericsForeach {
class A {
void methodA() {
System.out.println(getClass().getSimpleName() + ": A");
}
}
class B extends A {
void methodB() {
System.out.println(getClass().getSimpleName() + ": B");
}
}
void test() {
List<A> listOfA = new ArrayList<A>();
listOfA.add(new A());
List<B> listOfB = new ArrayList<B>();
listOfB.add(new B());
List<? super A> mixed = new ArrayList<A>();
mixed.addAll(listOfA);
mixed.addAll(listOfB);
Iterator<? super A> it = mixed.iterator();
while (it.hasNext()) {
A item = (A) it.next();
item.methodA();
}
// XXX: this does not work
// for (A item : mixed) {
// item.methodA();
// }
}
public static void main(String[] args) {
new GenericsForeach().test();
}
}
I construct two lists with different, but related, content types A and B (B extends A). I add the two lists to a 'mixed' list, which I declare to contain <? super A> types. Since this mixed list is 'consuming' items of type A (or B) I applied Bloch's PECS rule (Producer Extends, Consumer Super) to determine that I need <? super A> here.
So far, so good. But now when I want to iterate over this mixed list, I can only seem to do it with an Iterator<? super A>, and a cast A item = (A) it.next(). When I try to use a foreach loop (see commented-out code), no joy:
Type mismatch: cannot convert from element type capture#8-of ? super GenericsForeach.A to GenericsForeach.A
Eclipse even helpfully offers to
Change type of 'item' to '? super A'
but this results in disaster:
for (? super A item : mixed) {
item.methodA();
}
So I don't know. Eclipse doesn't seem to know. Does anybody else here know if this is possible, and if it's not, why not?
You want just List<A> for mixed. My reasoning:
you want to be able to add items which are of type A, so it can't be List<? extends A> - that would include List<B>, which you can't add an A to.
you want to be able to guarantee that items which you fetch are of type A, so it can't be List<? super A> as that could be a List<Object> containing non-A elements.
So you end up with:
List<A> mixed = new ArrayList<A>();
mixed.addAll(listOfA);
mixed.addAll(listOfB);
for (A item : mixed) {
item.methodA();
}
Everyone here is correct. You want use List<A>.
But generics and assignments can be confusing, so a little more explanation is in order.
First, the problem you may have found is that you can't do this: List<A> = new List<B>(). The compiler won't let you assign a sub-type in to a super-type listing using generics. This is a little confusing, but it prevents problems with type mis-matches. (More detail can be found here: http://java.sun.com/docs/books/tutorial/java/generics/subtyping.html.) The correct terminology for this is List<? extends A> = new List<B>(). This tells the compiler that your assignment is legal.
At the same time, this syntax can confuse you to believing that <? extends A> means that all elements in this variable extend A. This isn't true - the syntax just a way to inform the compiler of legal assignments.
So, you want to use List<A> = new List<A> and then assign the elements to List<A> using addAll(). This is legal because the method addAll checks to make sure each element is valid before pushing it to the collection.
What is the difference between <? super E> and <? extends E>?
For instance when you take a look at class java.util.concurrent.LinkedBlockingQueue there is the following signature for the constructor:
public LinkedBlockingQueue(Collection<? extends E> c)
and for one for the method:
public int drainTo(Collection<? super E> c)
The first (<? super E>) says that it's "some type which is an ancestor (superclass) of E"; the second (<? extends E>) says that it's "some type which is a subclass of E". (In both cases E itself is okay.)
So the constructor uses the ? extends E form so it guarantees that when it fetches values from the collection, they will all be E or some subclass (i.e. it's compatible). The drainTo method is trying to put values into the collection, so the collection has to have an element type of E or a superclass.
As an example, suppose you have a class hierarchy like this:
Parent extends Object
Child extends Parent
and a LinkedBlockingQueue<Parent>. You can construct this passing in a List<Child> which will copy all the elements safely, because every Child is a parent. You couldn't pass in a List<Object> because some elements might not be compatible with Parent.
Likewise you can drain that queue into a List<Object> because every Parent is an Object... but you couldn't drain it into a List<Child> because the List<Child> expects all its elements to be compatible with Child.
The reasons for this are based on how Java implements generics.
An Arrays Example
With arrays you can do this (arrays are covariant)
Integer[] myInts = {1,2,3,4};
Number[] myNumber = myInts;
But, what would happen if you try to do this?
myNumber[0] = 3.14; //attempt of heap pollution
This last line would compile just fine, but if you run this code, you could get an ArrayStoreException. Because you’re trying to put a double into an integer array (regardless of being accessed through a number reference).
This means that you can fool the compiler, but you cannot fool the runtime type system. And this is so because arrays are what we call reifiable types. This means that at runtime Java knows that this array was actually instantiated as an array of integers which simply happens to be accessed through a reference of type Number[].
So, as you can see, one thing is the actual type of the object, and another thing is the type of the reference that you use to access it, right?
The Problem with Java Generics
Now, the problem with Java generic types is that the type information is discarded by the compiler and it is not available at run time. This process is called type erasure. There are good reason for implementing generics like this in Java, but that's a long story, and it has to do, among other things, with binary compatibility with pre-existing code (see How we got the generics we have).
But the important point here is that since, at runtime there is no type information, there is no way to ensure that we are not committing heap pollution.
For instance,
List<Integer> myInts = new ArrayList<Integer>();
myInts.add(1);
myInts.add(2);
List<Number> myNums = myInts; //compiler error
myNums.add(3.14); //heap pollution
If the Java compiler does not stop you from doing this, the runtime type system cannot stop you either, because there is no way, at runtime, to determine that this list was supposed to be a list of integers only. The Java runtime would let you put whatever you want into this list, when it should only contain integers, because when it was created, it was declared as a list of integers.
As such, the designers of Java made sure that you cannot fool the compiler. If you cannot fool the compiler (as we can do with arrays) you cannot fool the runtime type system either.
As such, we say that generic types are non-reifiable.
Evidently, this would hamper polymorphism. Consider the following example:
static long sum(Number[] numbers) {
long summation = 0;
for(Number number : numbers) {
summation += number.longValue();
}
return summation;
}
Now you could use it like this:
Integer[] myInts = {1,2,3,4,5};
Long[] myLongs = {1L, 2L, 3L, 4L, 5L};
Double[] myDoubles = {1.0, 2.0, 3.0, 4.0, 5.0};
System.out.println(sum(myInts));
System.out.println(sum(myLongs));
System.out.println(sum(myDoubles));
But if you attempt to implement the same code with generic collections, you will not succeed:
static long sum(List<Number> numbers) {
long summation = 0;
for(Number number : numbers) {
summation += number.longValue();
}
return summation;
}
You would get compiler erros if you try to...
List<Integer> myInts = asList(1,2,3,4,5);
List<Long> myLongs = asList(1L, 2L, 3L, 4L, 5L);
List<Double> myDoubles = asList(1.0, 2.0, 3.0, 4.0, 5.0);
System.out.println(sum(myInts)); //compiler error
System.out.println(sum(myLongs)); //compiler error
System.out.println(sum(myDoubles)); //compiler error
The solution is to learn to use two powerful features of Java generics known as covariance and contravariance.
Covariance
With covariance you can read items from a structure, but you cannot write anything into it. All these are valid declarations.
List<? extends Number> myNums = new ArrayList<Integer>();
List<? extends Number> myNums = new ArrayList<Float>();
List<? extends Number> myNums = new ArrayList<Double>();
And you can read from myNums:
Number n = myNums.get(0);
Because you can be sure that whatever the actual list contains, it can be upcasted to a Number (after all anything that extends Number is a Number, right?)
However, you are not allowed to put anything into a covariant structure.
myNumst.add(45L); //compiler error
This would not be allowed, because Java cannot guarantee what is the actual type of the object in the generic structure. It can be anything that extends Number, but the compiler cannot be sure. So you can read, but not write.
Contravariance
With contravariance you can do the opposite. You can put things into a generic structure, but you cannot read out from it.
List<Object> myObjs = new List<Object>();
myObjs.add("Luke");
myObjs.add("Obi-wan");
List<? super Number> myNums = myObjs;
myNums.add(10);
myNums.add(3.14);
In this case, the actual nature of the object is a List of Objects, and through contravariance, you can put Numbers into it, basically because all numbers have Object as their common ancestor. As such, all Numbers are objects, and therefore this is valid.
However, you cannot safely read anything from this contravariant structure assuming that you will get a number.
Number myNum = myNums.get(0); //compiler-error
As you can see, if the compiler allowed you to write this line, you would get a ClassCastException at runtime (because item 0 in the list is an Object, not a Number).
Get/Put Principle
As such, use covariance when you only intend to take generic values out of a structure, use contravariance when you only intend to put generic values into a structure, and use the exact generic type when you intend to do both.
The best example I have is the following which copies any kind of numbers from one list into another list. It only gets items from the source, and it only puts items in the target.
public static void copy(List<? extends Number> source, List<? super Number> target) {
for(Number number : source) {
target.add(number);
}
}
Thanks to the powers of covariance and contravariance this works for a case like this:
List<Integer> myInts = asList(1,2,3,4);
List<Double> myDoubles = asList(3.14, 6.28);
List<Object> myObjs = new ArrayList<Object>();
copy(myInts, myObjs);
copy(myDoubles, myObjs);
<? extends E> defines E as the upper bound: "This can be cast to E".
<? super E> defines E as the lower bound: "E can be cast to this."
<? super E> means any object including E that is parent of E
<? extends E> means any object including E that is child of E .
I'm going to try and answer this. But to get a really good answer you should check Joshua Bloch's book Effective Java (2nd Edition). He describes the mnemonic PECS, which stands for "Producer Extends, Consumer Super".
The idea is that if you code is consuming the generic values from the object then you should use extends. but if you are producing new values for the generic type you should use super.
So for example:
public void pushAll(Iterable<? extends E> src) {
for (E e: src)
push(e);
}
And
public void popAll(Collection<? super E> dst) {
while (!isEmpty())
dst.add(pop())
}
But really you should check out this book:
http://java.sun.com/docs/books/effective/
You might want to google for the terms contravariance (<? super E>) and covariance (<? extends E>). I found that the most useful thing when comprehending generics was for me to understand the method signature of Collection.addAll:
public interface Collection<T> {
public boolean addAll(Collection<? extends T> c);
}
Just as you'd want to be able to add a String to a List<Object>:
List<Object> lo = ...
lo.add("Hello")
You should also be able to add a List<String> (or any collection of Strings) via the addAll method:
List<String> ls = ...
lo.addAll(ls)
However you should realize that a List<Object> and a List<String> are not equivalent and nor is the latter a subclass of the former. What is needed is the concept of a covariant type parameter - i.e. the <? extends T> bit.
Once you have this, it's simple to think of scenarios where you want contravariance also (check the Comparable interface).
Before the answer; Please be clear that
Generics only compile time feature to ensure TYPE_SAFETY, it wont b available during RUNTIME.
Only a reference with Generics will force the type safety; if the reference don't declared with generics then it will work without type safty.
Example:
List stringList = new ArrayList<String>();
stringList.add(new Integer(10)); // will be successful.
Hope this will help you to understand wildcard more clear.
//NOTE CE - Compilation Error
// 4 - For
class A {}
class B extends A {}
public class Test {
public static void main(String args[]) {
A aObj = new A();
B bObj = new B();
//We can add object of same type (A) or its subType is legal
List<A> list_A = new ArrayList<A>();
list_A.add(aObj);
list_A.add(bObj); // A aObj = new B(); //Valid
//list_A.add(new String()); Compilation error (CE);
//can't add other type A aObj != new String();
//We can add object of same type (B) or its subType is legal
List<B> list_B = new ArrayList<B>();
//list_B.add(aObj); CE; can't add super type obj to subclass reference
//Above is wrong similar like B bObj = new A(); which is wrong
list_B.add(bObj);
//Wild card (?) must only come for the reference (left side)
//Both the below are wrong;
//List<? super A> wildCard_Wrongly_Used = new ArrayList<? super A>();
//List<? extends A> wildCard_Wrongly_Used = new ArrayList<? extends A>();
//Both <? extends A>; and <? super A> reference will accept = new ArrayList<A>
List<? super A> list_4__A_AND_SuperClass_A = new ArrayList<A>();
list_4__A_AND_SuperClass_A = new ArrayList<Object>();
//list_4_A_AND_SuperClass_A = new ArrayList<B>(); CE B is SubClass of A
//list_4_A_AND_SuperClass_A = new ArrayList<String>(); CE String is not super of A
List<? extends A> list_4__A_AND_SubClass_A = new ArrayList<A>();
list_4__A_AND_SubClass_A = new ArrayList<B>();
//list_4__A_AND_SubClass_A = new ArrayList<Object>(); CE Object is SuperClass of A
//CE; super reference, only accepts list of A or its super classes.
//List<? super A> list_4__A_AND_SuperClass_A = new ArrayList<String>();
//CE; extends reference, only accepts list of A or its sub classes.
//List<? extends A> list_4__A_AND_SubClass_A = new ArrayList<Object>();
//With super keyword we can use the same reference to add objects
//Any sub class object can be assigned to super class reference (A)
list_4__A_AND_SuperClass_A.add(aObj);
list_4__A_AND_SuperClass_A.add(bObj); // A aObj = new B();
//list_4__A_AND_SuperClass_A.add(new Object()); // A aObj != new Object();
//list_4__A_AND_SuperClass_A.add(new String()); CE can't add other type
//We can't put anything into "? extends" structure.
//list_4__A_AND_SubClass_A.add(aObj); compilation error
//list_4__A_AND_SubClass_A.add(bObj); compilation error
//list_4__A_AND_SubClass_A.add(""); compilation error
//The Reason is below
//List<Apple> apples = new ArrayList<Apple>();
//List<? extends Fruit> fruits = apples;
//fruits.add(new Strawberry()); THIS IS WORNG :)
//Use the ? extends wildcard if you need to retrieve object from a data structure.
//Use the ? super wildcard if you need to put objects in a data structure.
//If you need to do both things, don't use any wildcard.
//Another Solution
//We need a strong reference(without wild card) to add objects
list_A = (ArrayList<A>) list_4__A_AND_SubClass_A;
list_A.add(aObj);
list_A.add(bObj);
list_B = (List<B>) list_4__A_AND_SubClass_A;
//list_B.add(aObj); compilation error
list_B.add(bObj);
private Map<Class<? extends Animal>, List<? extends Animal>> animalListMap;
public void registerAnimal(Class<? extends Animal> animalClass, Animal animalObject) {
if (animalListMap.containsKey(animalClass)) {
//Append to the existing List
/* The ? extends Animal is a wildcard bounded by the Animal class. So animalListMap.get(animalObject);
could return a List<Donkey>, List<Mouse>, List<Pikachu>, assuming Donkey, Mouse, and Pikachu were all sub classes of Animal.
However, with the wildcard, you are telling the compiler that you don't care what the actual type is as long as it is a sub type of Animal.
*/
//List<? extends Animal> animalList = animalListMap.get(animalObject);
//animalList.add(animalObject); //Compilation Error because of List<? extends Animal>
List<Animal> animalList = animalListMap.get(animalClass);
animalList.add(animalObject);
}
}
}
}
A wildcard with an upper bound looks like " ? extends Type " and stands for the family of all types that are subtypes of Type , type Type being included. Type is called the upper bound .
A wildcard with a lower bound looks like " ? super Type " and stands for the family of all types that are supertypes of Type , type Type being included. Type is called the lower bound .
You have a Parent class and a Child class inherited from Parent class.The Parent Class is inherited from another class called GrandParent Class.So Order of inheritence is GrandParent > Parent > Child.
Now,
< ? extends Parent > - This accepts Parent class or either Child class
< ? super Parent > - This accepts Parent class or either GrandParent class
super: List<? super T> 'super' guarantees object to be ADDED to the collection is of type T.
extends: List<? extends T> 'extend' guarantees object READ from collection is of type T.
Explanation:
There are three things that need to be considered while understanding a difference between 'super' and 'extends' from type safety point of view.
1.Assigning : What type of collection can be assigned to the generic reference.
2.Adding : What type can be added to the collection referred.
3.Reading : What type can be read from collection referred
'<? super T>' ensures-
Any collection of type T or its superclass can be assigned.
Any object of type T or its subclass can be added to collection, as it
will always pass a 'Is A' test for T.
Type of the item read from the collection can not be guarantied except from being of type 'Object'. It can be anything of type T or its superclass which includes type 'Object'.
'<? extends T>' ensures-
Any collection of type T or its subclass can be assigned.
No object can be added as we can not determine type of reference.
(Even object of type 'T' can not be added, because generic reference might be assigned to the collection of subtype of 'T')
Item read from the collection can be guarantied to be of type 'T'.
Consider class hierarchy
class Base {}
class Intermediate extends Base{}
class ThirdLayer extends Intermediate{}
public void testGenerics() {
/**
* super: List<? super T> super guarantees object to be ADDED to the collection
* if of type T.
*
* extends: List<? extends T> extend guarantees object READ from collection is
* of type T
*
* Super:-
*
* Assigning : You can assign collection of Type T or its super classes
* including 'Object' class.
*
* Adding: You can add objects of anything of Type T or of its subclasses, as we
* are sure that the object of type T of its subclass always passes Is A test
* for T. You can NOT add any object of superclass of T.
*
* Reading: Always returns Object
*/
/**
* To a Collection of superclass of Intermediate we can assign Collection of
* element of intermediate or its Parent Class including Object class.
*/
List<? super Intermediate> lst = new ArrayList<Base>();
lst = new ArrayList<Intermediate>();
lst = new ArrayList<Object>();
//Can not assign Collection of subtype
lst = new ArrayList<ThirdLayer>(); //Error!
/**
* Elements of subtype of 'Intemediate' can be added as assigned collection is
* guaranteed to be of type 'Intermediate
*/
lst.add(new ThirdLayer());
lst.add(new Intermediate());
// Can not add any object of superclass of Intermediate
lst.add(new Base()); //Error!
Object o = lst.get(0);
// Element fetched from collection can not inferred to be of type anything
// but 'Object'.
Intermediate thr = lst.get(0); //Error!
/**
* extends: List<? extends T> extend guarantees object read from collection is
* of type T
* Assigning : You can assign collection of Type T or its subclasses.
*
* Adding: You cannot add objects of anything of Type T or even objects of its
* subclasses. This is because we can not be sure about the type of collection
* assigned to the reference.
*
* Reading: Always returns object of type 'T'
*/
// Can assign collection of class Intermediate or its subclasses.
List<? extends Intermediate> lst1 = new ArrayList<ThirdLayer>();
lst1 = new ArrayList<Base>(); //Error! can not assign super class collection
/**
* No element can be added to the collection as we can not be sure of
* type of the collection. It can be collection of Class 'Intermediate'
* or collection of its subtype. For example if a reference happens to be
* holding a list of class ThirdLayer, it should not be allowed to add an
* element of type Intermediate. Hence no addition is allowed including type
* 'Intermediate'.
*/
lst1.add(new Base()); //Error!
lst1.add(new ThirdLayer()); //Error!
lst1.add(new Intermediate()); //Error!
/**
* Return type is always guaranteed to be of type 'Intermediate'. Even if the
* collection hold by the reference is of subtype like 'ThirdLayer', it always
* passes the 'IS A' test for 'Intermediate'
*/
Intermediate elm = lst1.get(0);
/**
* If you want a Collection to accept (aka to be allowed to add) elements of
* type T or its subclasses; simply declare a reference of type T i.e. List<T>
* myList;
*/
List<Intermediate> lst3 = new ArrayList<Intermediate>();
lst3 = new ArrayList<ThirdLayer>(); //Error!
lst3 = new ArrayList<Base>(); //Error!
lst3.add(new Intermediate());
lst3.add(new ThirdLayer()); // Allowed as ThirdLayer passes 'IS A' for Intermediate
lst3.add(new Base()); //Error! No guarantee for superclasses of Intermediate
}