Type erasure — sự thật không dễ chịu của generics Java

Generics Java trông giống C#, C++, TypeScript — nhưng cơ chế bên dưới khác hoàn toàn. C# reified generics giữ type info ở runtime. Java dùng type erasure — xoá mọi type parameter lúc compile, bytecode không biết List<String> khác List<Integer>.

Lý do: backward compatibility với code pre-Java 5. Code không generics vẫn chạy bên cạnh code generics mới mà không phá binary. Giá phải trả: nhiều hạn chế tinh vi bạn sẽ gặp khi viết generic code phức tạp.

Bài này giải thích cơ chế erasure, hệ quả thực tế, heap pollution, và workaround (Class<T> token, reflection).

1. Cơ chế — compiler xoá type parameter

Source:

public class Box<T> {
    private T value;
    public void set(T value) { this.value = value; }
    public T get() { return value; }
}

Sau compile, bytecode tương đương:

public class Box {
    private Object value;
    public void set(Object value) { this.value = value; }
    public Object get() { return value; }
}

T biến mất. Trong bytecode, T bị thay bằng:

• Object nếu không có bound.
• Bound class nếu có T extends X → thay bằng X.

public class Sorted<T extends Comparable<T>> {
    private T value;
    // bytecode: private Comparable value;
}

1.1 Compiler thêm cast tự động

Client code:

Box<String> box = new Box<>();
box.set("hello");
String s = box.get();

Compile thành:

Box box = new Box();   // raw
box.set("hello");
String s = (String) box.get();   // CAST tu dong

Compiler chèn cast (String) tại mọi chỗ gọi get() — bạn không thấy nhưng bytecode có. Đây là lý do lỗi ClassCastException thỉnh thoảng xuất hiện ở dòng không có cast nào trong source — cast ẩn từ generics.

2. Bridge Methods — Cầu nối duy trì tính đa hình ở runtime

Sau khi biên dịch, cơ chế Type Erasure biến các tham số kiểu generic thành Object (hoặc bound tương ứng). Tuy thế, điều này lại tạo ra một vấn đề lớn đối với tính đa hình (Polymorphism) khi kế thừa hoặc hiện thực một generic class/interface.

Hãy xem xét ví dụ dưới đây:

// Lớp cha generic
public class Node<T> {
    public void setData(T data) {
        System.out.println("Node.setData");
    }
}

// Lớp con kế thừa lớp cha với kiểu cụ thể Integer
public class MyNode extends Node<Integer> {
    @Override
    public void setData(Integer data) {
        System.out.println("MyNode.setData: " + data);
    }
}

Nếu phân tích bytecode của hai lớp này sau khi bị Type Erasure, ta sẽ thấy:

1. Lớp Node bị xóa kiểu thành:
   public class Node {
       public void setData(Object data) { ... }
   }
   

2. Lớp MyNode có phương thức:
   public class MyNode extends Node {
       public void setData(Integer data) { ... }
   }
   

Vấn đề xuất hiện: Phương thức setData(Integer) của MyNode không trùng khớp chữ ký (method signature) với setData(Object) của Node. Ở cấp độ JVM, đây là hiện tượng Overloading (Nạp chồng) chứ không phải Overriding (Ghi đè)!

Do đó, nếu một client sử dụng đa hình thông qua lớp cha:

Node node = new MyNode();
node.setData(5); // Tại runtime, JVM sẽ cố tìm setData(Object) để thực thi

Do không có override thực sự, lời gọi node.setData(5) sẽ thực thi phương thức setData(Object) của lớp cha Node thay vì phương thức mong đợi của lớp con MyNode. Điều này phá vỡ hoàn toàn nguyên lý đa hình căn bản.

Giải pháp của Compiler: Tự động sinh Bridge Method

Để duy trì tính đa hình ở runtime, trình biên dịch Java đã âm thầm tạo ra một phương thức phụ trong bytecode của lớp con MyNode, gọi là Bridge Method (phương thức cầu nối):

// Bytecode tự động sinh ra trong MyNode (Bridge Method)
public void setData(Object data) {
    this.setData((Integer) data); // Ép kiểu an toàn và chuyển tiếp lời gọi
}

Bridge method này có chữ ký trùng khớp hoàn hảo với Node.setData(Object) của lớp cha. Khi client thực hiện lời gọi qua lớp cha, JVM sẽ điều hướng đa hình đến bridge method trong MyNode, tại đây dữ liệu được ép kiểu runtime về Integer rồi chuyển tiếp đến phương thức setData(Integer) do bạn viết.

3. Hệ quả 1 — không new T()

public class Factory<T> {
    public T create() {
        return new T();   // COMPILE ERROR
    }
}

Lý do: runtime T là Object — compiler không biết phải gọi constructor nào. Workaround đã nói ở bài 1: pass factory qua Supplier<T> hoặc Class<T>.

public class Factory<T> {
    private final Supplier<T> supplier;
    public Factory(Supplier<T> supplier) { this.supplier = supplier; }
    public T create() { return supplier.get(); }
}

new Factory<>(User::new).create();

4. Hệ quả 2 — không instanceof T

public class Container<T> {
    public boolean contains(Object obj) {
        return obj instanceof T;   // COMPILE ERROR
    }
}

Runtime không biết T → không check được. Workaround: pass Class<T> token:

public class Container<T> {
    private final Class<T> type;

    public Container(Class<T> type) { this.type = type; }

    public boolean contains(Object obj) {
        return type.isInstance(obj);
    }
}

Class.isInstance(obj) thay cho obj instanceof T — runtime check dựa vào Class<T> token bạn pass vào.

5. Hệ quả 3 — không generic array

T[] arr = new T[10];              // COMPILE ERROR
List<String>[] lists = new List<String>[10];   // COMPILE ERROR

Array Java biết kiểu runtime (int[], String[]) qua array covariance. Generic bị erase → tạo generic array phá type safety:

// Gia su duoc phep:
List<String>[] arr = new List<String>[1];
Object[] objArr = arr;           // array covariance
objArr[0] = List.of(1, 2, 3);    // Object[] nhan List<Integer> — bypass check
String s = arr[0].get(0);         // ClassCastException — la Integer

Java cấm để ngăn pattern này. Workaround:

// Cach 1: dung List thay array
List<List<String>> lists = new ArrayList<>();

// Cach 2: cast raw array
@SuppressWarnings("unchecked")
List<String>[] arr = (List<String>[]) new List[10];
// WARNING "unchecked cast" — phai verify ban khong lam sai

Cách 1 đa số tốt hơn — rộng hơn, type-safe.

6. Hệ quả 4 — overload không khác nhau nếu erase ra cùng kiểu

public class Foo {
    public void process(List<String> list) { }
    public void process(List<Integer> list) { }   // COMPILE ERROR
}

Cả 2 erase thành process(List) → cùng signature bytecode → conflict. Compiler bắt tại compile time.

Fix: đổi tên method hoặc đổi signature khác.

7. Hệ quả 5 — không catch generic exception

public class MyException<T> extends Exception { }   // COMPILE ERROR

catch (MyException<String> e) ở runtime không phân biệt được với catch (MyException<Integer> e) — exception dispatch dựa vào class, erase làm mất thông tin. Java cấm generic trên Throwable.

8. Heap pollution — type safety bị phá ngầm

Erasure tạo kẽ hở: có thể nhét element sai kiểu vào List<String> mà không báo lỗi compile:

List<String> strings = new ArrayList<>();
List rawList = strings;          // raw reference — warning unchecked
rawList.add(42);                  // compile OK, warning unchecked

String s = strings.get(0);        // ClassCastException RUNTIME

rawList bypass type check; 42 lọt vào list. Khi get(0) returns Integer và compiler cast sang String → ClassCastException.

Đây gọi là heap pollution: tại runtime có object không khớp type parameter khai báo. JVM không phát hiện được (không có info), chỉ fail khi dùng.

7.1 Varargs + generic = heap pollution frequent

public static <T> List<T> asList(T... items) {
    return Arrays.asList(items);   // warning: unchecked
}

Varargs generic tạo T[] nội bộ — như đã nói, generic array không an toàn. Compiler warning "unchecked generic array creation". Fix: @SafeVarargs nếu bạn đảm bảo method không leak reference array ra ngoài.

9. Class<T> token — workaround phổ biến

Nhiều API muốn type runtime → nhận Class<T>:

public <T> T fromJson(String json, Class<T> type) {
    // dung type.isInstance, type.newInstance, reflection
}

User u = json.fromJson(jsonString, User.class);

User.class là Class<User> object — chứa type info runtime. Jackson, Gson, JPA... đều dùng pattern này.

9.1 Kỹ thuật Super Type Tokens (Neal Gafter)

Như đã phân tích, Class<T> bất lực trước các kiểu generic phức tạp như List<User> vì List<User>.class là cú pháp không hợp lệ (mọi thông tin kiểu generic bị xóa sạch).

Để giải quyết giới hạn này, chuyên gia Java Neal Gafter đã đề xuất kỹ thuật Super Type Tokens. Ý tưởng cốt lõi tận dụng một đặc tính trong cơ chế Type Erasure: Mặc dù thông tin kiểu của các thực thể (instance) bị xóa sạch, nhưng siêu thông tin kiểu (metadata) của các lớp con (subclasses) vẫn được lưu lại trong file .class.

Khi bạn viết:

// Gson
Type listType = new TypeToken<List<User>>(){}.getType();
List<User> users = gson.fromJson(json, listType);

// Spring RestTemplate
ResponseEntity<List<User>> response = restTemplate.exchange(
    url, GET, null, new ParameterizedTypeReference<List<User>>(){});

Hãy chú ý cặp dấu ngoặc nhọn trống {} ở cuối dòng khởi tạo new TypeToken<List<User>>() {}. Đây không phải là cú pháp khởi tạo thông thường, mà là cú pháp tạo ra một Anonymous Subclass (Lớp con ẩn danh) kế thừa từ TypeToken<List<User>>.

Tại sao Anonymous Subclass lại giữ được kiểu?

Khi biên dịch lớp con ẩn danh này, compiler bắt buộc phải lưu lại thông tin kiểu của lớp cha (TypeToken<List<User>>) vào thuộc tính Signature của Metadata class để phục vụ cho reflection.

Bên trong lớp TypeToken của Gson (hoặc ParameterizedTypeReference của Spring), mã nguồn xử lý như sau để lấy lại thông tin kiểu:

public class TypeToken<T> {
    private final Type type;

    protected TypeToken() {
        // Lấy thông tin generic superclass (TypeToken<List<User>>)
        Type superclass = getClass().getGenericSuperclass();
        
        if (superclass instanceof Class) {
            throw new RuntimeException("Missing type parameter.");
        }
        
        // Trích xuất kiểu tham số thực tế (List<User>)
        ParameterizedType parameterized = (ParameterizedType) superclass;
        this.type = parameterized.getActualTypeArguments()[0];
    }

    public Type getType() { return type; }
}

Bằng cách sử dụng getClass().getGenericSuperclass(), JVM truy cập trực tiếp vào siêu dữ liệu của lớp con ẩn danh ở runtime, từ đó lách qua được cơ chế Type Erasure và lấy ra chính xác đối tượng kiểu List<User> một cách trọn vẹn. Hack nhưng hoạt động cực kỳ hiệu quả và an toàn.

10. Case Study: Triết lý thiết kế & Đánh đổi (Trade-off) — Java Type Erasure vs C# Reified Generics

Khi giới thiệu Generics, hai ngôn ngữ lập trình lớn là Java (với Java 5 năm 2004) và C# (với .NET 2.0 năm 2005) đã đưa ra hai hướng đi hoàn toàn trái ngược nhau để giải quyết cùng một bài toán. Hãy cùng phân tích sâu case study này để hiểu rõ tư duy thiết kế hệ thống đứng sau:

10.1 Bối cảnh lịch sử

• Java (2004): Java đã có 9 năm lịch sử với hàng tỷ dòng code đang vận hành trong các hệ thống doanh nghiệp toàn cầu. Bất kỳ sự thay đổi lớn nào phá vỡ ứng dụng cũ đều là "thảm họa".
• C# (2005): Hệ sinh thái .NET của Microsoft còn tương đối non trẻ. Microsoft có toàn quyền kiểm soát cả ngôn ngữ lẫn môi trường thực thi CLR (Common Language Runtime) và sẵn sàng thực hiện các thay đổi đột phá.

10.2 Sự khác biệt cốt lõi về mặt kỹ thuật

10.3 Phân tích Triết lý thiết kế & Đánh đổi (Trade-offs)

Lựa chọn của Java: Ưu tiên sự ổn định của hệ sinh thái

Java chọn Type Erasure để đạt được mục tiêu tối thượng: Tương thích ngược tuyệt đối (Backward Compatibility).

• Được:
  • Migration mượt mà: Một ứng dụng chạy Java 1.4 có thể nâng cấp lên Java 5 và sử dụng các thư viện Generics mới mà không cần sửa đổi bất kỳ dòng code cũ nào hoặc biên dịch lại.
  • Bytecode nhỏ gọn: Chỉ có một lớp ArrayList duy nhất được tải vào bộ nhớ, không phụ thuộc vào việc ứng dụng khai báo bao nhiêu kiểu tham số khác nhau.
• Mất: Lập trình viên phải chịu đựng cú pháp phức tạp (không thể tạo mảng generic, lỗi ClassCastException ẩn, heap pollution) và chịu chi phí overhead hiệu năng do Auto-boxing của primitive type.

Lựa chọn của C#: Ưu tiên sự tối ưu kỹ thuật & Trải nghiệm nhà phát triển

C# chọn Reified Generics để xây dựng một kiến trúc chuẩn chỉ, hiệu năng cao nhất.

• Được:
  • Không có auto-boxing overhead cho primitive types, giúp ứng dụng C# có lợi thế hiệu năng tính toán vượt trội so với Java.
  • Trải nghiệm lập trình viên cực kỳ mượt mà, trực quan (có thể new T(), typeof(T) thoải mái).
• Mất: Phá vỡ tính tương thích nhị phân trực tiếp. Ứng dụng viết trên .NET 1.1 bắt buộc phải được biên dịch lại hoàn toàn để chạy trên .NET 2.0. Toàn bộ hệ sinh thái phải trải qua một quá trình nâng cấp (migration) bắt buộc và tốn kém chi phí.

Bài học thực chiến

Không có giải pháp nào là hoàn hảo tuyệt đối, chỉ có giải pháp phù hợp với triết lý của từng ngôn ngữ. Java hy sinh sự mượt mà cú pháp để bảo vệ hàng chục năm di sản code của khách hàng doanh nghiệp. C# chấp nhận phá vỡ cái cũ để đổi lấy một nền tảng kỹ thuật tối tân nhất cho tương lai.

11. Ưu điểm của erasure

Không phải toàn tệ — erasure có lý do:

• Backward compat: code pre-Java 5 chạy cùng code generic mới mà không phá binary. Quan trọng cho một ngôn ngữ dùng 20 năm.
• Bytecode nhỏ: một class List cho mọi T, không phải mỗi List<Integer>, List<String> một class bytecode.
• Tương thích với JVM cũ: generics thêm vào JVM mà không thay đổi JVM spec.

C# reified generics đẹp hơn về runtime info, nhưng C# có toàn quyền breaking binary compat giữa version — Java không thể.

12. Pitfall tổng hợp

❌ Nhầm 1: Tưởng List<String> khác List<Integer> ở runtime.

if (list instanceof List<String>) { ... }   // COMPILE ERROR

✅ Check List<?> chung hoặc lấy element rồi check kiểu.

❌ Nhầm 2: new T(). ✅ Pass Supplier<T> hoặc Class<T>.

❌ Nhầm 3: Raw type làm bypass check.

List<String> strings = ...;
List raw = strings;
raw.add(42);   // heap pollution

✅ Không dùng raw. @SuppressWarnings("unchecked") đánh dấu rõ khi cần.

❌ Nhầm 4: Generic exception.

class MyException<T> extends Exception { }   // COMPILE ERROR

✅ Exception không generic; pass data qua field thường.

❌ Nhầm 5: Array generic.

T[] arr = new T[10];    // COMPILE ERROR

✅ List<T> thay array.

13. 📚 Deep Dive Oracle

14. Tóm tắt

• Type erasure: compiler xoá type parameter T, thay bằng Object (hoặc bound). Bytecode không biết T là gì.
• Compiler tự chèn cast (T) tại call site — bạn không thấy nhưng runtime có.
• Bridge Methods: compiler tự động sinh ra trong bytecode của lớp con khi override một generic class/interface để duy trì tính đa hình ở runtime.
• Hệ quả: new T(), instanceof T, T[], generic exception — đều không làm được.
• Heap pollution: qua raw type, có thể đưa object sai kiểu vào List<T> — ClassCastException ở chỗ get() không có cast rõ.
• Workaround: Class<T> token, Supplier<T>, TypeToken / ParameterizedTypeReference (Super Type Tokens).
• Overload 2 method có signature erase giống nhau → compile error.
• Lý do erasure: backward compat với code pre-Java 5 + bytecode nhỏ.
• Project Valhalla đang thử sửa — chưa production.

15. Tự kiểm tra

List<String> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
System.out.println(a.getClass() == b.getClass());

List<String> strings = new ArrayList<>();
List raw = strings;
raw.add(42);
String s = strings.get(0);
System.out.println(s.length());

public class Factory {
    public void process(List<String> list) { }
    public void process(List<Integer> list) { }
}

public static <T> List<T> filterByType(List<?> list, Class<T> type) { ... }

public static <T> List<T> filterByType(List<?> list, Class<T> type) {
    List<T> result = new ArrayList<>();
    for (Object o : list) {
        if (type.isInstance(o)) {
            result.add(type.cast(o));
        }
    }
    return result;
}

// Su dung:
List<Object> mixed = List.of("hello", 42, "world", 3.14, "java");
List<String> strings = filterByType(mixed, String.class);
// strings = ["hello", "world", "java"]

List<Integer>[] lists = new List<Integer>[10];

// Neu cho phep:
List<Integer>[] a = new List<Integer>[1];
Object[] b = a;           // array covariance: Subtype[] -> Supertype[]
b[0] = List.of("x");       // Object[] nhan List<String> — khong check gi
Integer n = a[0].get(0);   // ClassCastException — thuc ra la String

Bài tiếp theo: Wildcard ? extends, ? super và PECS rule