String and Generics

[vuthlarhi donald]

given that String is final are these two things the same

List<String>
List<? extends String>

if possible you can explain that with a piece of code

[siv sanny]

List<? extends String>: something extents String. but there can never be a something that can extend String(final class) except String itself. so it would be effectively equal to List<String>.

    
public class TestGeneric {
    public static void main(String[] args){
        List<? extends String> sr;
        List<String> r = new ArrayList<String>();
        sr = r; //is allowed, sr and r are of same generic list types
        .....
    }
}

-sankar

[Rob Spoor]

List<? extends String> is worse than List<String>.

Because technically the compiler doesn't know what exact subclass of String is used, you cannot add anything to this List, whereas you can with List<String>.

Overall:
List<? extends String>: adding anything is not possible, any return value is String.
List<? super String>: adding Strings is not a problem, but the return value can only be assigned to an Object reference without casting.
List<String>: adding Strings is not a problem, any return value is String.

[Jim Yingst]

[Rob Prime]:

List<? extends String> is worse than List<String>.

Because technically the compiler doesn't know what exact subclass of String is used, you cannot add anything to this List, whereas you can with List<String>.

Some people use constructs like List<? extends String> intentionally, to create a read-only List which is enforced at compile time, rather than throwing an UnsupportedOperationException at run time. Anyone trying to add or set an element in the list will get a compiler error. Unfortunately the error is something like this:

Test.java:6: cannot find symbol
symbol  : method add(java.lang.String)
location: interface java.util.List<capture#503 of ? extends java.lang.String>
        foo().add("hi");
             ^

which is less clear than it might be. And the original "List<? extends String>" is not a very clear way to communicate the concept of an unmodifiable list, either. So I hope this practice doesn't catch on widely. It does exist, however.

[praveen Shangunathan]

Jim,
A question based on your previous reply.
For,

List<? extends String> sr;

we cannot do a sr.add(), and you said it is done intentionally to make the list read only.
but this is not enforced, right ?
because you can do a

List<? extends String> sr;
//sr.add("1");
List<String> r = new ArrayList<String>();
r.add("1");
sr = r; 

One way Im aware of to make unmodifiable collection is to use wrappers.

[Jim Yingst]

[praveen]: we cannot do a sr.add(), and you said it is done intentionally to make the list read only.

It could be intentional, yes.

[praveen]: but this is not enforced, right ?

It's partly enforced, but there are ways around it, as you show.

[praveen]: One way Im aware of to make unmodifiable collection is to use wrappers.

Yes, that gives more secure enforcement of unmodifiability, at run time. You could combine the two techniques, and get an unmodifiable collection that is always unmodifiable at run time, and usually modifiable at compile time:

List<? extends String> list = Collections.unmodifiableList(new ArrayList<String>());

That provides more compile-time enforcement than a plain unmodifiableList() does, at least. But it's still not very readable. I doubt I'd ever use it.

[praveen Shangunathan]

I doubt if I'd ever use that either.
thanks Jim.