Débat Java : Que pensez-vous de la multiplication des annotations ?

Expert confirmé

Le 09/04/2009 à 15:47

Pour ma part je trouve que les annotations sont un des points fort du langage.
Hibernate qui est un outil très puissant n'était pas aussi efficace lorsque les annotations n'éxistaient pas encore. Quelle perte de temps que de taper de longs fichier de mapping en xml ...
L'ORM avec JPA est devenu très facile à mettre en place et n'a que peu de rivaux (si ce n'est aucuns), et ceci grâce aux annotations.

Les annotations sont maintenant omniprésentes dans nos codes sources, et je pense que c'est une manière efficace de "marquer" une classe.

0

0

OButterlin

Modérateur

Le 09/04/2009 à 16:26

Le problème à mon sens n'est pas dans les annotations mais plutôt dans le fait qu'elles n'ont pas de référence (nominative) sur l'outil cible.
Dans le cas que tu cites (Seam), c'est assez flagrant.
On mélange des annotations JPA avec des annotations SEAM, on ne sait plus trop à quoi elles se rapportent.
Bon, on peut toujours regarder l'import pour s'en sortir...

Ceci dit, je ne remets pas en cause les annotations, la proximité avec la propriété ou la méthode cible est un plus par rapport aux fichiers externes.

Un autre avantage, le serveur cible va les interpréter idéalement... on pourrait imaginer la "traduction" d'une annotation différemment d'un serveur à l'autre...

Quelle perte de temps que de taper de longs fichier de mapping en xml

Pour Hibernate, l'argument de kazou sur les fichiers hbm ne tient pas, l'outil les générant également

0

nicorama

En attente de confirmation mail

Le 09/04/2009 à 23:15

OK pour le marquage quand il y a une annotation, par exemple @Stateless ou @Id : on comprend vite que c'est spécial.

Mais quand il y a 3 annotations dont certaines "tordues" sur une fonction, en quoi cela remplace t-il une ligne de code dans le constructeur ou la fonction ?

Exemple :
@Logger
private Log logger;

On ne peut pas faire par exemple Log4j.setLogger(this.logger) dans le constructeur ? (oui, je ne connais pas bien log4j

).
Si un framework bien particulier propose 3-4 annotations typiques de sa spécifité, ok. Mais je trouve que l'écriture fait un peu blackbox : on sait pas trop ce qu'il y a derrière.

0

Alain Defrance

Expert confirmé

Le 10/04/2009 à 9:35

Envoyé par nicorama

Mais quand il y a 3 annotations dont certaines "tordues" sur une fonction, en quoi cela remplace t-il une ligne de code dans le constructeur ou la fonction ?

Autant je suis de l'avis de dire que les annotation sont un réel plus à Java, autant je suis de ton avis sur le point où trop d'annotation nuit à la documentation naturelle du code source. On peut un perdre en visibilité et cela peut compliquer la compréhension du code.

0

Baptiste Wicht

Expert éminent sénior

Le 12/04/2009 à 22:21

Pour ce qui me concerne, je suis un grand fan des annotations.

J'utilise régulièrement JPA, Hibernate et Spring et je trouve beaucoup plus agréable et fin une configuration par annotation. Par exemple pour une entité JPA, on voit tout de suite dans la classe les propriétés JPA/Hibernate, on a pas besoin d'aller lire un fichier XML imbitable pour comprendre comment est mappé cette classe.

Il m'arrive également de créer mes propres annotations, mais c'est vrai que je n'en utilise pas beaucoup.

Pour ce qui est de la clarté, toutes les annotations que j'utilise (jpa, hibernate, spring, junit et annotations standards) m'ont toujours semblé suffisamment claires. Il est sûr qu'il faut être conscient de ce qui se passe derrière, mais une fois qu'on sait qu'est-ce qui est fait avec une annotation, on ne se pose pas la question.

0

X-plode

Expert confirmé

Le 12/04/2009 à 23:12

De même que Baptiste, depuis les annotations, le developpement n'a cesse de simplifier le code et la rapidité de ce dernier.

0

dingoth

Membre expérimenté

Le 16/04/2009 à 1:03

Le principe d'une annotation, c'est justement de ne pas savoir ce qu'il y a derrière, juste de ce qu'elle peut faire.

Personnellement les annotations, je ne pourrais plus m'en passer. Et n'en utiliser que 3 ou 4 du langage alors qu'il peut y en avoir des milliers, ce serait comme n'utiliser que java.lang alors qu'il existe tous les packages à côté.

Pour ajouter un comportement spécifique via AOP, y'a rien de tel.

Code :

Sélectionner tout

1
2
3
4
5
6
@Inject // Guice... Ah que c'est bon.
@Log({ENTRY,EXIT,THROWING}) //Log de l'entrée, de la sortie de la méthode et d'une éventuelle exception
@Property // Et hop un firePropertyChange.
public synchronized void setStatus (@NonNull Status status) { // et pour finir, un peu de validation
  this.status = status;
}

Ce genre de code (tiré d'une de mes applications) ne me dérange pas et augmente clairement ma productivité... une fois la fonctionnalité écrite.

0

Mikrob

Membre éclairé

Le 16/04/2009 à 7:12

Pour moi les annotations apportent d'une part une simplicité de développement, et donc un gain de productivité.
Mais en plus de ça elles facilitent la relecture du code, on voit tout au niveau de l'objet au lieu de devoir aller regarder dans plusieurs fichiers xml à quoi correspond tel attribut de tel objet.

C'est beaucoup plus clair, après c'est comme tout il ne faut pas en abuser.

0

ymajoros

Membre habitué

Le 16/04/2009 à 8:04

Difficulté de refactoring ? Les annotations font partie du langage et sont très bien comprises par les grands ide. Je ne vois pas en quoi renommer une méthode diffère de renommer une annotation, par exemple. En comparaison, cela peut être un véritable problème en xml, où on ne peut pas garantir le refactoring dans tous les cas.

Je ne comprends pas trop bien ton argument, "Difficultés de compréhension par l'équipe par rapport à une api standard". Les annotations introduites par une api font partie de l'api, où est le problème ?

0

Patriarch24

Membre expérimenté

Le 16/04/2009 à 8:20

Pour ma part, j'utilise les annotations assez fréquemment (JPA, Spring, TestNG/JUnit, ...). Je trouve l'outil fort intéressant et puissant. Comme cela est dit plus haut, les IDEs s'en accommodent très bien (refactoring, etc).

Cependant, je mettrais quand même des bémols : trop d'annotations tuent les annotations. Un fichier source truffé d'annotations (5, 6 voire plus sur un seul élément !) devient assez vite difficilement lisible (avis personnel cependant).

Par ailleurs, contrairement aux fichiers xml, les annotations sont des éléments de code, donc intrusifs par rapport au sens. Il est plus compliqué de modifier un configuration via les annotations que via un fichier xml (et éventuellement de l'aop). Dans le cas par exemple de JPA, cela ne pose pas réellement de problèmes, on ne modifie pas le modèle sans modifier les classes sous-jacentes. Mais dans le cas d'un logger, dont on donne par annotation le niveau (info, debug, etc.), alors le modifier signifie recompiler... Ce qui est fort dommage.

Enfin, en utilisant des annotations, on utilise certes des POJOS mais on devient de fait liés à une API particulière (pour JPA, c'est standard donc par de pb, par contre pour Spring par exemple...).

Pour conclure, je dirais : utilisez les annotations, en prenant en compte les avantages et inconvénients que leur utilisation implique. Si les inconvénients ne vous gênent pas, alors foncez. N'hésitez pas, vous gagnerez du temps, à coup sûr.

0

Identifiez-vous

Créer un compte

Débat Java : Que pensez-vous de la multiplication des annotations ?

Identifiant
Mot de passe

Mot de passe oublié ?