Bonjour,

C'est peut être parce que c'est Dimanche, un coup de fatigue ou bien parce que je vieillis, mais je perds mon latin là.

J'ai écrit cette classe:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class StringLocale implements Serializable, Cloneable
{
private Locale m_locale;
private String m_contenu;
 
   @Override public StringLocale clone()
   {
      try
      {
         StringLocale c = (StringLocale)super.clone();
         c.m_locale = (Locale)m_locale.clone();
         return(c);
      }
      catch(CloneNotSupportedException e)
      {
         throw(new DefautLogicielException(e.getMessage(), e));
      }
   }
}
et je m'en accommodais très bien, d'autant qu'elle compilait sans problèmes et montrait sous Eclipse son signe Override...

Jusqu'à ce que je me représente qu'elle n'aurait pas du compiler.
parce que l'interface Cloneable n'est pas générique, et réclame l'implémentation de
Code : Sélectionner tout - Visualiser dans une fenêtre à part
public Object clone();
Un peu ébranlé, je me suis dit: tiens, on peut redéfinir le type de retour en implémentant une interface non générique.
Mon monde vacillait déjà quelque peu...

Mais ceci passe aussi:

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
public class Sujet implements Cloneable 
{
   public Sujet clone()
   {
      return(this.clone());
   }
}

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
public class SujetExamen extends Sujet
{
   public SujetExamen clone()
   {
      return(this.clone());
   }
}
Redéfinir le type de retour d'une méthode dont on hérite... je n'avais jamais vu cela avant. Et pourtant, ça passe.

Pourquoi est-ce accepté?

En vous remerciant,

Grunt.