Enthuware. explanation q14 test 6. Why is List<? super Number> is a subtype of List<? super Integer>

enthuware.ocpjp.v17.2.3092

I understood the entire passage below except for this bit:

List<? super Number> is a subtype of List<? super Integer>

It seems reversed and counterintuitive since Integer is a subtype of Number.
Is it by convention laid down by the JLS or is there a reasoning behind this?
Note: I don't know why the text below is struck through!


Rule of Covariant Returns
An overriding method (i.e. a sub class's method) is allowed to return a sub-type of the type returned by the overridden method (i.e. super class's method).  
So, first check whether the return type of the overriding method is a subtype. For example, if the overridden method returns List, the overriding method can return ArrayList but not Object.  

Next, you need to check the type specification of generic types. This is a bit complicated. To determine this, you must remember the following hierarchy of subtypes. Assuming that S is a sub type of T and <<< means "is a subtype of", here are the two hierarchies:  

Hierarchy 1 <S> <<< A<? extends S> <<< A<? extends T> Example: Since Integer is a subtype of Number, List<Integer> is a subtype of List<? extends Integer> and List<? extends Integer> is a subtype of List<? extends Number>. Thus, if an overridden method returns List<? extends Integer>, the overriding method can return List<Integer> but not List<Number> or List<? extends Number>.  

Hierarchy 2 <T> <<< A<? super T> <<< A<? super S> Example: List<Number> is a subtype of List<? super Number> and List<? super Number> is a subtype of List<? super Integer> Thus, if an overridden method returns List<? super Number>, the overriding method can return List<Number> but not List<Integer> or List<? super Integer>.  
It is important to understand that List<Integer> is not a subtype of List<Number> even though Integer is a subtype of Number.

Hi Anil,

Here is a very good explanation of wildcard bounds: Wildcard Bounds.
First of all, there can be only one bound in a wildcard - lower or upper. <? super Integer> sets a lower bound to Integer.
You have to look at the hierarchy tree as:
Object   ^   | Number   ^   | Integer
Integer is the lower bound - it is at the bottom of allowed types. <? super Number> wildcard bound is a subset of <? super Integer>. Maybe that is why <? super Number> is called a subtype of <? super Integer>.

Ira Go wrote:
Integer is the lower bound - it is at the bottom of allowed types. <? super Number> wildcard bound is a subset of <? super Integer>. Maybe that is why <? super Number> is called a subtype of <? super Integer>

Shouldn't they say subset instead of subtype in both the "hierarchy rules"?

Not really.  First, subtype and supertype are well-defined terms in the Java Language Specification, while subset and superset are not.  More importantly though, subset and superset don't really apply here.  You could have two different collections and talk about whether the elements in one collection were a subset or superset of the other.  But that's different from having two different types, and wondering if everything you can do with one type can be done with the other type.

A type can not be a subset of another type because types are not sets.

You can assign a String to a variable of type Object because String is a subtype of Object.

You can assign a List<? extends Integer> to a variable of type List<? extends Number> because List<? extends Integer> is a subtype of List<? extends Number>.

If List<? super Integer> were a subtype of List<? super Number>, you would be able to assign a List<? super Integer> to a variable of type List<? super Number>. You can't, because it doesn't make sense and would lead to broken code:
List<? super Integer> integers = new ArrayList<Integer>(); // perfectly legal List<? super Number> numbers = integers;                   // this is illegal numbers.add(Float.valueOf(3.8f));                          // also perfectly legal
If the second statement were allowed, we would be able to add a Float to a List<Integer>.

Stephan van Hulst wrote: If List<? super Integer> were a subtype of List<? super Number>, you would be able to assign a List<? super Integer> to a variable of type List<? super Number>. You can't, because it doesn't make sense and would lead to broken code:
List<? super Integer> integers = new ArrayList<Integer>(); // perfectly legal List<? super Number> numbers = integers;                   // this is illegal numbers.add(Float.valueOf(3.8f));                          // also perfectly legal
If the second statement were allowed, we would be able to add a Float to a List<Integer>.

Okay then, how am I able to do this?
Assigning a Float to a list of Integer.

        List<? super Number> ln = new ArrayList<>();        List<? super Integer> li = new ArrayList<>();        ln.add(2.0);        li = ln;        System.out.println(li);

output:

[2.0]

I believe that he is talking about this kind of scenario:jshell> List<? super Integer> li = new ArrayList<>(); li ==> [] jshell> li.add(2.0f); |  Error: |  incompatible types: float cannot be converted to capture#2 of ? super java.lang.Integer |  li.add(2.0f); |         ^--^

Mike Simmons wrote:Not really.  First, subtype and supertype are well-defined terms in the Java Language Specification, while subset and superset are not.  More importantly though, subset and superset don't really apply here.

I used those terms because I was was having difficulty understanding

List<? super Number> is a subtype of List<? super Integer>

It seems reversed and counterintuitive since Integer is a subtype of Number

Ron McLeod wrote:I believe that he is talking about this kind of scenario

I don't think so - it is obvious a Float is not an Integer.
I have assigned a Float to a List<Integer>
Please see my code above (repeated below).

   // claim:   List<? super Number> is a subtype of List<? super Integer>        List<? super Number> ln = new ArrayList<>();        List<? super Integer> li = new ArrayList<>();        ln.add(2.0);        li = ln;        System.out.println(li);

output:

[2.0]

Anil Philip wrote:

List<? super Number> is a subtype of List<? super Integer>

It seems reversed and counterintuitive since Integer is a subtype of Number

It's reversed because it uses "super" (instead of "sub"). The Integer type is a possible runtime choice for "? super Integer", because Integer is Integer obviously, but it's not a possible runtime choice for "? super Number" because Number is not a subtype of Integer. Which means that "? super Integer" includes more possibilities than "? super Number" does. This wouldn't be the case if "? super Number" was a subtype of "? super Integer".

I would draw a Venn diagram and post it if I could, but imagine that the circle entitled "? super Integer" totally surrounds the circle entitled "? super Number". Which it does, because Integer has to be in the larger circle but not the smaller circle.

Counterintuitive? Absolutely. But intuition isn't the only tool available to understand this concept.

Anil Philip wrote:I have assigned a Float to a List<Integer>.

No... I don't see any List<Integer> anywhere in that code.

You'll remember that a while back there was a discussion about the meaning of "?" in generics. All of that discussion applies here too. Your assumption that there's a List<Integer> anywhere in that code is wrong, there's only a variable of type List<? super Integer> which refers to an object of type List<X> where X is some unknown superclass of Integer.

And X could be Number; Number is a superclass of Integer and 2.0 can be assigned to a Number variable. There isn't a problem. You could even use Object instead of Number and the same logic would apply. And your code would still compile and run.

Paul Clapham wrote:

Anil Philip wrote:I have assigned a Float to a List<Integer>.

No... I don't see any List<Integer> anywhere in that code.

Sorry, I misspoke - I meant to say list containing integers. Below I add Integer and Float to a List<? super Integer>
I should not be able to do that!

    // claim:   List<? super Number> is a subtype of List<? super Integer>        List<? super Number> ln = new ArrayList<>();        List<? super Integer> li = new ArrayList<>();        ln.add(2.0);        ln.add(Integer.valueOf(5));        li = ln;        System.out.println(li);

output:

[2.0, 5]

Anil Philip wrote:

Ron McLeod wrote:I believe that he is talking about this kind of scenario

I don't think so - it is obvious a Float is not an Integer.
I have assigned a Float to a List<Integer>
Please see my code above (repeated below).
   // claim:   List<? super Number> is a subtype of List<? super Integer>        List<? super Number> ln = new ArrayList<>();        List<? super Integer> li = new ArrayList<>();        ln.add(2.0);        li = ln;        System.out.println(li);

output:

[2.0]

Yup - I misunderstood.

In Stephen's example, he is assigning a List<? super Number> to a List<? super Integer>:List<? super Number> numbers = integers;                   // this is illegal
But in your example, you are doing the oppositeli = ln;
jshell> List<? super Number> ln = new ArrayList<>(); ln ==> [] jshell> List<? super Integer> li = new ArrayList<>(); li ==> [] jshell> ln.add(2.0f); $3 ==> true jshell> ln = li; |  Error: |  incompatible types: java.util.List<capture#2 of ? super java.lang.Integer> cannot be converted to java.util.List<? super java.lang.Number> |  ln = li; |       ^^

Anil Philip wrote:Sorry, I misspoke - I meant to say list containing integers. Below I add Integer and Float to a List<? super Integer>
I should not be able to do that!

Don't see why not. There are plenty of classes which are "super Integer".  Add these lines to your code:
      ln.add("Taylor Swift");       ln.add(LocalDate.now);
As you'll see those are also perfectly fine.

Anil Philip wrote:Okay then, how am I able to do this?
Assigning a Float to a list of Integer.

        List<? super Number> ln = new ArrayList<>();        List<? super Integer> li = new ArrayList<>();        ln.add(2.0);        li = ln;        System.out.println(li);

You haven't. You have added a Double to an ArrayList<Object>.

You used the diamond operator to create an ArrayList. The diamond operator inferred that the upper bound of the type parameter is Object.

Then you assigned an ArrayList<Object> to a variable of type List<? super Integer>, which is perfectly legal.

Anil Philip wrote:It seems reversed and counterintuitive since Integer is a subtype of Number

Sure, but we're not talking about Integer and Number.

We're talking about List<? super Integer> and List<? super Number>. Different variance, different rules.

Think of a List<? super Integer> as "a list that accepts integers".

Think of a List<? super Number> as "a list that accepts numbers".

A list that accepts numbers is also a list that accepts integers. Therefore, List<? super Number> is a subtype of List<? super Integer>.

Conversely, a list that accepts integers is not a list that accepts numbers, because it can not accept all different kinds of numbers.

Anil Philip wrote:Below I add Integer and Float to a List<? super Integer>
I should not be able to do that!

You are confusing the static type of the variable with the actual type of the referenced object at runtime.

You didn't add a Double to a List<? super Integer>.

You added a Double to an ArrayList<Object>.

That ArrayList<Object> just happens to be referenced by a variable of type List<? super Integer>, and one of type List<? super Number>. Both are fine.

Maybe it helps if we give a more concrete example:
/** * Reads the three sensors of this device and sinks them in the specified collection. * * @param sink the collection to store the read values into. */ void readSensorsInto(Collection<? super Number> sink) {  sink.add(sensor1.readInt());  sink.add(sensor2.readFloat());  sink.add(sensor3.readBigDecimal()); }
Obviously, you'd never write actual code like this, but let's just roll with it for now.

The readSensorsInto() method accepts a Collection<? super Number> because it doesn't care whether you pass it a Collection<Number> or a Collection<Object>, as long as it can dump arbitrary numbers into it.

Polymorphism says that you may always assign a reference of some type S to a variable of a supertype T, never the other way around. That means that whatever we assign to the sink parameter, is must be a subtype of Collection<? super Number>. Since we can assign an ArrayList<Number> or an ArrayList<Object>, it necessarily means that those are both subtypes of Collection<? super Number>.

I hope you agree that the following code makes sense:
var readValues = new ArrayList<Object>(); readSensorsInto(readValues); for (var value: readValues) {  System.out.println(value); }
And that the following code does NOT make sense:
var readValues = new ArrayList<Integer>(); readSensorsInto(readValues); for (var value: readValues) {  System.out.println(value); }
You shouldn't be able to add arbitrary number types into an ArrayList<Integer>.

The rule that allows the sensical use case of passing in an ArrayList<Object> and that prevents the disastrous use case of passing in an ArrayList<Integer> is the rule that says that ArrayList<Object> is a subtype of Collection<? super Number> and that says that ArrayList<Integer> is NOT a subtype of Collection<? super Number>.

Stephan van Hulst wrote:

Think of a List<? super Integer> as "a list that accepts integers".

Think of a List<? super Number> as "a list that accepts numbers".

A list that accepts numbers is also a list that accepts integers. Therefore, List<? super Number> is a subtype of List<? super Integer>.

Conversely, a list that accepts integers is not a list that accepts numbers, because it cannot accept all different kinds of numbers.

This makes it clear! Thanks!
I was trying to make a similar example out of the wildcards example from Cay Horstman's book on Java 17 where he says that Manager and Janitor objects cannot be in the same list. But I see that managersAndSupers is a list that accepts managers and is a subtype of a list that accepts employees.


         List<? super Employee> employeesAndSupers = new ArrayList<Employee>();        List<? super Manager> managersAndSupers = new ArrayList<Manager>();        employeesAndSupers.add(new Janitor(1));        employeesAndSupers.add(new Manager(5));        managersAndSupers = employeesAndSupers;        System.out.println(managersAndSupers);

output:

[Janitor{1}, Manager{5}]

To tweak this a little more:

Think of a List<? super Integer> as "a list that accepts Integers".  It might have previously been described as a List<Integer>, a list that only accepts Integers.  It might have previously been described as a list that accepts Numbers (including Integers).  Or it might have previously been described a list that accepts any Object (including Integers and other Numbers).  Of these, the only behavior that you (and the compiler) can rely on is that whatever else it is, it definitely accepts Integers.

Think of a List<? super Number> as "a list that accepts Numbers".  It might be a list that only accepts Numbers.  It might be a list that accepts any Object.  Of these, the only behavior that you can rely on is that whatever else, it definitely accepts Numbers.

Stephan van Hulst wrote:Therefore, List<? super Number> is a subtype of List<? super Integer>.

I had a further thought. Is it correct that:
ArrayList<? super Number> is a subtype of ArrayList<? super Integer> ArrayList<? super Number> is a subtype of ArrayList<? super Float> ArrayList<? super Number> is a subtype of ArrayList<? super Double> ArrayList<? super Number> is a subtype of ArrayList<? super Short>

But that would be multiple inheritance by classes - which is not allowed by Java.

Anil Philip wrote:Is it correct that:
ArrayList<? super Number> is a subtype of ArrayList<? super Integer> ArrayList<? super Number> is a subtype of ArrayList<? super Float> ArrayList<? super Number> is a subtype of ArrayList<? super Double> ArrayList<? super Number> is a subtype of ArrayList<? super Short>

Yes.

Anil Philip wrote:But that would be multiple inheritance by classes - which is not allowed by Java.

Well, that's not really true.  You may have heard that multiple inheritance is not allowed in Java - but that's an oversimplification.  It's not allowed for a class to directly extend more than one class - that's true.  But a class can directly implement more than one interface.  And an interface can directly extend more than one interface.  So even before they added generics, there was no absolute rule against multiple inheritance of types.  There's still just a rule against direct inheritance of more than one class.  

That's still true in your example - the class of all your examples is ArrayList, period.  The one direct superclass of ArrayList is AbstractList.  And the one direct superclass of AbstractList is AbstractCollection.  And the one direct superclass of AbstractCollection is Object.  That's it.

Now they also all implement a variety of interfaces, like List, Collection, Iterable, Cloneable, Serializable, and RandomAccess.  And they can also have a variety of different generic types.  But those are not covered by the rule against multiple inheritance.

Mike Simmons wrote:But a class can directly implement more than one interface.  ...
Now they also all implement a variety of interfaces, like List, Collection, Iterable, Cloneable, Serializable, and RandomAccess.  And they can also have a variety of different generic types.  But those are not covered by the rule against multiple inheritance.

But that is what I am pointing out.
This is a single type multiply inheriting a number of classes , not interfaces and is disallowed in Java.
To put it differently:

ArrayList<? super Number> extends ArrayList<? super Integer>, ArrayList<? super Float >, ArrayList<? super Double>, ArrayList<? super Short>

When you invert the inheritance hierarchy, it looks like that is what you get.

Anil Philip wrote:When you invert the inheritance hierarchy, it looks like that is what you get.

Yes.

It looks like this quote which I just came across may apply:

John von Neuman wrote:In mathematics, you don't understand things, you just get used to them.

Anil Philip wrote:. . . a single type multiply inheriting a number of classes . . . it looks like that is what you get.

It only looks like it; as MS said, that class only extends one superclass.

I'm not really understanding the issue here.

Classes always extend exactly one other class, except the Object class, which extends no other class.

ArrayList<? super Number> is a subtype of ArrayList<? super Integer>, this is true.

But who said that ArrayList<? super Number> is a class?

ArrayList<? super Number> is not a class at all. It is a parameterized type.

ArrayList is a class, and it extends exactly one other class: AbstractList.

Subtyping/supertyping and Inheritance are two different things. What constitutes a subtype/supertype relation is explicitly defined by the JLS in Section 4.10. This definition does include subclasses/superclassess/superinterfaces but only as one of the constituents.

The point is, it is true that ArrayList<? super Number> is a subtype of ArrayList<? super Integer> (and others) but that does not mean ArrayList<? super Number> inherits from ArrayList<? super Integer>. Java does not have multiple implementation inheritance and having multiple subtype/supertype relationships does not violate that. There is no contradiction.

Inheritance is real. Subtyping is "legal fiction".

(Fixed grammar typo)

Stephan van Hulst wrote:

ArrayList<? super Number> is not a class at all. It is a parameterized type.

It is not a class, indeed, but it is a type. Subclass and subtype are often used interchangeably for convenience because there is a lot of overlap between the two and that is the cause of confusion here, I think. They are technically different things.

Stephan van Hulst wrote:A type can not be a subset of another type because types are not sets.

Oh but they are. That is how the JLS defines them. See section 4.5: A class or interface that is generic (§8.1.2, §9.1.2) defines a set of parameterized types.

It doesn't help that the file format in which compiled Java types are serialized is also called "class", regardless of whether it serializes an actual class, an interface, a package declaration or a module declaration; and that the Class class is used to reify types that are not just classes.

Paul Anilprem wrote:

Stephan van Hulst wrote:A type can not be a subset of another type because types are not sets.

Oh but they are. That is how the JLS defines them. See section 4.5: A class or interface that is generic (§8.1.2, §9.1.2) defines a set of parameterized types.

Curious.  They don't really elaborate on this statement.  Note that it does not actually say that a class that is generic is a set of parameterized types.  They say it defines a set of parameterized types.  Not quite the same thing - and I don't see a further explanation of this use of "set".  But I believe it refers to the fact that a class or interface can define multiple nested types, in addition to defining a type for itself.  So for example, the Map interface defines two parameterized types, Map<K><V> and Map.Entry<K,V>.  Most generic classes or interfaces will define a set of exactly one parameterized type... but some will define more.

Unless you see or can think of another way to interpret the "set" here...

Mike Simmons wrote:But I believe it refers to the fact that a class or interface can define multiple nested types, in addition to defining a type for itself.

Yes, that makes more sense.

Stephan van Hulst wrote:A type can not be a subset of another type because types are not sets.

Is this referring to

Ira Go wrote: <? super Number> wildcard bound is a subset of <? super Integer>.

Those are bounded wildcards. They are sets of types.
<? super Number>  => [java.lang.Object,  java.lang.Number]
<? super Integer>    => [java.lang.Object,  java.lang.Number,  java.lang.Integer]
So, <? super Number> is a subset (in math terms) of <? super Integer>. Isn't it?

Here is from the JSL 4.5.1. Type Arguments of Parameterized Types:

The Java® Language Specification wrote:A type argument T1 is said to contain another type argument T2, written T2 <= T1, if the set of types denoted by T2 is provably a subset of the set of types denoted by T1 under the reflexive and transitive closure of the following rules (where <: denotes subtyping (§4.10)):

? extends T <= ? extends S if T <: S

? extends T <= ?

? super T <= ? super S if S <: T

? super T <= ?

? super T <= ? extends Object

T <= T

T <= ? extends T

T <= ? super T

Ira Go wrote:Is this referring to

Ira Go wrote:<? super Number> wildcard bound is a subset of <? super Integer>.

No.

I was referring to:

Anil Philip wrote:Shouldn't they say subset instead of subtype in both the "hierarchy rules"?

Which in turn refers to:

Anil Philip wrote:Hierarchy 2 <T> <<< A<? super T> <<< A<? super S> Example: List<Number> is a subtype of List<? super Number> and List<? super Number> is a subtype of List<? super Integer> Thus, if an overridden method returns List<? super Number>, the overriding method can return List<Number> but not List<Integer> or List<? super Integer>.  
It is important to understand that List<Integer> is not a subtype of List<Number> even though Integer is a subtype of Number.

I was countering Anil's question whether the correct wording was subset rather than subtype. List<Number> is NOT a subset of List<? super Number>, because List<Number> is a type, not a set.

Any philosophical or set-theoretical debate than ANYTHING can be classified as a set some way is not really helpful in this context.

Those are bounded wildcards. They are sets of types.

Sure, but the original text that Anil took exception to does not refer to the bounded wildcards. Instead, it refers to the parameterized types. And again, in this context, parameterized types are not sets of types. According to the part of the JLS that Paul Anilprem mentioned, they may "define" sets of types, but the original wording that sparked this entire tangent is correct as it is:

Example: List<Number> is a subtype of List<? super Number>

I totally misread Anil's question.