Recherche:

Oui mais alors là non ! Le but de la proposition est de simplifier le code pour les propriétés. Ce que tu proposes, c'est de garder le codage actuel (i.e. écrire soit même son getter et son setter)...

Moi j'ai voté POUR en gardant à l'esprit que cette proposition a pour but de simplifier le code Java, et donc d'améliorer la lisibilité des classes, et non de proposer une nouvelle fonctionnalité à...

Pas complètement d'accord avec ça...
Prennons un framework comme JSF. Si je fais "monBean.maPropriete" dans une page XHTML (ou JSP), alors JSF va chercher à utiliser getMaPropriete() et...

Oui, ce n'est clairement pas pour gagner quelques secondes à leur génération, mais voir 200 lignes de getters / setters dans un bean, je trouve ça indigeste...

Je n'ai rien contre l'annotation, du moment que je n'ai pas à écrire (ou générer) mes getters et setters.
Mais alors autant la mettre directement dans le langage Java plutôt que d'utiliser des...

Justement, si tu fais une faute de frappe (genre getTurc() pour une propriété truc), comment le compilateur va savoir que tu redéfinis un getter (setter) ? Le coup de l'exception ne servirait à rien...

Je suis tout à fait d'accord, c'est bien plus propre. Maintenant, rien ne t'empêche de définir un setter (ou un getter) sur une property, et dans ce cas, j'estime qu'il est important que le setter...

Je reste pour ;)
La plupart de mes accesseurs sont vraiment basiques, je préférerais placer le mot property devant, et c'est marre !
Vu que c'est un ajout à l'existent, rien ne m'empêche de garder...

Pas vraiment d'accord avec heid, dans la mesure où la proposition du langage permettrait de zapper complètement l'écriture des getters et setters basiques. Là, tu es obligé de tout écrire, même si...

Clairement pour !
C'est franchement lourd, inutile et polluant de mettre 50 getters et setters dans son bean Java.
D'autant que si j'ai vraiment besoin que mon getter (ou setter) fasse quelque...