ITSC 1213 - Introduction to CS 2 How to Design Programs with Object Oriented Programming

Subsection 10.11.1 What is Type Erasure?

• Code written using generics (e.g., Box<String>) is checked for type correctness by the compiler.
  🔗
• • An unbounded type parameter like T in Box<T> is replaced by Object. So, Box<String> and Box<Integer> both become just Box in the bytecode, storing Object references internally.
    🔗
  • A bounded type parameter like T extends Number is replaced by its bound (Number). So, NumericBox<Integer> becomes NumericBox in the bytecode, storing Number references internally.
    🔗
  🔗
• The compiler also automatically inserts necessary type casts into the calling code’s bytecode wherever you retrieve an element from a generic type. Since the compiler already verified the type safety at compile time, these automatically inserted casts are guaranteed to be safe at runtime.
  🔗

Box<String> stringBox = new Box<>();
stringBox.set("Type Safe");
String s = stringBox.get(); // No cast needed in source code

// Conceptual Bytecode-Level Approximation (after erasure)
Box rawBox = new Box(); // T replaced by Object
rawBox.set("Type Safe"); // Argument is treated as Object
String s = (String) rawBox.get(); // Compiler inserts the cast automatically and safely!

Subsection 10.11.2 Why Type Erasure? Backward Compatibility

• Migration Compatibility: New code using generics (like List<String>) could still interact with older ("legacy") methods that expected raw types (like List). The compiler would issue warnings but allow the interaction, preserving the functionality of existing libraries.
  🔗
• Binary Compatibility: Compiled code from older Java versions could largely continue to run on newer JVMs without recompilation.
  🔗

Box rawBox = new Box(); // Using the raw type (no <...>)
rawBox.set("A String"); // Compiles (treated as Object)
rawBox.set(123);      // Compiles (treated as Object) - Potential for mix-ups!

// Requires casting and risks ClassCastException, just like ObjectBox
String s = (String) rawBox.get(); // Risky! Currently holds an Integer.

Subsection 10.11.3 Implications and Limitations of Type Erasure

1. Cannot Create Instances of Type Parameters (new T())

   🔗
   Due to erasure, you cannot directly create an instance of a type parameter T using new T(). At runtime, the JVM only sees Object (or the bound type) and wouldn’t know which specific class constructor (new String()? new Player()?) to actually call.

   🔗

   public class Factory<T> {
       public T createInstance() {
           // return new T(); // Compile Error! Cannot instantiate the type T due to erasure.
           return null; // Placeholder
       }
   }
   

   Common Workarounds: One common pattern is to pass a Class<T> object (which retains type information at runtime) to the constructor or method, and then use reflection methods like newInstance() (though this itself has limitations and potential exceptions to handle).

   🔗

   // Example using Class<T> token (simplified)
   public class ReflectiveFactory<T> {
       private Class<T> typeToken;
   
       public ReflectiveFactory(Class<T> typeToken) {
           this.typeToken = typeToken;
       }
   
       public T createInstance() {
           try {
               // Use reflection via the Class object (requires accessible no-arg constructor)
               // Note: newInstance() is deprecated; modern reflection is more complex.
               // This is just for illustrating the concept.
               return typeToken.newInstance();
           } catch (InstantiationException | IllegalAccessException e) {
               // Handle exceptions appropriately
               e.printStackTrace();
               return null;
           }
       }
   }
   
   // Usage:
   // ReflectiveFactory<String> stringFactory = new ReflectiveFactory<>(String.class);
   // String myNewString = stringFactory.createInstance();
   

   🔗
2. Cannot Create Arrays of Generic Types (new T[size])

   🔗
   Due to erasure, you cannot create an array whose element type is a generic type parameter, like new T[10]. Arrays in Java store their component type information at runtime for type checking array assignments. Since T is erased, the runtime wouldn’t know the actual required type, potentially leading to type safety violations (heap pollution) if it were allowed.

   🔗

   public class GenericArrayHolder<T> {
       private T[] elements;
   
       public GenericArrayHolder(int size) {
           // this.elements = new T[size]; // Compile Error! Cannot create a generic array of T due to erasure.
           // Common but unsafe workaround (requires cast, disables array store checks):
           // this.elements = (T[]) new Object[size];
       }
   }
   

   Common Workarounds: Avoid creating generic arrays directly. Use a generic collection like ArrayList<T>, which manages an internal Object[] safely. If an array is truly needed, use Object[] and manage casts carefully, or use reflection-based array creation (which is complex).

   🔗
   🔗
3. Cannot Use instanceof with Parameterized Types

   🔗
   Due to erasure, you generally cannot use instanceof to check if an object is an instance of a specific generic parameterization at runtime. The type argument information (String in Box<String>) isn’t available for the check.

   🔗

   Box<String> stringBox = new Box<>();
   Box<Integer> integerBox = new Box<>();
   
   // if (stringBox instanceof Box<String>) { ... } // Compile Error! Illegal generic type for instanceof
   
   // You CAN check against the raw type (erased type):
   if (stringBox instanceof Box) { // OK - Checks if it's any kind of Box
       System.out.println("It's a Box!");
   }
   

   At runtime, both stringBox and integerBox are just instances of the raw type Box.

   🔗
   🔗
4. Static Context Restrictions

   🔗
   Due to erasure, a class’s type parameter (T in Box<T>) cannot be referenced from static methods, static fields, or static inner classes of that generic class. Static members belong to the class itself (e.g., Box.staticMethod()), not to any particular instance like Box<String> or Box<Integer>. Since static members exist independently of any instance-specific type argument for T, they cannot use T.

   🔗

   public class Counter<T> {
       private T instanceItem; // OK - Instance field
   
       // private static T staticItem; // Compile Error! Cannot make a static reference to type T.
   
       // public static T getStaticItem() { ... } // Compile Error! Static method cannot use T.
   
       // Note: Static generic methods ARE allowed, but they declare their OWN type parameters:
       public static <E> E identity(E item) { return item; } // OK
   }
   

   🔗

Subsection 10.11.4 Summary: Living with Type Erasure

• Benefit: Enables interaction between generic and non-generic legacy code.
  🔗
• Consequence: Type parameter information is generally unavailable at runtime.
  🔗
• Limitations: Leads to restrictions like the inability to use new T(), new T[], or instanceof Box<T>, and prevents static members from using class type parameters. These occur because type information is erased.
  🔗