Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par nicorama

0PARTAGES

0  0 
Alors que le langage Java comporte de base peu d'annotations, des apis peuvent en amener une multitudes comme le montre le récent tutoriel Seam, ou celles proposées par Hibernate.

Je suis assez réticent sur la multiplication des annotations qui pour moi ressemblent à première vue à un nouveau dialecte. Voici mes craintes si j'en crée dans mes packages :

  • Difficultés de refactoring par les ide
  • Difficultés de compréhension par l'équipe par rapport à une api standard
  • Est-ce, comme le fut xml, une mode ?
  • Quel est la réelle plus-value par rapport à une ligne de code ?

J'étais également réticent à Hibernate par rapport à JDBC, et pourtant utilisant JPA, c'est quand même bien mieux (surtout quand Netbeans génère tout ces annotations louches ).

Bref, créez-vous vos propres annotations, et êtes-vous content d'avoir des frameworks pleines d'annotations ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Alain Defrance
Expert confirmé https://www.developpez.com
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 
Avatar de OButterlin
Modérateur https://www.developpez.com
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  0 
Avatar de nicorama
En attente de confirmation mail https://www.developpez.com
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  0 
Avatar de Alain Defrance
Expert confirmé https://www.developpez.com
Le 10/04/2009 à 9:35
Citation Envoyé par nicorama Voir le message

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  0 
Avatar de Baptiste Wicht
Expert éminent sénior https://www.developpez.com
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  0 
Avatar de X-plode
Expert confirmé https://www.developpez.com
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  0 
Avatar de dingoth
Membre expérimenté https://www.developpez.com
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  0 
Avatar de Mikrob
Membre éclairé https://www.developpez.com
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  0 
Avatar de ymajoros
Membre habitué https://www.developpez.com
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  0 
Avatar de Patriarch24
Membre expérimenté https://www.developpez.com
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  0