Java Generics Puzzler, extending a class and using wildcards

Question

I\'ve been beating my head against this one for awhile and thought that maybe some fresh eyes will see the issue; thanks for your time.

import java.util.*;

clas         


        

Answer 1

This happens because of the way capture conversion works:

There exists a capture conversion from a parameterized type G<T1,...,Tn> to a parameterized type G<S1,...,Sn>, where, for 1 ≤ i ≤ n :

• If Ti is a wildcard type argument of the form ? extends Bi, then Si is a fresh type variable [...].

Capture conversion is not applied recursively.

Note the end bit. So, what this means is that, given a type like this:

    Map<?, List<?>>
//      │  │    └ no capture (not applied recursively)
//      │  └ T2 is not a wildcard
//      └ T1 is a wildcard

Only "outside" wildcards are captured. The Map key wildcard is captured, but the List element wildcard is not. This is why, for example, we can add to a List<List<?>>, but not a List<?>. The placement of the wildcard is what matters.

Carrying this over to TbinList, if we have an ArrayList<Tbin<?>>, the wildcard is in a place where it does not get captured, but if we have a TbinList<?>, the wildcard is in a place where it gets captured.

As I alluded to in the comments, one very interesting test is this:

ArrayList<Tbin<? extends Base>> test3 = new TbinList<>();

We get this error:

error: incompatible types: cannot infer type arguments for TbinList<>
    ArrayList<Tbin<? extends Base>> test3 = new TbinList<>();
                                                        ^
    reason: no instance(s) of type variable(s) T exist so that
            TbinList<T> conforms to ArrayList<Tbin<? extends Base>>

So there's no way to make it work as-is. One of the class declarations needs to be changed.

---

Additionally, think about it this way.

Suppose we had:

class Derived1 extends Base {}
class Derived2 extends Base {}

And since a wildcard allows subtyping, we can do this:

TbinList<? extends Base> test4 = new TbinList<Derived1>();

Should we be able to add a Tbin<Derived2> to test4? No, this would be heap pollution. We might end up with Derived2s floating around in a TbinList<Derived1>.

Answer 2

Replacing the definition of TbinList with

class TbinList<T> extends ArrayList<Tbin<? extends T>> {}

and defining test2 with

TbinList<Base> test2 = new TbinList<>();

instead would solve the issue.

With your definition you're ending up with an ArrayList<Tbin<T>> where T is any fixed class extending Base.

Answer 3

You can define the generic types as follows:

class Tbin<T> extends ArrayList<T> {}
class TbinList<K, T extends Tbin<K>> extends ArrayList<T> {}

Then you would create instance like:

TbinList<? extends Base, Tbin<? extends Base>> test2 = new TbinList<>();
test2.add(new Tbin<Derived>());

Answer 4

You're using a bounded wildcard (TbinList<? extends Base>> ...). This wildcard will prevent you from adding any elements to the list. If you want more info, heres the section about Wildcards in the docs.

Answer 5

OK, here's the answer:

import java.util.*;

class Tbin<T> extends ArrayList<T> {}
class TbinList<T> extends ArrayList<Tbin<? extends T>> {}

class Base {}
class Derived extends Base {}

public class Test {
  public static void main(String[] args) {

    TbinList<Base> test3 = new TbinList<>();
    test3.add(new Tbin<Derived>());

  }
}

As I expected, kind of obvious once I saw it. But a lot of thrashing around to get here. Java generics seem simple if you only look at working code.

Thanks, everyone, for being a sounding board.

Answer 6

you cannot add any objects to TbinList<? extends Base> ,it is not guaranteed what objects you are inserting into the list. It is supposed to read data from test2 when you use wildcard extends

If you declared as TbinList<? extends Base> which means you it is any subclass of the class Base or class Base itself, and when you initialize it you use diamond other than concrete class name, it makes your test2 not obvious which makes it harder to tell what objects can be inserted. My suggestion is that avoid such declaration it is dangerous, it may not have compile errors but it is horrible code, you might add something, but you also might add the WRONG thing which will break your code.