Pourquoi la première méthode compile-t-elle et la seconde n'est-elle pas? Les génériques pour J'utilise Javac version 1.7.0_25 à construire. Je reçois l'erreur suivante sur la deuxième méthode, mais pas sur le premier. Je crois que je devrais obtenir l'erreur dans les deux cas, car il n'est pas tape correct pour mettre un numéro définir et immutatables.builder sont identiques et les signatures de type pour leur ajoutent sont également identiques. dans une collection de ? étend le numéro .
4 Réponses :
Je pense que j'ai commencé à comprendre la réponse. le numéro immutatableset.builder Méthode Ajouter est surchargé, il existe une autre signature ajouter (e ... éléments) . J'ai couru javap -v sur le fichier .Class résultant et j'ai vu que cette méthode alternative est celle qui est en fait appelée. Les éléments varargs sont en réalité un tableau Java sous les couvertures et les matrices Java sont Covariant. C'est-à-dire, en ce qui concerne cet exemple spécifique, nous appelons n est converti en une matrice mono-élément de type numéro [] . Mais je ne sais pas comment ce tableau est légalement converti en un tableau de !
Lorsque vous dites définir Constructeur; Cela signifie qu'il pourrait avoir quelque chose que étend numéro , par exemple. entier . Maintenant, vous mettez un numéro dans Builder.add (n); qui n'est pas un integer . Si vous avez besoin d'ajouter quelque chose, vous devriez faire définir Builder; .
La question ne concerne pas comment corriger le code pour compiler. Il s'agit du comportement étrange du compilateur Javac
En effet La spécification du langage Java définit :
La méthode m est un procédé variable arité applicable si et seulement si toutes les conditions suivantes sont satisfaites:
1 ≤ i Si k ≥ n, pour n ≤ i ≤ k, le type de ei, Ai, peut être converti par conversion d'invocation de méthode pour le type de composant Sn.
...
Dans notre cas Sn est Maintenant, juste quel est le type de composant de Sn? Malheureusement, la JLS ne donne pas de définition officielle de ce terme. En particulier, il ne dit pas explicitement si le type de composant est un type de compilation (qui ne doivent pas être réifiable) ou d'un type d'exécution (qui doit être). Dans le cas de l'ancien, le type de composant serait Il semble que les implémenteurs du compilateur Eclipse ont utilisé l'ancienne définition, alors que les implémenteurs de javac ont utilisé ce dernier.
add (E) n'est pas appliccable, mais la question est moins claire pour la méthode add (E ...) :
capture-of? étend Number [] .
capture ou-? étend Nombre , qui ne peut pas accepter un numéro par la conversion d'appel de méthode. Dans le cas de ce dernier, le type de composant serait Nombre , qui peut évidemment.
Il y a quelque chose appelé get & Met Principe. Il est toujours recommandé de le suivre.
"Utilisez une zone générique étend lorsque vous obtenez uniquement des valeurs d'une structure, utilisez une super-carte générique lorsque vous ne mettez que des valeurs dans une structure et n'utilisez pas de caractères génériques lorsque vous obtenez et que vous mettez à la fois"
Les deux méthodes ne parviennent pas à compiler sur mon PC comme prévu.
Jetez un coup d'œil ici, je crois que cela répond à votre question: Stackoverflow.com/Questtions/2776975/...
@Rohit, quelle version de SDK utilisez-vous?
Merci @farlan. J'attends que les deux méthodes ne compilent pas, pour les raisons expliquées dans le lien que vous avez posté. Ce qui me perplexe, c'est pourquoi le premier exemple fait compile, sans avertissement.
La "Cette question peut déjà avoir une réponse ici:" Au sommet de la poste est définitivement faux. Comment puis-je vous en débarrasser ou le voter?
@ Sullivan- Je pense que ce n'est visible que si suffisamment de personnes votent pour fermer la question. Espérons que les gens voient maintenant que ce n'est pas un duplicata (de ce poste au moins).
Malheureusement, Eclipse n'est pas d'accord avec JDK 7 dans ce cas et ne compile pas à compiler ces deux méthodes.
Cela ressemble à un bug Javac