Etant donné que je ne suis pas homme à gueuler sans preuve, voici la démonstration de ce que j’avance.

Je vous laisse le temps de lire ce petit bout de code et deviner le résultat logique d’une exécution…
Si vous pensez comme moi, vous vous attendez à ce résultat:

Object: java.lang.String

Integer

Float

Réfléchissons deux minutes.

Nous avons une liste qui contient différents objets, une chaîne de caractère, un entier et un nombre décimal. Notre classe Main présente une méthode polymorphique prenant en paramètre un Object, un Integer ou un Float.
Pour le premier objet la méthode la plus approchante est la méthode avec le paramètre Object.
Pour les deux autres la méthode avec le paramètre de type exact va être appelé du fait que la liaison en java est dynamique et décidée à l’exécution. Le fameux « VIRTUAL » des programmeurs C++.

Voyons le résultat de l’exécution (JVM 1.6 sur MacOS 10.6 dit « Snow Leopard »):

Object: java.lang.String
Object: java.lang.Integer
Object: java.lang.Float

Mais ????!!!! Voilà un résultat qui ferait lacher à nos amis anglo-saxons un virulent « WTF ?! ». Que c’est-il passé ?

Et bien c’est extrêmement facile. Nous nous trouvons devant un manique échec de Java et ses méthodes liées à l’exécution… Le compilateur voit que l’ArrayList contient des instances de Object, il voit une méthode prenant en paramètre un Object, il fait la liaison à la compilation. Dans le langage courant on dirait simplement: JAVA FAIL !

Si vous ne me croyez pas, vous pouvez simplement télécharger le fichier de test ici (en renommant le fichier Main.java évidemment). Pour le principe j’ai changé Object en Number (superclasse de Integer, Float, Double, …) et le résultat est bien sûr le même, comme vous le constaterez là.