J'ai une liste Jusqu'à présent, j'ai ceci, mais il génère un avertissement de compilateur de fonctionnement "non coché" typique: p> p> p> code> qui contient une superclasse (comme véhicule similaire) et je voudrais écrire une méthode qui renvoie les objets de cette liste qui sont des instances d'une certaine sous-classe (comme voiture) . List<Car> cars = getVehiclesOfType(Car.class);
8 Réponses :
Que diriez-vous de cela?
public <T extends Vehicle> List<T> getVehiclesOfType(Class<T> type) {
return Lists.newArrayList(Iterables.filter(getVehicles(), type));
}
Oui, voir les modifications à la question originale. Celui que j'ai publié à l'origine était un avertissement caché de l'IDE, mais les messages du compilateur l'ont montré. (t) fait un avertissement différent et visible.
Vous serez peut-être coincé avec l'ajout @suppresswarning ("non coché") à la méthode
Je suis prêt à accepter cela comme la réponse, si vous pouvez expliquer pourquoi. Nous sommes instructions pour supprimer ou expliquer toute suppression d'avertissement.
Vous obtenez un avertissement car il n'y a aucun moyen pour le compilateur (ou l'IDE) de savoir que la distribution est sûre, sans comprendre la signification de Cependant, vous savez ce que iSAssignAdFrom () . Mais isAssignableFrom () n'est pas une fonctionnalité de langue, c'est juste une méthode de la bibliothèque. En ce qui concerne le compilateur concerné, c'est la même chose que si vous l'avez dit isAssignablefrom () signifie, donc vous savez que c'est sûr que c'est sûr. C'est exactement le type de situation @suppresswarnings est destiné à.
P.s. J'utiliserais Type.Isinstance () moi-même.
Donc, le compilateur donne à cet avertissement n'importe quel classe.cast () est utilisé?
Peut dépendre du compilateur. Avec Idea 9 et JDK 1.6 (expérimenter maintenant), je ne reçois pas un avertissement, même pour une utilisation totalement dangereuse qui conduit à une exception classique. Je suppose que la vérification de l'instance de est-ce que vous pouvez en faire un - pourrait éliminer l'avertissement, car il est alors connu au moment de la compilation pour être en sécurité. Mais je ne sais pas vraiment.
Comme je l'ai dit, l'EDI ne montre pas l'avertissement, mais quand je le compile. N'est pas le vôtre? Vous devriez avoir raison sur l'instance de la vérification mais qui n'est pas possible ici (objet de classe dynamique)
Je ne reçois pas l'avertissement de l'idée ni de Javac - qui dans le cas de Javac au moins est un peu curieux. Pourrait être une question de drapeaux compilateurs / préférences de l'IDE. (Utilisez-vous Eclipse? Il y a beaucoup de différences subtiles entre le compilateur Eclipse et Javac - généralement sans importance, mais vous les courez de temps en temps.) Peu importe, il ne me surprend pas que vous obtenez un AVERTISSEMENT ET SUPPRESSION SIMPLEMENT QUE SIMPLE QUE LA VOYAGE DROITE À FAIRE.
Le problème est que le compilateur n'est pas assez intelligent de savoir que le véhicule est de "type" de classe. Ceci est une vérification d'exécution et le compilateur ne fait pas ce genre d'analyse. Il y a beaucoup de situations comme celle-ci. Par exemple, j'utilise si (vrai) retour; sortir d'une fonction tôt lors du débogage tout le temps. Si j'utilise juste retour, le compilateur se rend compte qu'il existe un code inaccessible, mais avec le conditionnel, le compilateur ne réalise pas qu'il est impossible d'entrer dans cette branche.
Considérez si vous remplacez votre conditionnel avec si (FALSE) {. Le code n'a aucune chance de jeter une exception mais contient toujours un casting dangereux.
Fondamentalement, le compilateur dit: "Je ne peux pas confirmer que c'est sûr, c'est donc à vous de vous assurer de savoir ce que vous faites." Votre code n'est pas cassé, il vous suffit de faire preuve de prudence.
Vous travaillez sur le véhicule, qui est une superclasse et que vous essayez de refuser la sous-classe de véhicule. C'est toujours un casting dangereux et vous rapportera un avertissement de compilateur.
Ainsi, alors que vous pouvez lancer de En utilisant un casting (en utilisant voiture à véhicule sans avertissement (car voiture prolonge le véhicule ), le compilateur n'a aucun moyen de savoir que La variable dactylographiée comme véhicule est en réalité une voiture.
(voiture) ou couler (..) ), vous racontez le compilateur que vous connaissez mieux.
Le compilateur déteste les gens et maintiendra toujours un avertissement à vous :)
Personnellement, je pense que vous prenez la mauvaise approche. Les génériques de Java sont un fonctionnalité de compilation uniquement a >. Vous savoir i> Quel type de liste dont vous avez besoin au moment de la compilation, il suffit de créer une méthode d'assistance qui renvoie le bon type de liste: ajoutez la méthode de l'assistante à la Classe en question et ensuite dans votre code, faites: P> List<Car> cars = Cars.getCars( getVehicles() );
Intéressant. C'est une bonne option à considérer, mais je ne suis pas fou de l'idée d'avoir à écrire la méthode de chaque type que j'ai. C'est pourquoi je voulais avoir une seule méthode. Mais j'apprécie le nouvel angle.
Vous n'avez vraiment que deux options que je le vois. Soit vous créez les méthodes d'assistant individuelles telles que mentionnées ci-dessus ou créez une seule méthode getvehiclesoftype dans votre superclasse de votre véhicule qui renvoie une liste
2 choses:
@Codemwnci, @sblundy, oups, désolé. Avertissement standard "non coché". Question éditée pour ajouter ceci.
Je ne peux pas reproduire cet avertissement. Quel est le type de retour de GetveHicles ()?