Type Erasure

A generics típusinformációjának nagy része compile-time segédlet, runtime alatt type erasure miatt eltűnik.

1. Definíció

A type erasure azt jelenti, hogy a fordító a generikus típusinformáció nagy részét eltávolítja, és a bytecode-ban jellemzően a felső korlát vagy Object marad. Interjún ez azért fontos, mert ebből következnek a generics korlátai: nincs new T(), nincs List<String>.class, és az overloadok is ütközhetnek. Ez a téma összeköti a nyelvi szintaxist a JVM kompatibilitási döntéseivel. A Java úgy vezette be a generics-et, hogy a régi bytecode és a régi API-k továbbra is működjenek.

2. Alapfogalmak

Fogalom	Jelentés	Miért fontos
Type erasure	A generikus típusinformáció eltávolítása fordítás után	Runtime-on a List<String> és List<Integer> ugyanaz a nyers típus.
Compile-time ellenőrzés	A fordító validálja a típusokat	Sok hiba már fordításkor kiderül.
Runtime korlát	A JVM nem lát minden generikus részletet	Bizonyos reflection és példányosítási minták nem működnek közvetlenül.
Bridge method	A fordító által generált segédmetódus	Polimorfizmust őriz meg generikus felületeknél.
Reifiable type	Olyan típus, ami runtime-on teljesen ismert	Például String[], de nem List<String>.

• A generics elsődleges nyeresége compile-time: a fordító castokat illeszt be és ellenőrzi a kompatibilitást.
• Runtime alatt a legtöbb generikus információ nem marad meg, ezért nem lehet például if (list instanceof List<String>) formát használni.
• Az array és a generics közti különbség klasszikus interjútéma: az array reified, a generics erase-elt.
• A bridge method-ok miatt generikus öröklésnél a forráskódnál több metódus jelenhet meg a bytecode-ban.

3. Gyakorlati használat

A(z) Type Erasure témában a legfontosabb gyakorlati kérdés mindig az, hogy milyen use-case-re választasz eszközt. A jó interjúválasz itt nem csak azt mondja meg, mit lehet csinálni, hanem azt is, mikor érdemes és mikor nem.

• Kerüld az unchecked castot, és ha mégis kell, tedd egy kis, jól elszigetelt helyre dokumentáltan.
• Ha runtime típusinformáció kell, gyakran explicit Class<T> paramétert vagy type token mintát használnak.
• Ne próbálj generikus tömböt létrehozni közvetlenül; inkább kollekciót vagy reflection alapú megoldást használj óvatosan.
• Interjún külön említsd meg a back­ward compatibility szempontot: ezért választotta a Java az erasure modellt.

4. Kód példák

Egyszerű példa

import java.util.List;

public class ErasureDemo {
    public static void print(List<String> names) {
        System.out.println(names.getClass());
    }

    public static void main(String[] args) {
        List<String> strings = List.of("a", "b");
        List<Integer> numbers = List.of(1, 2);

        System.out.println(strings.getClass() == numbers.getClass());
        // true
    }
}

Haladó példa

class Repository<T> {
    public T create() {
        throw new UnsupportedOperationException();
    }
}

class UserRepository extends Repository<String> {
    @Override
    public String create() {
        return "user";
    }
}

// A fordító bridge methodot generálhat, hogy az öröklés és a polimorfizmus
// bytecode szinten is konzisztens maradjon.

A kódpéldák interjún azért hasznosak, mert megmutatják, hogy a fogalmi szintű tudást le tudod fordítani konkrét API-használatra. Ha röviden el tudod magyarázni, miért így írod a példát, az általában többet ér, mint egy túlbonyolított demo.

5. Trade-offok

Szempont	Előny	Hátrány
Erasure modell	Visszafelé kompatibilis a régi JVM és könyvtárak felé	Runtime generikus információ korlátozott
Compile-time típusellenőrzés	Kevesebb cast és kevesebb futásidejű hiba	Nem old meg minden reflection-alapú igényt
Bridge method	Megőrzi a polimorf viselkedést	A bytecode és stack trace néha zavaróbb lehet

6. Gyakori hibák

• ❌ Rossz: new T() vagy T.class használatát várod. ✅ Helyes: Adj át Class<T> paramétert vagy használj factory-t.
• ❌ Rossz: Azt hiszed, runtime-on különbözik List<String> és List<Integer>. ✅ Helyes: Erasure után ugyanahhoz a nyers típushoz jutnak.
• ❌ Rossz: Generikus és array szemantikát összekevered. ✅ Helyes: Az array runtime típust hordoz, a generics jellemzően nem.

7. Senior szintű meglátások

Senior interjún gyakran előkerül, hogy a type erasure miért kompromisszum. A válasz: a Java ökoszisztéma stabilitását védte, de cserébe bizonyos modern típusreprezentációs képességekről lemondott.

Fontos follow-up kérdés: hogyan oldasz meg runtime deszerializációt vagy mappinget generikus típusokra? Erre jellemző válasz a Class<T>, TypeReference vagy hasonló type token minta.

A generics korlátainak megértése segít jobb API-t írni: nem erőltetsz olyasmit a típusrendszerre, amit a JVM nem tud később reprezentálni.

Tipikus follow-up interjúkérdések:

• Hogyan magyaráznád el röviden a(z) Type Erasure témát egy junior fejlesztőnek?
• Milyen trade-offot látsz a(z) Type Erasure kapcsán valós projektben?
• Milyen tipikus production hibát tudsz ehhez a témához kötni?

8. Szószedet

Kifejezés	Jelentés
type erasure	A generikus típusinformáció eltávolítása a fordítás után.
reifiable type	Olyan típus, amely runtime-on teljesen ismert.
unchecked cast	Olyan cast, amit a fordító nem tud teljesen ellenőrizni.
bridge method	Fordító által generált segédmetódus generikus örökléshez.
type token	Explicit runtime típusinformációt hordozó objektum, pl. Class<T>.

9. Gyorsreferencia

• Generics főleg compile-time feature.
• List<String> és List<Integer> runtime-on ugyanaz az osztály.
• Nincs new T() közvetlenül.
• Array reified, generics erase-elt.
• Runtime típushoz gyakran Class<T> kell.

Ha interjún elakadsz, a(z) Type Erasure témánál mindig térj vissza a három alapelvhez: pontos definíció, tipikus use-case, és a legfontosabb trade-off vagy hiba.