Discussion :

[®om]

Salut,

L'annotation @Override doit être utilisée lorsqu'une méthode redéfinit la méthode de la superclasse, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

@Override public boolean equals(Object other) {...}

Par contre, qu'en est-il lorsqu'une classe implémente une interface? Est-ce que la sémantique de @Override indique que la méthode est "overridée" (on peut considérer que oui, car par exemple la javadoc de la méthode dans l'interface est héritée).

Indicates that a method declaration is intended to override a method declaration in a superclass.

Donc a priori ça devrait être utilisé aussi pour l'implémentation...

Pour information, @Override génère une erreur dans ce cas (pour les méthodes implémentées d'une interface) dans Java 5, mais pas dans Java 6...

[djo.mos]

Indicates that a method declaration is intended to override a method declaration in a superclass. If a method is annotated with this annotation type but does not override a superclass method, compilers are required to generate an error message.

Je n'ai pas testé @Override sur une classe qui implémente une interface, mais selon la doc, ça devrait générer une erreur puisque dans un cas pareil la condition énoncée dans la doc (en rouge) est réalisée !

[yannart]

Mais si on peut utiliser @Override.
Faut considérer une interface comme une classe complétement abstraite, c'est à dire que toutes les méthodes sont abstraites.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public interface TestInt {
    public void test();
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public class Test implements TestInt{
    @Override
    public void test(){
         //code...
    }
}

[djo.mos]

Faut considérer une interface comme une classe complétement abstraite

Dans ce cas, @Override n'a aucun sens puisque on ne redéfinit pas la méthode en question, mais on l'implémente ! Donc personellement, et indépendament du fait que le compilateur l'accepte ou pas, je considère qu'utiliser @Override dans une classe qui implémente une interface sémantiquement erroné ! (A moins qu'on ajoute une annotation du genre @Implement )

[yannart]

Dans ce cas, @Override n'a aucun sens puisque on ne redéfinit pas la méthode en question, mais on l'implémente ! Donc personellement, et indépendament du fait que le compilateur l'accepte ou pas, je considère qu'utiliser @Override dans une classe qui implémente une interface sémantiquement erroné ! (A moins qu'on ajoute une annotation du genre @Implement )

Je pense qu'ajouter une annotation comme @Implement n'a pas vraiment d'intérêt vu que quelquefois on se fiche de savoir si on implémente une interface ou une classe. C'est vrai qu'avec les interfaces on implémente une méthode mais l'intérêt d'@Override est le même: ça te permet d'être sur que tu redéfinit ou implémente une méthode du père et que n'en définit pas une nouvelle.

[®om]

Moi je trouverais ça bien pratique car je fais la javadoc sur toutes les méthodes, sauf bien sûr si elle est déjà documentée dans l'interface... Ça permet de voir rapidement si une méthode n'a pas de javadoc parce qu'elle est implémentée, ou parce que c'est un oubli...

[adiGuba]

Salut,


Le sens d'Override a bien changé entre Java 5.0 et 6...
J'avais trouvé une discussion intéressante sur le sujet mais je ne la retrouve plus...

Je vais essayer de vous résumer ca de mémoire : On y parlais également d'une annotation @Implement, mais au final ils en étaient arrivé à la conclusion que cela apporterait plus de problème, et qu'il était préférable d'utiliser @Override dans tous les cas dans le sens "j'implémente ou je redéfini une méthode".

Le principal problème concernait les méthodes abstraites des classes abstraites : doit-on utiliser @Implement ou @Override dans ce cas ?

Si on utilise @Implement, on limite les évolutions de la méthode.
Si une future version de la classe propose une implémentation pour cette méthode, il faudra alors remplacer les @Implement par des @Override, ce qui provoquera une incompatibilité des sources...

Si on utilise @Override, on fait la distinction dans l'implémentation d'une méthode abstraite selon qu'elle soit défini dans une classe ou une interface.

De même on peut se retrouver avec le même problème si une classe abstraite déclare implémenter une interface mais ne propose pas d'implémentation pour ses méthodes...


Bref lorsqu'on y regarde bien l'utilisation d'@Implement en plus d'@Override pose un grand nombre de cas particulier qui complexifieraient l'utilisation de ces deux annotations...

En adoptant une annotation commune au notion d'implémentation et de redéfinition on se simplifie grandement la vie...

De plus, il n'y a pas vraiment d'intérêt à différencier ces deux cas...

a++

[®om]

Donc même quand on implémente une méthode, il est préférable d'utiliser @Override (plutôt que rien)...?

[adiGuba]

Donc même quand on implémente une méthode, il est préférable d'utiliser @Override (plutôt que rien)...?

A partir de Java 6 oui

a++

[®om]

A partir de Java 6 oui

a++

OK, ça me paraît plus logique comme ça.
Cependant, ce qui est dommage, c'est que sans ça, un programme java 6 compile en java 5 pour peu qu'on n'utilise pas une nouvelle classe (et là ça casse ceci).
Autre chose, peut-on configurer eclipse pr qu'il fasse un warning si on ne met pas le @Override lorsqu'une méthode est implémentée (il le fait que pr les méthodes redéfinies)?

[bouye]

Le sens d'Override a bien changé entre Java 5.0 et 6...
[...]

Ce qui expliquerai pourquoi JBuilder 2006/Java 5 fait une erreur "method does not override a method from its superclass at line xx" quand on met @Override devant une methode qui implemente une signature provenant d'une interface.

Dans JBuilder 2007*/Java 6 ca ne passe pas non plus cependant avec un "method xxx of type yyy must override a superclass method."

*JBuilder 2007 est base sur Eclipse.

Tests realises avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
    JButton button = new JButton();
    button.addActionListener(new ActionListener() {
      @Override public void actionPerformed(ActionEvent event) {
 
      }
    });
 
[...]
 
private class Test implements ActionListener {
  @Override public void actionPerformed(ActionEvent event) {
  }
}

Si jamais ca marche dans Eclipse normal (plutot que dans JBuilder 2007) cela ne devrait cependant pas empecher la production de binaires 1.5 a partir de sources 1.6 puisque c'est juste de la syntaxe pre-compilation. Non ?

[djo.mos]

c'est juste de la syntaxe pre-compilation

Je ne suis pas d'accord ! les annotations ne sont pas juste pour la pré-compilation, elles sont inscrites aussi dans le .class. La preuve ? On peut les récuperer avec l'API de reflection et d'instrospection !

[adiGuba]

*JBuilder 2007 est base sur Eclipse.

Et eclipse possède son propre compilateur, qui peut avoir un comportement différent du javac standard...

Cela peut donc varier d'une version d'eclipse à l'autre...

Si jamais ca marche dans Eclipse normal (plutot que dans JBuilder 2007) cela ne devrait cependant pas empecher la production de binaires 1.5 a partir de sources 1.6 puisque c'est juste de la syntaxe pre-compilation. Non ?

Non cela ne devrait pas poser de problème...

Je ne suis pas d'accord ! les annotations ne sont pas juste pour la pré-compilation, elles sont inscrites aussi dans le .class. La preuve ? On peut les récuperer avec l'API de reflection et d'instrospection !

Cela dépend, les annotations ne sont pas forcément enregistré dans le fichier *.class ni disponible via réflection, cela dépend de leurs Retention

a++

[adiGuba]

J'avais trouvé une discussion intéressante sur le sujet mais je ne la retrouve plus...

J'ai retrouvé la discussion en question (qui date d'un an) : http://blogs.sun.com/ahe/entry/override

D'ailleurs sur ce blog on retrouve un autre message qui indique le comportement de @Override : http://blogs.sun.com/ahe/entry/override_snafu

• La méthode redéfini ou implémente une méthode déclaré dans un type parent.
• La méthode a une signature équivalente à une des méthodes publiques déclaré dans Object.

a++

[djo.mos]

cela dépend, les annotations ne sont pas forcément enregistré dans le fichier *.class ni disponible via réflection ...

T'as tout à fait raison ...
En effet, Override n'est retenue que dans le source, pas le .class .

@Target(value=METHOD)
@Retention(value=SOURCE)
public @interface Override

Mais tout de même, il n'ont pas mis à jour la JavaDoc pour la version 6.0 (cf : mon premier post).

[®om]

J'ai retrouvé la discussion en question (qui date d'un an) : http://blogs.sun.com/ahe/entry/override

D'ailleurs sur ce blog on retrouve un autre message qui indique le comportement de @Override : http://blogs.sun.com/ahe/entry/override_snafu

• La méthode redéfini ou implémente une méthode déclaré dans un type parent.
• La méthode a une signature équivalente à une des méthodes publiques déclaré dans Object.

a++

OK merci beaucoup pour les liens... Donc la spécification a changé (tant mieux, je trouvais ça pas très logique dans Java 5).
Maintenant il faudrait que eclipse mette les warnings qu'il faut quand on n'a pas mis @Override sur une méthode implémentée...

[bobuse]

Merci pour cette discussion. Ça m'a permis de découvrir qu'on pouvait utiliser @Override pour les implémentations d'interface. Ça me manquait cruellement !!
Pour le warning d'eclipse, il faudrait voir si il y a déjà un bugreport et sinon le créer

[adiGuba]

Pour le warning d'eclipse, il faudrait voir si il y a déjà un bugreport et sinon le créer

Le bugreport existe déjà : [1.6] compiler should warn about missing @Override annotation for interface method

a++

[Gfx]

Et eclipse possède son propre compilateur, qui peut avoir un comportement différent du javac standard...

Cela peut donc varier d'une version d'eclipse à l'autre...

Compilateur qui d'après mon expérience contenait énormément de bugs importants pour le support de J2SE 5.0 il y a encore un an.