Discussion :

[smutmutant2003]

Bonjour dans ce morceau de code -question pour une certif scjp -
j'ai ce bout de code dont je n'arrive pas à expliquer la sortie

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
20
21
22
 
public class NombreMachine {
	public static void main(String[] args) {
		Integer wi1 = new Integer("420");
		int i = 101;
		Integer wi2 = i * 420 / 101;
		if (wi1 == wi2)
			System.out.print(" ==");
		if (wi1.equals(wi2))
			System.out.print(" egale");
		float f = 1.23f;
		new NombreMachine().impression(f);
	}
 
	void impression(Float f) {
		System.out.println(" Float");
	}
 
	void impression(double d) {
		System.out.println(" double");
	}
}

Logiquement pour moi la sortie c'est :
egale double
Et bien non, la sortie fait
egale double
Du coup je ne comprends plus, normalement à l'appel de
new NombreMachine().impression(f);
j'appelle Float, pourquoi va-t-elle m'appeller double ?
Franchement je ne vois pas.
Merci pour toute aide, je suis sûr que vos réponses aideront beaucoup de gens comme moi.

Bien à vous.

PS: Soit dit en passant, ne me demandez pas pourquoi le code est ainsi, c'est un examen de certif, c'est clair, je ne me casserai jamais la tête avec ce genre d'idioties, mais que voulez vous, les exams sont ainsi, et on a pas le choix.

[ngpub]

L'autoboxing a des limites et ici le type float est plus proche du type primitif double que du wraper Float.

[smutmutant2003]

Merci pour votre aide.

L'autoboxing a des limites et ici le type float est plus proche du type primitif double que du wraper Float.

Es ce que vous pourriez détailler un peu plus s'il vous plait. J'ai pas compris.

[Rei Ichido]

C'est pas tant une question de limites que de priorité. S'il n'y a pas de correspondance exacte, ça commence par un downcast, puis de l'autoboxing.

EDIT pour détailler :
L'appel à impression(f) se résoud à la compilation.
=> Il n'y a pas de fonction impression(float).
Le compilateur tente les downcast : youpi, on peut dégrader le float en double, donc le compilateur choisit ça.

S'il n'y avait pas eu de correspondance, il aurait ensuite tenté l'autoboxing en cherchant une méthode impression(Float).

[smutmutant2003]

C'est pas tant une question de limites que de priorité. S'il n'y a pas de correspondance exacte, ça commence par un downcast, puis de l'autoboxing.

EDIT pour détailler :
L'appel à impression(f) se résoud à la compilation.
=> Il n'y a pas de fonction impression(float).
Le compilateur tente les downcast : youpi, on peut dégrader le float en double, donc le compilateur choisit ça.

S'il n'y avait pas eu de correspondance, il aurait ensuite tenté l'autoboxing en cherchant une méthode impression(Float).

En gros ce que vous m'expliquez c'est que que pour une variable donnée, le compilateur préferera d'abord le primitif, à l'objet, autrement dit il préferera le double, parce que primitif, au Float.
Si j'ai bien compris la notion de downcast.

[adiGuba]

Salut,


C'est le mécanisme de résolution de méthode effectué à la compilation. Lorsque tu appelles une méthode, le compilateur va rechercher la méthode correspondante.

S'il trouve une méthode strictement identique il n'y a aucun problème et il va utiliser cette dernière. Ce qui n'est pas le cas dans ton exemple puisque la méthode impression(float) n'existe pas.

Dans ce cas le compilateur va rechercher la méthode s'en approchant le plus, avec un fonctionnement un peu différents pour les types primitifs et pour les objets :

• Pour les types primitifs, le compilateur va d'abord tenter de faire une conversion implicite vers un type plus "large".
  Les types primitifs acceptent une plage plus ou moins larges de valeurs, si bien qu'on a l'ordre suivante : byte < short < int < long < float < double.
  En clair : un double peut accueillir toutes les valeurs d'un float, qui lui même peut accueillir toutes les valeurs d'un long, etc.
  Ainsi, le compilateur peut tout à fait effectuer une conversion float -> double car il n'y aura pas de perte de valeur.
  Ainsi, s'il ne trouve pas de méthode correspondante, le compilateur va chercher à effectuer une conversion vers un type primitif plus large pour tenter de trouver une méthode correspondante.
  
  C'est ce qui se passe ici : ton float est implicitement converti en double afin d'appeler la méthode impression(double).
  
  
  L'autoboxing de Java 5 ne rendre en jeu que dans le cas où aucune conversion vers une type primitif plus large n'est possible.
  
  
  
• Pour les objets, lorsque les types ne correspondent pas exactement, le compilateur vérifies la compatibilité avec les types parents et les interfaces implémenté jusqu'à trouver une méthode correspondante.

Enfin, il reste plusieurs cas d'ambiguïté, où le compilateur génèrera une erreur car il n'arrive pas à départager deux méthodes (ou plus). Il faut alors préciser la méthode à utiliser en castant explicitement les paramètres vers le type précis.


a++

[thelvin]

En gros ce que vous m'expliquez c'est que que pour une variable donnée, le compilateur préferera d'abord le primitif, à l'objet, autrement dit il préferera le double, parce que primitif, au Float.

Et je pense qu'il y a une bonne raison à ça.

En effet la conversion implicite de float vers double existe depuis toujours. L'auto-inbox/outbox a été introduit avec Java 1.5. Supposons que nous compilions le même code avec Java 1.4 et avec Java 1.5 : si l'auto-inbox/outbox avait priorité, le même code source générerait des résultats différents, au lieu de faire une erreur de compilation comme on doit normalement le faire en cas d'évolution de langage incompatible. Ce serait un gros problème de compatibilité avec l'existant.

[smutmutant2003]

Merci à tous, je pense avoir compris à présent.
Ce que je vous invite à c'est rajouter ce précieux exemple dans les quizz, où autres tests java, dans une bibliothèque de test-langage objet sur le site developpez.com. C'est un exemple qui n'était pas évident de prime à abord. Je pense que c'est peut être pour ça, qu'il a été posé à un examen scjp.
Ca peut vraiment aider des auditeurs à bien comprendre ce langage.

Bien cordialement.