JavaRush /Blog Java /Random-FR /Annotations. Première partie, un peu ennuyeuse

Annotations. Première partie, un peu ennuyeuse

Publié dans le groupe Random-FR
Première partie. J'ai écrit très brièvement sur les annotations avec les types SOURCE et CLASS. Cela vaut la peine d'être lu pour ne pas se perdre dans la deuxième partie et commencer un peu plus à « mal comprendre » =) Il y aura certainement ici au moins un mot que vous connaissez !
Annotations.  Première partie, un peu ennuyeuse - 1
La première fois que je les ai vus dans des problèmes ici, je ne les ai pas remarqués. Eh bien, Override traîne, il a été écrit par IDEA, donc c'est comme ça que ça devrait être. Au fil du temps, j’ai réalisé que tout est bien plus profond. Pendant que vous étudiez, les annotations semblent inutiles, mais nécessaires. Vous ne savez pas pourquoi ils font cela. Je pense avoir lu quelques articles, ils disaient « comme c'est génial que maintenant nous ayons des annotations, tout est devenu si simple ». Mais je ne savais pas comment c’était avant, et je ne comprenais pas que c’était plus facile maintenant. Maintenant, je sais et je veux vous en dire un peu. Il existe 3 types d'annotations (RetentionPolicy) :
  • SOURCE – annotations du compilateur
  • CLASS – les données de l'annotation seront écrites en bytecode mais ne seront pas disponibles pendant le fonctionnement. Ils écrivent que de nombreuses annotations de la bibliothèque standard utilisent ce type et le conservent désormais en raison de la compatibilité ascendante. Utilisé pour des tâches très spécifiques.
  • Questions et réponses sur StackOverflow
  • RUNTIME – le plus populaire, utilisé pendant l’exécution du code.
Puisqu'une partie de l'article a été reprise par l'introduction, j'écrirai ici sur les annotations SOURCE et CLASS. Voici les résumés que j'ai pu trouver (grâce au problème 3607). Je n'écris pas sur le runtime, il y en a trop et ce n'est pas le sujet de l'article. SOURCE:
  • java/lang/annotation/Native.class;
  • java/lang/SuppressWarnings.class
  • javax/annotation/Generated.class
  • ,java/lang/Override.class
CLASSE: Je ne sais pas pourquoi des annotations de type CLASS sont nécessaires. Je n'ai pas trouvé de documentation pour les annotations existantes, donc je pense que nous pouvons simplement laisser ce bagage derrière nous. Mais si vous le trouvez, partagez-le. Annotations SOURCES :
  1. Natif – une variable sous cette annotation peut faire référence au code natif ;

  2. SuppressWarnings – supprime divers avertissements du compilateur ;

  3. Généré – marque le code source qui a été généré ;

  4. Override – vérifie le remplacement de la méthode.
Plus de détails:
Annotations.  Première partie, un peu ennuyeuse - 2
Natif - jamais vu et jamais utilisé. Je pense que c'est une annotation plutôt rare, car... ils l'utilisent s'ils ont besoin d'exécuter du code dans une autre langue « native ». J'ai essayé de trouver une référence claire à elle, mais je n'y suis pas parvenu.
Annotations.  Première partie, un peu ennuyeuse - 3
SuppressWarnings - souvent utilisé sous la forme @SuppressWarnings("unchecked"). Utilisé pour supprimer les avertissements dont vous avez connaissance. L'exemple ci-dessus supprime les avertissements concernant la conversion de types non cochés. Encore une fois, je ne l'ai rencontré que sous cette forme et dans cette utilisation.
Annotations.  Première partie, un peu ennuyeuse - 4
Généré - Je l'ai rencontré maintenant lorsque la tâche m'oblige à générer des classes à partir de fichiers XSD. Ces 3 annotations sont assez précises et ne vous intéressent probablement pas pour le moment. Je vais décrire le dernier.
Annotations.  Première partie, un peu ennuyeuse - 5
Override - vous l'utilisez tout le temps et cela fait une chose très utile. Il est facile de faire une erreur en remplaçant une méthode, à moins qu'IDEA ne le fasse. Il y a des fautes de frappe ou simplement des erreurs. Cette annotation garantira que la méthode de la classe parent est la même que notre méthode (étiquetée). Cela nous garantit que la méthode sera remplacée et non ajoutée. Lors de la refactorisation du code, la méthode peut être supprimée ou modifiée. Là encore, l'annotation vous indiquera l'erreur. Sans cela, notre méthode serait tout simplement achevée.
Annotations.  Première partie, un peu ennuyeuse - 6
Ennuyeux? Je dirais oui, il n’y a pas grand chose d’utile à retenir de cet article. Presque tout (90 %) est une histoire sur quelque chose que vous n'utiliserez pas, ou vous l'utiliserez, mais très rarement. Les 10 % restants sont un bonjour et une description de l'annotation Override, qui à première vue est inutile. Eh bien, je pense que la deuxième partie de l'article sera plus intéressante. Il y aura des annotations RUNTIME, elles interagiront avec le code en temps réel et créeront de la magie noire. Annotations. Deuxième partie. Lombok.
Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION