From the beginning, I learned how to compare arrays and generic containers in java-13.11 and observe what problems type erasure brings to generic containers?

From the beginning, I learned how to compare arrays and generic containers in java-13.11 and observe what problems type erasure brings to generic containers?

In this section, we will continue with the topic of Type erasure. We will compare arrays with generic containers and observe what problems type erasure brings to generic containers?

1. Array

package com.ray.ch13;public class Test {public static void main(String[] args) {Fruit[] fruits = new Apple[5];fruits[0] = new Apple();fruits[1] = new Fuji();fruits[2] = new Fruit();}}class Fruit {}class Apple extends Fruit {}class Fuji extends Apple {}

Looking at the code above, we can see that although the definition is only an array of Fruit, it can be put into child-type objects such as Apple and Fuji, because the array is a reference of the object, in addition, it can be transformed upwards at runtime.

2. Generic containers

General Usage:

package com.ray.ch13;import java.util.ArrayList;public class Test {public static void main(String[] args) {ArrayList
 
   fruits = new ArrayList
  
   ();fruits.add(new Fruit());fruits.add(new Apple());fruits.add(new Fuji());}}class Fruit {}class Apple extends Fruit {}class Fuji extends Apple {}
  
 

The above is our common usage. We define a List container and fill in the same type in the wildcard.

However, let's look at the features of upward transformation to see if they can be like arrays?

Example:

Package com. ray. ch13; import java. util. ArrayList; public class Test {public static void main (String [] args) {// ArrayList
 
  
Fruits = new ArrayList (); // errorArrayList fruits = new ArrayList (); // fruits. add (new Apple (); // error // fruits. add (new Fruit (); // errorfruits. add (null); // here it can only be null, no other options} class Fruit {} class Apple extends Fruit {} class Fuji extends Apple {}
 

Observe the code above. We wanted to define the generic type as the Fruit subclass when creating the list, just like the array. However, the compiler throws an exception. This is because generics are not fully defined. They only check the type security in the compiler and do not have the concept of generics at runtime. When we define it, we use the wildcard "?". That is to say, I can put it into the Fruit itself or sub-class, the compiler can know, but at runtime, jvm only knows to put in the Object, and when it is created, it defines the Apple sub-class, although the compiler knows, but at runtime, jvm only knows that the Object is put in. This will cause type security problems during runtime. Therefore, when any object we put will cause type security, the compiler can only provide the null option, otherwise there will inevitably be a type security risk.

In general, because arrays are fully defined, both the compiler and runtime will perform type detection, or the array itself is an object, while the generic container only checks the type security in the compiler, during the runtime, all objects are objects, but they are semi-defined, or generic containers do not hold objects, which leads to the problems shown above.

Summary: This chapter compares arrays and generic containers to observe the problems caused by type erasure.

This chapter is here. Thank you.