Mit diesen Klassen passiert dasselbe wie mit allen anderen Klassen auch. Bei homogener Übersetzung in Java wird es wahrscheinlich keine Typschranke geben, weil es sonst ja schwer wäre, Integer irgendwie hinein zu bekommen. Daher werden an allen Stellen der Klasse die Typparameter mit object ersetzt, und dort, wo man außerhalb der Klasse einen bestimmten Typparameter erwartet, ein Cast eingefügt. Einfache ints werden automatisch geboxed, d.h. wenn du {List<Integer> mylist=new List<Integer>(); int a=5; mylist.Add(a);} schreibst, wird der int in einen Integer "umgewandelt", und wenn du eine int-Variable hast und dieser einen Wert aus der Liste zuweist, wird der eben wieder unboxed, also vom objekt zurück in den Werttyp umgewandelt. Das ist, wie im Skriptum erwähnt, nicht sonderlich effizient im Vergleich zur heterogenen Übersetzung von int-Listen, bei der diese Umwandlungen nicht stattfinden müssen. Nur: Angenommen es gäbe auch heterogene Übersetzung in Java und der Compiler optimiert dir das nicht weg, dann fallen zwar die casts weg, aber wenn du dort noch immer Integer als generischen Typ angibst, dann muss das boxing und unboxing für die int-Werte noch immer stattfinden. Der Unterschied wäre dann nur, dass mit der homogenen Übersetzung nur eine Klasse gibt, die überall object statt dem Typparameter stehen hat, und dann eben die Casts an den Stellen braucht, wo man einen Wert des Typparameters erwartet, während es bei der heterogenen Übersetzung halt eine eigene Übersetzung für Integer gäbe, wo der Typparameter eben immer mit Integer ersetzt wurde, wodurch die Casts wegfallen. Bei heterogener Übersetzung wäre es halt einfacher, nicht Integer, sondern int zu verwenden und damit das boxing-Zeug einzusparen. In C# wird das dann zum Beispiel so gelöst, dass Generizität mit Werttypen (also int, bool, long, structs etc.) homogen und mit Referenztypen (~ der ganze Rest) heterogen übersetzt wird.
