Comment Java peut-il être amélioré pour qu'il n'ait plus besoin d'effacer le type?


16

Le tutoriel Java officiel sur les génériques explique l'effacement des types et pourquoi il a été ajouté au compilateur:

Lorsqu'un type générique est instancié, le compilateur traduit ces types par une technique appelée effacement de type - un processus où le compilateur supprime toutes les informations liées aux paramètres de type et aux arguments de type dans une classe ou une méthode. L'effacement de type permet aux applications Java qui utilisent des génériques de maintenir la compatibilité binaire avec les bibliothèques Java et les applications créées avant les génériques.

C'était probablement une approche pragmatique, ou peut-être la moins douloureuse. Cependant, maintenant que les génériques sont largement pris en charge dans l'industrie, que pouvons-nous faire pour que nous n'ayons pas besoin d'effacement de type? Est-ce faisable sans avoir besoin de briser la compatibilité descendante, ou si c'est faisable, est-ce pratique?

La dernière déclaration de la citation ci-dessus est-elle devenue auto-référentielle? C'est-à-dire: "l'effacement de type permet aux applications Java qui utilisent des génériques de maintenir la compatibilité binaire avec les bibliothèques Java et les applications qui ont été créées avec des versions Java qui effectuent l'effacement de type."


1
Le Sun 1.4 était EOL'ed. IBM prend toujours en charge 1.4 sur leurs plateformes.

@ ThorbjørnRavnAndersen: Et au moins pour la plate-forme qui se trouve dans le sous-sol de mon père, il n'y en a pas 1,5.
Jörg W Mittag

@ ThorbjørnRavnAndersen Non seulement cela, mais on peut également acheter un support étendu pour des versions beaucoup plus anciennes de la JVM. La dernière fois que j'ai entendu dire que c'était assez cher.
maple_shaft

1
Aucun de nous ici ne possède de boule de cristal, donc elle n'est pas responsable. Il peut peut-être être rouvert si vous reformulez la question d'une question "Y aura-t-il jamais ..." en une question "Que faut-il faire pour que l'effacement de type soit effectué dans une future version de Java"
maple_shaft

@ JörgWMittag serait-ce une plate-forme réellement utilisée pour la production en 2012?

Réponses:


7

La fin de vie s'applique à Java Development Toolkit et à Java Runtime Environment. Et uniquement les versions Oracle (Sun). Mais cela ne s'applique pas aux applications écrites par des tiers. L'intention est de ne jamais casser le code qui a déjà été exécuté sur la JVM, il est donc peu probable que Java cesse de faire l'effacement de type.

Bien sûr, C # a également introduit des génériques dans une version ultérieure de manière rétrocompatible sans faire d'effacement de type, mais cela signifiait essentiellement la duplication de toutes les classes de collection. Ce que je suppose, c'est ce que les concepteurs Java ne veulent pas faire et donc pourquoi ils ont choisi l'effacement de type en premier lieu. Sans types de valeur, l'avantage des génériques non effacés n'est pas si grand.


6
L'équipe OpenJDK a discuté de la possibilité de revoir les génériques réifiés, calendrier? Le plus susceptible d'être examiné sérieusement pendant la période de temps de Java 9 et si c'est techniquement faisable, livré dans la période de temps de Java 10. Mais c'est un sérieux devin de ma part.
Martijn Verburg

L'effacement de type est effectué par le compilateur, pas par la JVM. L'introduction de génériques réifiés nécessiterait un nouveau compilateur et une nouvelle JVM, mais ils fonctionneraient probablement avec l'ancien code.
Gabe

@Gabe: Évidemment, ils seraient introduits dans une nouvelle version, il y aurait donc un nouveau compilateur et une nouvelle JVM. Mais cela nécessite également la duplication d'une partie importante de la bibliothèque standard, car il aurait alors besoin de versions génériques pour le nouveau code et de versions non génériques pour la compatibilité descendante. .NET a fait exactement cela dans la version 2.0, Java l'a évité avec l'effacement. .NET a des types de valeur (struct) et leur prise en charge de première classe empêche l'effacement des types. Java ne le fait pas, donc la pression pour les génériques réifiés est beaucoup plus faible.
Jan Hudec

Jan: Je commentais juste le fait que la réification des génériques ne signifie pas automatiquement que tout l'ancien code est cassé. J'ajouterais également que List<int>cela rendrait certainement les charges de travail beaucoup plus efficaces que le courant List<Integer>.
Gabe

@Gabe: Nous ne sommes pas en désaccord là-dessus. Je voulais juste noter le principal inconvénient.
Jan Hudec
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.