[Language]Probleme de switch case

Salut,

Je souhaite faire un simple switch - case en Java sous JBuilder mais je rencontre un problème :
voila ce que je fais :
Code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

switch(childElement.getNodeName()) { case "factory" : factory = ((Element)childElement).getAttribute("name"); System.out.println("Factory : " +factory); break; case "destination" : destination = ((Element)childElement).getAttribute("name"); System.out.println("Destination : " +factory); break; }

---

Et JBuilder refuse mon Code:
switch(childElement.getNodeName())
ou Code:
childElement.getNodeName())
est un string, en indiquant qu'un int est demandé :
Citation:
"UprJmsXml.java": incompatible types; found : java.lang.String, required: int at line 106, column 50

Pourtant il est bien possible de faire des switch sur des chaines de caracteres...
???

[ Modéré par SEMPERE Benjamin ]
Ajout des balises code
:arrow: Les Règles du Forum

Salut,
le swith ne fonctionne qu'avec desint, short, char ou byte !!

Citation:

---

Envoyé par FreshVic

Salut,
le swith ne fonctionne qu'avec desint, short, char ou byte !!

---

Tout à fait, tu as raison on dit qu'il doivent être "assignment compatible" avec int :wink:

OK donc pas d'autre moyen que de faire des if, else imbriqué dans mon cas?

si vraiment t'as 2 cas , tu le fais simplement avec des if

Ah non non je n'ai pas seulement 2 cas... j'en ai bien plus d'une dizaine environ...

Si tu as vraiment beaucoup de cas et si ton cas e porte sur des String, il existe une astuce (pas très jolie certes, mais elle existe) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

switch (taChaine.hashCode()) { case "CHAINE1".hashCode() : ... break; case "CHAINE2".hashCode() : ... break; ... default : ... break; }

---

Salut,

Citation:

---

Envoyé par NGY

Si tu as vraiment beaucoup de cas et si ton cas e porte sur des String, il existe une astuce (pas très jolie certes, mais elle existe) :

---

Attention car deux String peuvent avoir le même hashCode() même si elles sont différente !!! De plus il me semble que le hashCode() peut varier selon les implémentations de la JVM...




Sinon quel est l'objectif exacte de tout ca ? PArce que le bout de code que tu as montré peut très bien être factoriser :

Code:

---

1 2	factory = ((Element)childElement).getAttribute("name"); System.out.println( childElement.getNodeName()+" : " +factory);

---

a++

Citation:

---

De plus il me semble que le hashCode() peut varier selon les implémentations de la JVM...

---

Je ne pense pas que ce soit le cas pour la classe String, car la méthode n'est pas native (contrairement à celle dans Object). D'ailleurs, la formule de calcul est donnée dans la javadoc du jdk :

Citation:

---

Returns a hash code for this string. The hash code for a String object is computed as

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]


using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)

---

Effectivement deux string différentes peuvent avoir le même hashcode, par exemple "aa" et "bB".

Code:

---

1 2	Salut, le swith ne fonctionne qu'avec des int, short, char ou byte !!

---

Ou des enums :!: :!: :!:

perso je pense que l'utilisation des if est dans ce cas la meilleure solution en rendant le code lisible bien entendu....

Citation:

---

Envoyé par Xavinou

Je ne pense pas que ce soit le cas pour la classe String, car la méthode n'est pas native (contrairement à celle dans Object). D'ailleurs, la formule de calcul est donnée dans la javadoc du jdk

---

Oui en effet cela je n'ai pas regarder la javadoc avant de répondre... shame on me :D
Si c'est indiquer dans la javadoc ce doit être la même chose dans toutes les implémentations de la JVM... mais je pense que le fait que la méthode soit native ou pas ne change rien (même le code des méthodes non-natives peut être différents tant que cela respectent les spécification de java et de la javadoc).

a++

Techniquement, effectivement rien ne t'empeche de faire varier le code source de ton jdk (et de le recompiler bien sûr), mais dans ce cas, on ne peux pas vraiment parler d'implémentation de la JVM à mon avis.

Citation:

---

Envoyé par Xavinou

Techniquement, effectivement rien ne t'empeche de faire varier le code source de ton jdk (et de le recompiler bien sûr), mais dans ce cas, on ne peux pas vraiment parler d'implémentation de la JVM à mon avis.

---

Dans ce cas non puisque l'algorythme est indiqué dans la javadoc, mais ce n'est pas forcément le cas pour toutes les méthodes :

• Elles peuvent varier d'une version à l'autre de la JVM de Sun.
• Elles peuvent être différentes sur d'autres implémentations (je pense à la JVM d'IBM, d'Apple pour MacOS ou au projet GNU-Classpath).

A condition bien sûr qu'elles respectent les spécification et la javadoc officielle...

a++

J'ai l'impression que tu ne fais pas de distinction entre la JVM et le code Java qui est fourni avec. A mon sens c'est deux choses bien distinctes.

Mais bon avec toutes ces étoiles sous ton pseudo je me demande si j'ai vraiment bien compris :oops:

Citation:

---

Envoyé par adiGuba

(...)

Citation:

---

Envoyé par NGY

Si tu as vraiment beaucoup de cas et si ton cas e porte sur des String, il existe une astuce (pas très jolie certes, mais elle existe) :

---

Attention car deux String peuvent avoir le même hashCode() même si elles sont différente !!! (...)

---

Oui, mais dans ce cas, on sera averti dès la compilation : en effet, il ne peut pas y avoir 2 case identiques dans un même switch.

Donc, pour développer ma remarque

Citation:

---

Envoyé par NGY

il existe une astuce (pas très jolie certes, mais elle existe)

---

je dirais que cette astuce fonctionne si elle compile.

Sinon, je ne vois pas pourquoi le fait que l'implémentation de la méthode hashCode() soit différente selon les JVM remet en question la solution.

Citation:

---

Envoyé par Xavinou

J'ai l'impression que tu ne fais pas de distinction entre la JVM et le code Java qui est fourni avec. A mon sens c'est deux choses bien distinctes.

---

Oui mais tu as besoin des 2 pour exécuter un programme Java : la JVM et le code des classes standard. Ce que je veux dire c'est que même le code des classes standard peut aussi être différent d'une JRE à l'autre...

Mais concernant String.hashCode() on est d'accord que c'est le même partout puisque l'algo est spécifié dans la javadoc, et que donc toutes les implémentations doivent le respecter...

Ce que je voulais dire c'est que si ce n'était pas spécifié dans la javadoc ou dans les spécifications de Java, on pourrait avoir des implémentations qui utilisent un algorythme différent pour le calcul du hashCode(), et donc potentiellement un résultat différent...

Citation:

---

Envoyé par Xavinou

Mais bon avec toutes ces étoiles sous ton pseudo je me demande si j'ai vraiment bien compris :oops:

---

Les étoiles ne veulent rien dire il ne faut pas y faire attention ;)

Citation:

---

Envoyé par NGY

Citation:

---

Envoyé par adiGuba

(...)

Citation:

---

Envoyé par NGY

Si tu as vraiment beaucoup de cas et si ton cas e porte sur des String, il existe une astuce (pas très jolie certes, mais elle existe) :

---

Attention car deux String peuvent avoir le même hashCode() même si elles sont différente !!! (...)

---

Oui, mais dans ce cas, on sera averti dès la compilation : en effet, il ne peut pas y avoir 2 case identiques dans un même switch.

Donc, pour développer ma remarque

Citation:

---

Envoyé par NGY

il existe une astuce (pas très jolie certes, mais elle existe)

---

je dirais que cette astuce fonctionne si elle compile.

---

Justement on ne peut pas être avertit à la compilation puisque le hashCode() ne peut être déterminé qu'à l'exécution... D'ailleurs tu viens de me faire remarquer que cela ne peut pas compilé puisque les différents case doivent correspondre à des valeurs constantes...

Citation:

---

Envoyé par NGY

Sinon, je ne vois pas pourquoi le fait que l'implémentation de la méthode hashCode() soit différente selon les JVM remet en question la solution.

---

C'est justement parceque le hashCode() n'est connu qu'a l'exécution et non pas à la compilation... Donc le compilateur ne peut pas vérifier les différentes valeurs...

Si String.hashCode() pouvait avoir plusieurs implémentation (ce qui n'est pas le cas), on ne peut pas être sûr du résultat de la comparaison suivante :

Code:

---

"AA".hashCode() == "BB".hashCode()

---

Parce que les valeurs de hashCode() pourrait varier d'une implémentation à l'autre. Et du coup on peut se retrouver avec des valeurs différentes ou égales selon l'implémentations...

Par exemple dans l'implémentation standard cela doit donner 2080 et 2112 donc cela retourne false.
Maintenant imagine une implémentation simpliste qui retournerai directement la taille de la chaine. On aurait 2 == 2 ce qui retournerai true...

Le hashCode() ne permet pas d'affirmer l'égalité de deux objets. Pour deux objets a et b :

• a.equals(b) implique que a.hashCode() == b.hashCode().
• Mais a.hashCode() == b.hashCode() ne signifie pas forcément que a.equals(b).

Mais il n'y a aucune obligation qu'un objet ai toujours le même hashCode()...
Bien entendu ce n'est pas le cas pour les String (mais je l'ignorais lorsque j'ai écrit le premier message la-dessus).


Je ne sais pas si je suis clair...

a++

Exact, le compilateur ne sait pas calculer les hashCode. Donc la compilation est impossible.

Du coup, il faudrait les calculer à l'avance et les déclarer en constante ce qui retire beaucoup d'intérêt à la solution.

adiGuba: Et donc OK, la solution est effectivement dépendante de l'impémentation de hashCode() => heureusement, elle est standard pour les String.

Sinon avec Java 5.0 la solution a été donné par bouye :

Citation:

---

Envoyé par bouye

Ou des enums :!: :!: :!:

---

Code:

---

public enum TypeEnum { factory, destination }

---

Puisqu'on peut convertir une String en la valeur correspondante de l'enum :

Code:

---

1 2 3 4 5 6 7 8

switch ( TypeEnum.valueOf("factory") ) { case factory: // ... break; case destination: // ... break; }

---

a++

ok merci!!!