J'ai utilisé des annotations en Java ou un moment comme utilisateur final, mais j'ai récemment décidé d'examiner mes propres types d'annotation et je trouve la syntaxe pour définir des annotations en Java avec @interface pour être très étrange. Ma question est de savoir pourquoi Java utilise-t-elle @interface pour définir des annotations au lieu d'introduire un nouveau mot clé comme celui-ci pour Enums? Y a-t-il un avantage de la syntaxe @interface que je manque?
Je suis attaché à comprendre les considérations de conception que les concepteurs d'annotations ont traversé, je suis sûr qu'ils devaient avoir joué avec l'idée d'introduire un nouveau mot clé pour définir des annotations.
@interface a trop de restrictions, par exemple, vous ne pouvez pas utiliser étendre, il existe des types spécifiques que vous ne pouvez pas utiliser lors de la définition d'un membre d'annotation telle que la date. Je trouve les restrictions sur ce qui peut aller dans @interface pour ne pas être évidente et cela ressemble à un hack pour moi.
3 Réponses :
Clairement, les concepteurs ne voulaient pas ajouter de mot clé. Pas quelque chose que vous faites à la légère, car il invalide les programmes corrects existants. Le comité COBOL-9X a ajouté des dizaines si non pas des centaines de mots-clés et vous auriez dû entendre les cris. Certaines entreprises parlaient de poursuivre l'organe des normes.
Pouvez-vous s'il vous plaît élaborer sur ce que vous voulez dire @ n'est pas un mot clé Le compilateur le traite de manière particulière pendant que la spécification indique que vous pouvez définir le type d'annotation avec quelque chose comme "@ interface" avec des espaces entre l'interface @ qui me semble que Un mot clé voir ma question mise à jour quant à «pourquoi pas» n'est pas la seule réponse disponible
@ams mes excuses, j'ai vérifié la grammaire Java, c'est vraiment un mot clé, donc j'ai complètement révisé ma réponse.
Je ne connais pas les considérations exactes pour ce cas particulier, mais en général:
Présentation d'un nouveau mot-clé dans une langue rompre la compatibilité de tout code source existant qui utilise ce mot clé particulier comme identifiant.
Le code source existant ne peut pas être compilé avec la nouvelle version du compilateur jusqu'à ce qu'elle ait été modifiée pour éviter le mot-clé. Ceci n'est pas impossible à surmonter (comme le démontrant le document enum ), mais il est gênant et force beaucoup de gens à faire du travail supplémentaire. Les designers de Java ont généralement essayé d'introduire de nouvelles fonctionnalités linguistiques sans casser la compatibilité du code source.
Dans le cas de En tant que de côté, vous êtes peut-être intéressé à regarder Conception de la conception de l'API effective de Josh Bloch qui touche beaucoup de ces considérations. Enum , que vous avez mentionné, je suppose qu'ils ont décidé que c'est (a) un mot clé commun dans d'autres langues de style C, (b) généralement utilisé uniquement comme une portée locale Identifiant dans le code existant et donc facilement refactored et (c) sans aucune alternative saines. Ils ont décidé que les avantages dépassaient les coûts. Pour le cas d'annotation, ils ont apparemment décidé autrement.
Les déclarations d'annotation sont généralement très dégoûtantes à regarder.
Ils pensaient probablement que, seulement quelques (experts) déclareront et traitent des annotations, la plupart des programmeurs utiliseront simplement des annotations conçues par des experts. Par conséquent, ils n'ont pas trop pensé à embellir les déclarations d'annotation. Mais maintenant de plus en plus de cadres tels que Guice / CDI exigent / encourager les programmeurs d'applications à déclarer leurs propres annotations. Et de nombreux programmeurs se sentent assez courageux pour concevoir et traiter leurs propres annotations. Le problème de la syntaxe désordonnée des déclarations d'annotation devient plus important. Enum est censé être utilisé par la plupart des programmeurs dans leur travail quotidien, la syntaxe doit donc être succincte.
Le JSR 303 accepté La validation des haricots nécessite que les développeurs définissent leurs propres annotations si vous souhaitez effectuer des annotations de validateur composites, compte tenu de la centralité de la validation pour créer des applications, je pense que le commentaire que j'ai vu dans les spécifications du soleil que la plupart des développeurs n'auront que besoin d'utiliser mais non Définir les annotations à courte vue.