Question on Upper-Bounded Wildcards

[Mike Gosling]

So from the OCP Java17 they give an example on what method call will compile, "line a" or "line b"?

import java.util.ArrayList;
import java.util.List;

interface Flyer { void fly(); }
class HangGlider implements Flyer { public void fly() {} }
class Goose implements Flyer { public void fly() {} }
public class Demo {

    private void anyFlyer(List<Flyer> flyer) {}
    private void groupOfFlyers(List<? extends Flyer> flyer) {}

    void m(){
        List<Goose> x = null;
        this.anyFlyer(x); //Line a
        this.groupOfFlyers(x);//Line b
    }

I wanted to check with you guys if my way of "reasoning" is correct:

First I notice I'm dealing with two classes which have common interface, also I notice I'm dealing with parameterized collections. So I envision three groups of hierarchies like so:

//1.
List<?>
 /|\
  |  (is)
  |
List<? extends HangGlider>
 /|\
  |  (is)
  |
List<HangGlider>

//2.
List<?>
 /|\
  |  (is)
  |
List<? extends Goose>
 /|\
  |  (is)
  | 
List<Goose>

//3.
List<?>
 /|\
  |  (is)
  |
List<? extends Flyer>
 /|\
  |  (is)
  | 
List<Flyer>

First lets check anyFlyer.

Since formal parameter of anyFlyer is List<Flyer> the object it points to, if we were to write it somewhere in the code, it could only:

List<Flyer> flyer = new ArrayList<Flyer> //not counting LinkedList

It couldn't be:

List<Flyer> flyer = new ArrayList<Goose>

This is because of parameterized types (I'm not sure are there any more reasons or is this correct):

public class ArrayList<E> extends AbstractList<E>
        implements List<E>
{

So flyer can only be pointing to appropriate parameterized collection.

Having that  in mind, passing variable x, to anyFlyer would cause compilation error.

Lets check groupOfFlyers:

If we take a look at third group of hierarchies, we can see 'List<? extends Flyer>'. These can be type for (I don't know proper term) four objects (options ?), that would compile:

        List<? extends Flyer> f = new ArrayList<>();
        List<? extends Flyer> f1 = new ArrayList<Goose>();
        List<? extends Flyer> f2 = new ArrayList<HangGlider>();
        List<? extends Flyer> f3 = new ArrayList<Flyer>();

And since they all compile and x is one of them, f1, then we can safely say "Line b" is the one which does compile.


I'm interested to hear is this good way to reason about?

[Stephan van Hulst]

I didn't really understand your entire reasoning, but I think you have figured out something for yourself that works. The answer you got is correct, anyway.

[Liutauras Vilda]

@OP

I did not try to disassemble your example, but here is some guide for you using Java's built-in types. Try to relate it to your case and see if you can make sense out of it.

Using extends (i.e. List<? extends T>)

For example, the wildcard declaration of List<? extends Number> foo means that any of these are legal assignments:

List<? extends Number> foo = new ArrayList<Number>(); // Number "extends" Number (in this context)
List<? extends Number> foo = new ArrayList<Integer>(); // Integer extends Number
List<? extends Number> foo = new ArrayList<Double>(); // Double extends Number

Reading (get) - given the above possible assignments, what type of objects you are guaranteed to read from a List foo?
can

You can read a Number because any of the lists that could be assigned to foo contain a Number or a subclass of Number

can't

You can't read an Integer because foo could be pointing to an ArrayList<Double>

You can't read a Double because foo could be pointing to an ArrayList<Integer>

Writing (add) - what type of objects you could add to a List foo that would be legal for all the above possible List instances?
can't

You can't add an Integer because foo could be pointing to an ArrayList<Double>

You can't add a Double because foo could be pointing to an ArrayList<Integer>

You can't add a Number because foo could be pointing to an ArrayList<Integer>

In different words, you can't add any object to List<? extends T> because you can't guarantee what kind of List it is actually pointing to, so you can't guarantee that the object is allowed in that List. The only guarantee so to speak is, that you can only read from it and you'll get a T or subclass of T. That is it.


Now, using super (i.e. List<? super T>)

For example, the wildcard declaration of List<? super Integer> foo means that any of these are legal assignments:

List<? super Integer> foo = new ArrayList<Integer>(); // Integer is a "superclass" of Integer (in this context)
List<? super Integer> foo = new ArrayList<Number>(); // Number is a superclass of Integer
List<? super Integer> foo = new ArrayList<Object>(); // Object is a superclass of Integer

Reading (get) - given the above possible assignments, what type of object are you guaranteed to receive when you read from a List foo:
can

You can read an Object because all classes inherit from Object

can't

You can't guarantee an Integer because foo could be pointing to an ArrayList<Number> or ArrayList<Object>

You can't guarantee a Number because foo could be pointing to an ArrayList<Object>

The only guarantee is that you will get an instance of an Object or subclass of Object, but you don't know what that subclass might be.

Writing (add) - what type of object could you add to a List foo that would be legal for all the above possible List instances:
can

You can add an Integer because an Integer is allowed in any of the above lists

You can add an instance of a subclass of Integer because Integer is allowed in any of the above lists

can't

You can't add a Double because foo could be pointing to an  ArrayList<Integer>

You can't add a Number because foo could be pointing to an ArrayList<Integer>

You can't add an Object because foo could be pointing to an ArrayList<Integer>

All can get confusing, but when you think about it slowly, all make sense.

[Mike Gosling]

Hey Liutauras, thanks for excellent post. After reading Oracle's tutorial on generics it became a bit clearer, but now with your post, these wildcards are becoming far more clearer now. I will just follow your strategy for determining what can be added/removed in generics with bounded wildcards.

Good thing you dismantled my example  

[Anil Philip]

Liutauras Vilda wrote:@OP
List<? super Integer> foo = new ArrayList<Integer>(); // Integer is a "superclass" of Integer (in this context)

You can add an Integer because an Integer is allowed in any of the above lists

I have been struggling to understand this concept. Isn't the code snippet below, similar to what you wrote above?
Yet it does not compile

If you think it is useful, please vote to reopen the question here https://stackoverflow.com/questions/73889515/does-wildcard-super-number-refer-to-a-superclass-like-object-or-a-subtype-li

import java.util.ArrayList;
import java.util.List;

public class Bewildered {
    static class A {}
    static class B extends A {}
    static class C extends B {}

    public static void main(String[] args) {
        List<? super B> listBs = new ArrayList<A>();
        listBs.add(new A()); // DOES NOT COMPILE
    }
}

[Paul Clapham]

Anil Philip wrote:I have been struggling to understand this concept. Isn't the code snippet below, similar to what you wrote above?
Yet it does not compile

You can add an Integer to a List<? super Integer>, as he wrote above. Likewise you can add a B to a List<? super B>. But your code doesn't do that.

[Liutauras Vilda]

Anil Philip wrote:Isn't the code snippet below, similar to what you wrote above?

It is, but not the same. Anyway, reasons are the same. If I did not make any mistake, that should be it. Please write code and verify for yourself.

You have List<? super B>

Reading:
can

You can read an Object because all classes inherit from Object

can't

You can't guarantee a B because foo could be pointing to an ArrayList<A> or an ArrayList<Object>

You can't guarantee a A because foo could be pointing to an ArrayList<B> or an ArrayList<Object>

Writing:
can

You can add a B

You can add an instance of a subclass of B

can't

You can't add an A because foo could be pointing to an  ArrayList<Object>

[Anil Philip]

Liutauras Vilda wrote:You can't add an A because foo could be pointing to an  ArrayList<Object>

But the compiler knows that we are only adding an A to a List<A> yet it disallowed it!
Does List<? super B> mean every member should be the same (all As, all Bs, all Objects)
Is my understanding correct?

[Mike Gosling]

Hopefully this would help.

 class A {}
 class B extends A {}
 class C extends B {}
public class Demo4 {


    public static void main(String[] args) {
        Demo4 demo4 = new Demo4();

        List<? super B> listOfBs1 = demo4.getListOfBsAsBObjects();
        List<? super B> listOfBs2 = demo4.getListOfBsAsAObjects();
        List<? super B> listOfBs3 = demo4.getListOfBsAsObjects();

        //Getting
        final Object object = listOfBs1.get(0);  //DOES COMPILE;
        final Object object1 = listOfBs2.get(0); //DOES COMPILE;
        final Object object2 = listOfBs3.get(0); //DOES COMPILE;

        B b = listOfBs1.get(0); //DOES NOT COMPILE;
        A a = listOfBs2.get(0); //DOES NOT COMPILE;
        Object o = listOfBs3.get(0); //DOES COMPILE;


        //Adding
        listOfBs2.add(new A()); //DOES NOT COMPILE;
        listOfBs2.add(new B()); //DOES COMPILE;
        listOfBs2.add(new C()); //DOES COMPILE;

        /*
          I try to think of it, as Liutauras nicely explained, that Java cannot know at which object listOfBsX is pointing to.
          Let's say you called getListOfBsAsBObjects(). You would have a list of subclass objects (since B extends A) in which you try to add a superclass object (A). Cannot do that in Java.
          That is not "is-a" relationship. "A is not B" but "B is A". You might even call getListOfBsAsBObjects() or getListOfBsAsObjects() and attempted to add new A() in one of those lists. Which seems
          okay at first. But Java doesn't know which object List<? super B> it is, so it defend itself by allowing to add only B and its covariant (subclasses) and getting only Object.
         */

    }

    public List<? super B> getListOfBsAsBObjects() {
        return new ArrayList<B>(); //DOES COMPILE
    }

    public List<? super B> getListOfBsAsAObjects() {
        return new ArrayList<A>(); //DOES COMPILE
    }

    public List<? super B> getListOfBsAsObjects() {
        return new ArrayList<>(); //DOES COMPILE
    }

}

Please go through this tutorial (https://docs.oracle.com/javase/tutorial/java/generics/index.html) and combined with this thread it should make sense. It helped me I am know seeing that List<? super T> is more convenient for addition and that List<? extends T> is more handy for getting things.

[Stephan van Hulst]

Anil Philip wrote:But the compiler knows that we are only adding an A to a List<A> yet it disallowed it!

The compiler knows no such thing. It only knows that you have a List<? super B>, which could be a List<A>, but it also could be a List<B>. The compiler won't know which one, so it doesn't allow you to add an A to what might possibly be a List<B>

Does List<? super B> mean every member should be the same (all As, all Bs, all Objects)
Is my understanding correct?

No. List<? super B> means it can refer to any kind of list, as long as the generic type argument is B or a supertype of B. So, it may refer to a List<B>, a List<A> or a List<Object>, but importantly the compiler will not know which one exactly.

It's not helping that you've chosen type names that are meaningless. Let's use different examples:

class Animal {}

class BigCat extends Animal {}

class Lion extends BigCat {}

class Tiger extends BigCat {}

class Cage<T extends Animal> {

  private final T animal;

  T getAnimal() {
    return animal;
  }

  void putAnimal(T animal) {
    this.animal = animal;
  }
}

Here is a simple case that should be easy to understand:

Cage<Lion> lionCage = new Cage<>();

lionCage.putAnimal(new Lion());

Lion lion = lionCage.getAnimal();

Let's mix some big cats:

Cage<BigCat> catCage = new Cage<>();

catCage.putAnimal(new Lion());  // okay
catCage.putAnimal(new Tiger()); // okay

// okay
BigCat cat = catCage.getAnimal();

// not okay, there could be a Tiger in the cage
Lion lion = catCage.getAnimal();

So far so good, right? Now let's try some lower bounds:

Cage<? super BigCat> cage = unknownTypeOfCage();

cage.putAnimal(new Lion());  // okay
cage.putAnimal(new Tiger()); // okay

// not okay, cage could refer to a Cage<Animal>
BigCat cat = cage.getAnimal();

// not okay, cage could refer to a Cage<BigCat>
cage.putAnimal(new Butterfly());

[Anil Philip]

Stephan van Hulst wrote:

It's not helping that you've chosen type names that are meaningless. Let's use different examples:

I tried to compile your code to see what is allowed, but there seem to be other compile errors.

package com.sandbox.learn;

class Animal {
}

class BigCat extends Animal {
}

class Lion extends BigCat {
}

class Tiger extends BigCat {
}

public class Cage<T extends Animal> {

    private final T animal;

    T getAnimal() {
        return animal;
    }

    void putAnimal(T animal) {
        this.animal = animal;
    }

    public static void main(String[] a) {
        Cage<Lion> lionCage = new Cage<>();

        lionCage.putAnimal(new Lion());

        Lion lion = lionCage.getAnimal();

        Cage<BigCat> catCage = new Cage<>();

        catCage.putAnimal(new Lion());  // okay
        catCage.putAnimal(new Tiger()); // okay

// okay
        BigCat cat = catCage.getAnimal();

// not okay, there could be a Tiger in the cage
        lion = catCage.getAnimal();

        Cage<? super BigCat> cage = unknownTypeOfCage();

        cage.putAnimal(new Lion());  // okay
        cage.putAnimal(new Tiger()); // okay

// not okay, cage could refer to a Cage<Animal>
        cat = cage.getAnimal();

// not okay, cage could refer to a Cage<BigCat>
        cage.putAnimal(new Butterfly());
    }
}

[Liutauras Vilda]

Remove final from line 17.

The remaining non-compiling parts of the code are explained in the comment that they are not compiling. That was intention of this code, to demonstrate the problem domain.

[Stephan van Hulst]

Sorry, Liutauras is correct. I habitually added the final modifier to that code, and didn't test it before posting.

[Anil Philip]

Liutauras Vilda wrote:@OP All can get confusing, but when you think about it slowly, all make sense.

How about this?

       List<? super B> oList = new ArrayList<C>(); // DOES NOT COMPILE

However, this will compile and run and is effectively an

 ArrayList<C>

    
// COMPILES AND RUNS OK
       List<? super B> oList = new ArrayList<>();
        cList.add(new C());
        cList.add(new C());
        cList.add(new C());

In other words, it has defeated the original restriction.

[Liutauras Vilda]

Anil Philip wrote:

// COMPILES AND RUNS OK
List<? super B> oList = new ArrayList<>();
cList.add(new C());
cList.add(new C());
cList.add(new C());

In other words, it has defeated the original restriction.

I don't get your point, nor what's confusing you. But it didn't defeat what I mentioned before, if that's what you meant.

Apart from the fact that you declared oList but adding to cList that code wouldn't compile, but if you were to fix it, it would compile just fine, because C is a subclass of B. We have explained that thrice.

[Anil Philip]

Liutauras Vilda wrote:We have explained that thrice.

no need to get annoyed

List<? super B> cList = new ArrayList<C>();

is illegal, and I get it.

However, one is still able to construct effectively the same thing by doing

List<? super B> cList = new ArrayList<>();
cList.add(new C());
cList.add(new C());
cList.add(new C());

[Liutauras Vilda]

Ah no no, I'm not annoyed, apologies if I sounded that way

Let's get back to business

You know, when you say new ArrayList<C>(), you say that this array list would hold C's. But that's not true, right? Because on the left side you say List<? super B>.

However, when you have an empty diamond operator <>, it infers the type this array list could hold based on the declaration on the left hand side, then it compiles just fine, and I trust you understand why to add C is allowed.

[Campbell Ritchie]

But just try getting a B or a C back out of that List
How can you get this code to compile?

??? x = cList.get(0);
/* assuming oList/cList problem has been corrected */

[Anil Philip]

Liutauras Vilda wrote:Ah no no, I'm not annoyed, apologies if I sounded that way

Let's get back to business

You know, when you say new ArrayList<C>(), you say that this array list would hold C's. But that's not true, right? Because on the left side you say List<? super B>.

However, when you have an empty diamond operator <>, it infers the type this array list could hold based on the declaration on the left hand side, then it compiles just fine, and I trust you understand why to add C is allowed.

My point is that in the first case, an ArrayList of C was not allowed because of the declaration on the left hand side.
But if we still keep the declaration the same and instead add the C's one by one, or bulk copy, we end up with the result that was denied earlier - an ArrayList of Cs.

[Liutauras Vilda]

Anil Philip wrote:...add the C's one by one, or bulk copy, we end up with the result that was denied earlier - an ArrayList of Cs.

I know I know what you mean. But that's not accurate.

Consider this:

class A {}
class B extends A {}
class C extends B {}
class F extends B {} // newly added

Now if you say new ArrayList<C>(), that contradicts what List<? super B> says:
"You can add a B or an instance of a subclass of B"

F is indeed a subclass of B, same as C is a subclass of B.

Is it clear now?

[Anil Philip]

Liutauras Vilda wrote:

Anil Philip wrote:...add the C's one by one, or bulk copy, we end up with the result that was denied earlier - an ArrayList of Cs.

I know I know what you mean. But that's not accurate.

Consider this:

class A {}
class B extends A {}
class C extends B {}
class F extends B {} // newly added

Now if you say new ArrayList<C>(), that contradicts what List<? super B> says:
"You can add a B or an instance of a subclass of B"

F is indeed a subclass of B, same as C is a subclass of B.

Is it clear now?

If I understand what you are saying,
we should be able to have both F's and C's in the ArrayList since both are subclasses of B.
The only way to have this is to deny or disallow

new ArrayList<C>()

.
Am I understanding you correctly?

[Piet Souris]

Congratulations, Mike!

Your topic got a mentioning in the October 2022 Journal, and so you earn a cow.

(Edit: that'll be tomorrow, since I have reached my cow-limit)

[Anil Philip]

Anil Philip wrote:
Am I understanding you correctly?

@Liutauras Vilda can you please confirm?

[Liutauras Vilda]

Anil Philip wrote:If I understand what you are saying,
we should be able to have both F's and C's in the ArrayList since both are subclasses of B.
The only way to have this is to deny or disallow

new ArrayList<C>()

Am I understanding you correctly?

Well, yes, otherwise contract isn't respected.

Apologies didn't reply earlier - missed your message.

[Anil Philip]

Liutauras Vilda wrote:

Anil Philip wrote:If I understand what you are saying,
we should be able to have both F's and C's in the ArrayList since both are subclasses of B.
The only way to have this is to deny or disallow

new ArrayList<C>()

Am I understanding you correctly?

Well, yes, otherwise contract isn't respected.

Apologies didn't reply earlier - missed your message.

Thank you for your patience and kindness.