Discussion :

[Oprichnik]

Bonjour, je suis pour le moment entrain de débuter la programmation en Java à l'aide d'un livre comme il se doit et malgré mes relectures, je pense que ces commentaires (qui viennent du livre) sont incorrects :

Code :

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

1
2
3
4
5
6
7
8
9
 
Object o1, o2;
String ch1 = "...", ch2 = "...";
o1 = ch1; o2 = ch2;
...........
o1.equals(o2) // utilise equals de object
o1.equals(ch2) // utilise equals de object
ch1.equals(o2) // utilise equals de string
ch1.equals(ch2) // utilise equals de string

Pour la première instruction par exemple, je déduis :
- On regarde le type de o1 (Object) et on cherche la signature de la meilleure méthode (boolean equals(Object))
- A l'exécution o1 référence un String et comme la classe String redéfinit la méthode equals identiquement (même signature), on utilise equals de String et non de Object.

Impossible de trouver mon erreur en cherchant, j'ai même refais le test avec des classes que j'ai créer et j'arrive à ma conclusion...

[eric39]

Bonjour,

Avec le code que tu décris, effectivement les 4 appels à equals() seront fait sur la classe String.

Il n'y avait pas de code important au niveau des '...........'?

[adiGuba]

Salut,

Pour la première instruction par exemple, je déduis :
Pour la première instruction par exemple, je déduis :
- On regarde le type de o1 (Object) et on cherche la signature de la meilleure méthode (boolean equals(Object))
- A l'exécution o1 référence un String et comme la classe String redéfinit la méthode equals identiquement (même signature), on utilise equals de String et non de Object.

Ton analyse est tout à fait correct !


En fait il faudrait savoir de quel coté on se place exactement, mais au final c'est toujours la méthode equals() de String qui sera exécutée...


Je suppose que ton bouquin se place du point de vue du compilateur, car là on a bien des différences.

Par exemple si on reste sur cette première instruction :

• Le compilateur se base sur le code source et le type déclaré des variables. Ainsi comme o1 est de type Object, le compilateur génère un appel de méthode virtuelle (invokevirtual) vers Object.equals() de l'instance o1.
• A l'exécution, la JVM va interpréter cet appel en vérifiant le type réel de o1. Puisqu'il s'agit du type String qui redéfini la méthode equals(), c'est cette dernière qui sera exécutée.

a++

[Oprichnik]

Pour les ".....", c'est tel quel dans le livre.

Je vais vous écrire exactement le paragraphe qui s'intitule /!\ Précautions du livre :

Code :

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

1
2
3
4
5
6
7
8
Object o1, o2;
String ch1 = "...", ch2 = "...";
o1 = ch1; o2 = ch2;
.....
o1.equals(o2) // utilise equals de Object --> comparaison de références
o1.equals(ch2) // utilise equals de Object --> comparaison de références
ch1.equals(o2) // utilise equals de String --> comparaison de valeurs
ch1.equals(ch2) // utilise equals de String --> comparaison de valeurs

J'ai fait une photo pour vous montrer dans la globalité :
http://www.casimages.com/img.php?i=0...2345922761.jpg

Le livre ne précise pas que c'est juste à la compilation :s

PS : Livre : Programmer en Java de Claude Delannoy

[adiGuba]

Dans ce cas c'est clairement une erreur ! Quoi qu'il arrive dans tous les cas le commentaire des deux première ligne est incorrect !!!

Code :

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

1
2
3
4
o1.equals(o2) // utilise equals de Object --> comparaison de références
o1.equals(ch2) // utilise equals de Object --> comparaison de références
ch1.equals(o2) // utilise equals de String --> comparaison de valeurs
ch1.equals(ch2) // utilise equals de String --> comparaison de valeurs

Au final dans les 4 cas c'est la même méthode qui est exécutée : celle de la classe String (on a donc bien des comparaison de valeurs).

Le code de la méthode equals() de Object n'est jamais exécuté !

a++

[Oprichnik]

ok, merci, j'ai envoyé un e-mail à l'auteur pour voir ce qu'il en dit...

C'est quand même pas super d'avoir une erreur dans un livre :s

[eric39]

OK,

Si tu pouvais nous dire si l'auteur dit qu'il y a une erreur, et sinon, comment il justifie son exemple de code. Histoire de comprendre ce qu'il avait derrière la tête au moment de la rédaction du bouquin.

[adiGuba]

C'est quand même pas super d'avoir une erreur dans un livre :s

Une erreur est si vite arrivée... et pas forcément facile à détecter même après plusieurs relectures !

a++

[Oprichnik]

Voici la réponse :

Bonjour,

Je vous remercie de l'intérêt que vous portez à mes ouvrages.

Effectivement, vos remarques sont justifiées. La signature de la méthode equals de la classe String est bien :
boolean equals (Object)

Dans ces conditions, le polymorphisme fonctionne normalement, ce qui, sommes toutes, est plutôt satisfaisant.
A force de chercher des contre exemples, on finit par dire des bêtises....

Merci de votre aide !

[adiGuba]

Ok je comprend : il voulais surement parler de surcharge !

Par exemple ici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MaClasse {
 
	private final int value;
 
	public MaClasse(int value) {
		this.value = value;
	}
 
	public boolean equals(MaClasse o) {
		return this.value==o.value;
	}
 
}

Malgré le fait qu'on utilise le même nom, on ne redéfinie pas equals() car la signature de la méthode est différente ! Ce n'est pas une redéfinition (override en anglais), mais une surcharge (overload en anglais) : c'est à dire une méthode avec le même nom mais une signature différente (type et/ou nombre de paramètres différents).
Du coup le compilateur génèrera des appels de méthodes "différentes", et la JVM ne modifie pas l'appel de méthode car elle ne trouve pas de redéfinition :

Code :

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

1
2
3
4
5
6
7
MaClasse c1 = new MaClasse(1);
MaClasse c2 = new MaClasse(1);
Object o1 = c1;
 
c1.equals(c2); // => MaClasse.equals()
c1.equals(o1); // => Object.equals()
o1.equals(c2); // => Object.equals()

Mais ce serait une erreur d'utiliser une méthode equals() de la sorte.

Astuce : lorsqu'on redéfinit une méthode, on peut utiliser l'annotation @Override qui force le compilateur à vérifier qu'on respecte bien la signature parente

Plus d'info : Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?

a++

[Oprichnik]

J'y avais penser mais si tu regarde la 3ème instruction :

Code :

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

1
2
 
ch1.equals(o2) // utilise equals de String --> comparaison de valeurs

ça me semble faux même si la classe String surchargeait la méthode equals.

Car ch1 est de type String => on prend la méthode equals de String mais o2 étant de type Object (peut împorte sa référence à l'exécution) on ne saurait utiliser la méthode equals de String qui prend un String en argument et non un Object (un objet n'est pas un String).

On reviendrait à la méthode de la classe ascendante à String Object.equals qui prend elle comme argument un objet (o2).

[adiGuba]

Code :

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

1
2
 
ch1.equals(o2) // utilise equals de String --> comparaison de valeurs

ça me semble faux même si la classe String surchargeait la méthode equals.

Non car s'il y aurait eu surcharge on aurait deux méthode equals : equals(Object) hérité de Object et la surcharge equals(String).

Cette dernière ne peut pas être choisi par le compilateur, car le type de o2 est Object. Par contre la méthode equals(Object) est alors acceptable

a++

[Oprichnik]

Oui c'est ce que j'ai écrit mais le commentaire est quand même incorrect vu qu'on utilise equals de Object et non de String (comparaison de références et pas de valeurs).

[adiGuba]

arf oui en effet

Bien vu

a++