Some Understandings of wildcards in Java generics

Replacement Principle
Based on some object-oriented features of Java, we can easily understand such a replacement principle:

A variable of the specified type can be assigned to any subclass of this type. A method that specifies a type parameter can be called by passing in a subclass of this type.

In general, that is to say, any type variable we use can be replaced by the Child type of this type.

An incorrect inheritance relationship in generics
In generic programming, when we consider the subtype relationship, it is easy to confuse a relationship and use the replacement principle incorrectly.

For example:

List <integer> ints = new arraylist <integer> ();
Ints. Add (1 );
Ints. Add (2 );
List <number> Nums = ints; // compile Error
In this code, we can see that the type parameter integer is the child type of number, so it is easy to take it for granted that list <integer> is also a subclass of list <number>. Actually not. Therefore, Type mismatch may occur, resulting in a compilation error.

Sometimes, we feel that such conversions do not seem to use the inheritance relationship between objects. If we can have a list that can process data of a certain type and all child data of this type, isn't it possible to use both the benefits of generics and the benefits of object relationships? The wildcard (wildcard) is introduced here ).

Wildcard (wildcard)
The collection interface definition in the Java class library contains a method that uses wildcards:

Interface collection <E> {
...
Public Boolean addall (collection <? Extends E> C );
...
}

In the description of the addall method, parameters of the collection type can be accepted. The type parameter in the collection can be any child type that inherits E.
Therefore, we can use this in actual code:

List <number> Nums = new arraylist <number> ();
List <integer> ints = arrays. aslist (1, 2 );
List <double> dbls = arrays. aslist (2.78, 3.14 );
Nums. addall (ints );
Nums. addall (dbls );
In the code, we can see that both list <integer> and list <double> are collection <? Extends number> type subclass. Therefore, the list types integer and double can be passed into the method in the above method.

Wildcard use limit 1:
It is interesting to use wildcard data types. Since we can use them as parameters for method declaration, can we use them as a variable type to directly create variables?

See the following code:
List <? Extends number> Nums = new arraylist <integer> (); // compile Error
In fact, the above Code cannot be compiled.

Wildcard use limit 2:
Since it cannot be used to directly create variable objects, let's look at the following code:

List <integer> ints = new arraylist <integer> ();
Ints. Add (1 );
Ints. Add (2 );
List <? Extends number> Nums = ints;
Nums. Add (3.14); // compile Error
The 5th lines of this Code cause compilation errors. In the 4th line of code, we assign the ints value to nums. On the surface, Nums is declared as a list <integer> parent type, so the 4th lines are compiled normally. Why is there an error in 5th lines of code? On the surface, since the Nums type can accept all parameters inherited from the number, it is no problem to add data of the double type. In fact, let's take another look at the problems that may arise:

Nums originally references a list that inherits from this type <integer>. If we allow data of the double type to be added, the list of integer ints contains double data, when we use ints, it does not match the expected data that only contains the integer type.

Therefore, this code also illustrates the problem? In the data types referenced by wildcards such as extends E, adding data operations to them may cause problems. Therefore, adding data to it is not allowed. But we can read data from it.

Summary:
1: wildcard-modified generics cannot be used to directly create variable objects.

2: wildcard modifier declares a variable, which can be passed as a parameter in the method. The benefit of doing so is that we can apply methods that contain lists of certain data types to lists that contain their subtypes. It is equivalent to using some object-oriented features in the list.