Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 19 sur 19
  1. #1
    Expert Confirmé
    Avatar de ®om
    Inscrit en
    janvier 2005
    Messages
    2 812
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 2 812
    Points : 2 833
    Points
    2 833

    Par défaut Définition exacte de @Override

    Salut,

    L'annotation @Override doit être utilisée lorsqu'une méthode redéfinit la méthode de la superclasse, par exemple :
    Code :
    @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).

    Citation Envoyé par Javadoc
    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...

  2. #2
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 009
    Points
    7 009

    Par défaut

    Citation Envoyé par Javadoc pour la SE 6.0
    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 !

  3. #3
    Membre éprouvé

    Profil pro Yann Arthur Nicolas
    Inscrit en
    novembre 2005
    Messages
    159
    Détails du profil
    Informations personnelles :
    Nom : Yann Arthur Nicolas
    Âge : 31
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : novembre 2005
    Messages : 159
    Points : 416
    Points
    416

    Par défaut

    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 :
    1
    2
    3
    4
     
    public interface TestInt {
        public void test();
    }
    Code :
    1
    2
    3
    4
    5
    6
    7
     
    public class Test implements TestInt{
        @Override
        public void test(){
             //code...
        }
    }

  4. #4
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 009
    Points
    7 009

    Par défaut

    Citation Envoyé par yannart
    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 )

  5. #5
    Membre éprouvé

    Profil pro Yann Arthur Nicolas
    Inscrit en
    novembre 2005
    Messages
    159
    Détails du profil
    Informations personnelles :
    Nom : Yann Arthur Nicolas
    Âge : 31
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : novembre 2005
    Messages : 159
    Points : 416
    Points
    416

    Par défaut

    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.

  6. #6
    Expert Confirmé
    Avatar de ®om
    Inscrit en
    janvier 2005
    Messages
    2 812
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 2 812
    Points : 2 833
    Points
    2 833

    Par défaut

    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...

  7. #7
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 272
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 272
    Points : 19 344
    Points
    19 344

    Par défaut

    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++

  8. #8
    Expert Confirmé
    Avatar de ®om
    Inscrit en
    janvier 2005
    Messages
    2 812
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 2 812
    Points : 2 833
    Points
    2 833

    Par défaut

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

  9. #9
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 272
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 272
    Points : 19 344
    Points
    19 344

    Par défaut

    Citation Envoyé par ®om
    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++

  10. #10
    Expert Confirmé
    Avatar de ®om
    Inscrit en
    janvier 2005
    Messages
    2 812
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 2 812
    Points : 2 833
    Points
    2 833

    Par défaut

    Citation Envoyé par adiGuba
    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)?

  11. #11
    Modérateur
    Avatar de bouye
    Homme Profil pro Fabrice Bouyé
    Développeur Java
    Inscrit en
    août 2005
    Messages
    4 487
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Bouyé
    Âge : 38
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 4 487
    Points : 9 176
    Points
    9 176

    Par défaut

    Citation Envoyé par adiGuba
    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 :
    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 ?
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  12. #12
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 009
    Points
    7 009

    Par défaut

    Citation Envoyé par bouye
    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 !

  13. #13
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 272
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 272
    Points : 19 344
    Points
    19 344

    Par défaut

    Citation Envoyé par bouye
    *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...


    Citation Envoyé par bouye
    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...

    Citation Envoyé par Modjo
    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++

  14. #14
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 272
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 272
    Points : 19 344
    Points
    19 344

    Par défaut

    Citation Envoyé par 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++

  15. #15
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 009
    Points
    7 009

    Par défaut

    Citation Envoyé par adiGuba
    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 .
    Citation Envoyé par JavaDoc 6.0
    @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).

  16. #16
    Expert Confirmé
    Avatar de ®om
    Inscrit en
    janvier 2005
    Messages
    2 812
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 2 812
    Points : 2 833
    Points
    2 833

    Par défaut

    Citation Envoyé par adiGuba
    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...

  17. #17
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    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

  18. #18
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 272
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 272
    Points : 19 344
    Points
    19 344

    Par défaut

    Citation Envoyé par bobuse
    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++

  19. #19
    Gfx
    Gfx est déconnecté
    Expert Confirmé Sénior
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 32

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 7 310
    Points
    7 310

    Par défaut

    Citation Envoyé par adiGuba
    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.
    Romain Guy
    Android - Mon livre - Mon blog

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •