À propos de la création de tableau générique en Java

Compilation dans Eclipse I Obtenir

Cannot create a generic array of ArrayList<String>

Je pense que le JLS, Â §4.8, "Types bruts" répond à votre question actuelle de pourquoi la mission est valide:

L'utilisation des types bruts n'est autorisée que comme une concession à la compatibilité du code hérité. L'utilisation de types bruts dans le code écrit après l'introduction de génériques dans le langage de programmation Java est fortement découragé. Il est possible que les futures versions du langage de programmation Java rejette l'utilisation de types bruts.

C'est pour la compatibilité avec le code pré-générique. Généralement, si vous allez pour la sécurité de type, vous ne devez pas utiliser des tableaux de types paramétrés du tout, cela aurait été meilleur si l'auteur a écrit: xxx

---

< P> Votre hypothèse sur une règle de type de sécurité étant violée est erronée. Vous dites que list n'est pas un sous-type de list . Toutefois, dans le système de type Java, la réponse à la question: "est Liste un sous-type de la liste ?" n'est ni "oui", ni ce n'est "n °" C'est "cette question ne peut pas être répondue."

_{(Il n'est donc probablement pas correct de confondre "types" et "classes". Il n'y a qu'une seule liste classe, mais list et list sont différents types. Bonus: Liste est pas a Sous-type de Liste .)}

---

Pour ajouter un peu plus de détails sur ce qui se passe, les JLS explique quelles conversions sont autorisées dans une variable Affectation dans §5.2, "contextes d'affectation ". Notamment, la liste se termine par:

Si, après que les conversions énumérées ci-dessus ont été appliquées, le type résultant est un type brut ( §4.8 ), une conversion non cochée ( §5.1.9 ) peut alors être appliqué.

Le dernier lien vers §5.1.9, "Conversions non cochées" , après quelques formalismes expliquant la conversion non cochée, réitère la justification (emphase de la mine):

La conversion non cochée est utilisée pour permettre une interopération en douceur du code hérité , écrit avant l'introduction de types génériques, avec des bibliothèques ayant subi une conversion pour utiliser la généricité (processus que nous appelons la production). Dans de telles circonstances (notamment les clients du cadre de collections dans java.util ), le code hérité utilise des types bruts (par exemple collection au lieu de collection < / code>). Les expressions de types bruts sont transmises comme des arguments sur des méthodes de bibliothèque utilisant des versions paramétrées de ces mêmes types que les types de paramètres formels correspondants.

Ces appels ne peuvent pas être montrés statilement en sécurité sous le système de type à l'aide de génériques. Rejeter de tels appels invaliderait les grands corps de code existant et les empêcher d'utiliser de nouvelles versions des bibliothèques. Cela à son tour, découragerait les vendeurs de la bibliothèque de tirer parti de la généricité. Pour éviter un tel tour d'événements indispensable, un type brut peut être converti en une invocation arbitraire de la déclaration de type générique auquel le type brut fait référence. tandis que la conversion est sans fond, elle est tolérée comme une concession à la pratique. Un avertissement non coché est délivré dans de tels cas.

L'histoire officielle est effectivement que des conversions non cochées de type brut au type paramétré ont été ajoutées délibérément à la langue, malgré leur potentiellement dangereuse et ne sont marquées qu'avec un avertissement de compilation pour des raisons de compatibilité. (Java essaie beaucoup de s'assurer que le code compilé dans la version X ne manque jamais de compiler ou cesse d'être utile dans la version X + 1.)