La syntaxe n'est pas définitive...
Après bien sûr ce sera plus propre avec des APis conçus pour cela !
a++
Pour moi, la réponse "pourquoi pas de string dans un switch" tient en un raisonnement très simple.
Fondamentalement, le switch sert à énumérer tous les cas possibles. Et pour pouvoir énumérer tous les cas possibles, il faut qu'il y en est un ensemble fini. Les entiers (en informatique), les enums (qui ne sont rien de plus qu'un sous ensemble d'entier), sont des ensembles finis. Il existe une infinité de string, on ne peut donc pas les énumérer, elles n'ont donc pas leur place dans un switch.
Bien sûr, c'est là un raisonnement très conceptuel. On me répondra que c'est pour cela qu'il existe le mot clé default. Et puis, que la meilleure conception est rarement la solution la plus simple à mettre en place. Ou encore que, de toute manière, si quelqu'un code en concevant mal, ne pas accepter de mettre de string dans les switch lui fera faire une grosse succession de if else if qui reviendra considérablement au même.
Il n'empêche, conceptuellement, le switch n'a pas été créé pour ça. Ce n'est pas une syntaxe amélioré du if mais bien un concept différent.
Autant je crois que les références de méthodes vont clairement apporter un vrai plus à ce niveau, autant je suis moyennement convaincu par l'utilisation des expressions lambda pour cela.
Ton exemple reste bizarre et pas intuitif si on ne connait pas bien le mécanisme qui se cache derrière. Je préfère encore voir l'intégralité du mécanisme que le cacher partiellement
Pour bien faire il faudrait un vrai système de structures de contrôle qui fait disparaitre toute la plomberie:
Malheureusement, ce n'est plus au programme et j'ai peur que les choix fait actuellement pour les lambda, compliquent leur possible arrivée dans les prochaines versions.
Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 meteo.onTemperatureChange(double oldTemperature, double newTemperature) { SwingUtilities.invokeLater{ textField.setText(""+newTemperature); } }
Conceptuellement le switch sert bien a énumérer, mais "les résultats attendus", certainement pas "tous les cas possibles".
Comme tu le dis, le "default" en est bien la preuve. Je rajouterais également que l'énumération avec les entiers n'est jamais sur un ensemble fini, car même si le nombre d'entiers possible est fini, il ne viendrait jamais à l'idée de qui que ce soit de gérer l'intégralité des valeurs possibles pour un entier.
Et même sur une énumération, rien n'oblige de traiter tous les résultats possibles.
hum... Pour moi, ca n'énumère rien du tout. Ce n'est pas un itérateur.
Le switch est un sélecteur qui permet de choisir un bloc de code à exécuter suivant la valeur d'une variable. Que cette variable soit de type entier, booléen, décimal ou chaine, ca ne change pas le principe du switch.
@Uther : C'est quand même un exemple particulier au départ du fait qu'il incorpore 2 classes anonymes imbriqués. Et la syntaxe n'est pas définitive. Il sera préférable de juger sur le résultat final avec des APIs conçus pour cela
Dans ce cas précis les Method references seront surement plus pratique en effet. Mais ces dernières reposent sur les expressions lambdas
Donc lorsque tu fais un switch sur un int, tu énumères les 4 milliards de valeurs possibles ??? Impressionnant !
Sans rire, un switch permet de faire un traitement spécifique selon la valeur d'un variable par rapport à des constantes. Je ne vois pas en quoi ce ne serait pas correct de faire cela avec des String, alors que cela le serait avec des int...
a++
linux, solaris, windows .... whaouuuuu !
mac ??
deploy everywhere .... but on apple
Bah le problème du Mac c'est que ca va prendre un certain temps de réintégrer dans OpenJDK les travaux d'Apple. Ca viendra a coup sur, mais il faudra être patient.
Le planning prévoyait depuis longtemps que la version Mac sorte plus tard que les autres (en même temps ça ne change pas grand chose par rapport a quand Apple s'en occupait).
Un bogue sur Java 7 paralyse Apache Lucene et Solr
Une optimisation défectueuse du compilateur Hotspot incriminée
Mise à jour du 1 août 2011 par Idelways
Un sérieux bogue vient d'être dévoilé suite au lancement final de Java 7. Il entrave le fonctionnement de deux projets de la fondation Apache, notamment Lucene, le célèbre moteur de recherche en full-text.
Le problème se situe plus précisément au niveau du compilateur Hotspot qui intègre un optimisateur défectueux, capable de créer des boucles potentiellement erronées.
Par conséquent, la machine virtuelle Java peut planter à l'exécution, ou produire des résultats de calculs incorrects.
Pour Lucene, ce bogue risque de corrompre l'index, plus particulièrement sur la version qui embarque le PulsingCodec.
L'autre projet phare de la fondation Apache affecté par ce bogue est Solr, le moteur de recherche issue de la bibliothèque Lucene sus-citée.
Oracle aurait découvert ce bogue 5 jours avant la sortie de Java 7 en version définitive, mais aurait préféré reporter sa correction au deuxième « service release » de Java 7. Le premier étant réservé à la correction des bogues de sécurité, sauf changement de planning.
En attendant, les utilisateurs des deux projets doivent temporiser avant de passer à Java 7 en production ou l'utiliser avec l'option -XX:-UseLoopPredicate qui désactive l'optimisation et met ainsi l'index Lucene à l'abri.
Un bogue similaire peut surgir sur Java 6 avec les flags -XX:+OptimizeStringConcat et -XX:+AggressiveOpts qui activent des optimisations Hotspot par défaut désactivées.
Trois rapports de bogues ont été admis par Oracle, l'un de faible priorité et les deux autres de priorité modérée.
De pareils dysfonctionnements n'ont pas encore été signalés sur des produits autres que ceux de la fondation Apache.
Pour plus d'informations sur les nouveautés de Java 7, lire ci-devant.
Source : avertissement de la fondation Apache
Et vous ?
Qu'en pensez-vous de ce bogue ? L'avez-vous rencontré ?
A propos des optimisations, est-ce qu'on sait quels types d'algorithmes seront optimisés par les améliorations intégrées à Java 7 ?
Je viens de me balader sur la nouvelle JavaDoc (que je trouve bien moche) et je constate que sur le package java.awt, la couleur des lignes n'est pas alternée ?!
Un petit bug ?
Pour revenir sur les énumérations, je rajouterai que les références static c'est le mal
j'ai toujours dit qu'il faut éviter de passer en prod avec une version non encore éprouvé pour moi la migration vers java 7 c'est pas pour tout de suite
Comparez :
http://download.oracle.com/javase/7/...ql/RowSet.html
http://download.oracle.com/javase/6/...ql/RowSet.html
J'ai surtout l'impression que l'ancienne version est infiniment plus lisible... Je trouve le contraste de la nouvelle version trop faible (peine à repérer les liens), la première colonne du tableau infiniment trop large sur mon écran (25% de la largeur) et j'ai l'impression que les commentaires apparaissent plus que les signatures des méthodes.
Je plussoie !
Je trouve ça moins lisible et j'ai l'impression que ca prends plus de place en hauteur ... Pas génial pour les portables à la résolution limité en hauteur.
Ca ne vaut pas celle d'Android dans laquelle tu gardes toujours les frames ...
Java 7 Update 1 corrige l'incompatibilité avec Apache Lucene et Solr
Due à une optimisation défectueuse du compilateur JIT
Mise à jour du 27 octobre 2011 par Idelways
Une anomalie découverte quelques jours avant la sortie de Java 7, et laissée pour compte par manque de temps, vient d'être écartée.
Oracle sort l'Update 1 de Java 7 qui corrige l'optimisation défectueuse du compilateur Hotspot, responsable de boucles potentiellement erronées, pouvant produire des résultats de calculs incorrects, ou faire crasher la JVM à l'exécution.
Cette anomalie touchait notamment Apache Lucence, le célèbre moteur de recherche en full TEXT, ainsi que son sous-produit Solr.
Oracle a sortie cet Update il y a quelques jours, mais n'a mis à jour qu'aujourd'hui les statuts des trois rapports du compilateur "JIT [Just in Time] et les bogues de boucle" signalés par la fondation. D'autres bogues relatifs, découverts en interne, ont été corrigés.
Uwe Schindler, un contributeur du projet confirme après des tests que l'anomalie a bien été résorbée. Il n'a cependant pas précisé si l'utilisation des flags -XX:+OptimizeStringConcat et -XX:+AggressiveOpts reste toujours recommandée.
Télécharger Java 7u1
Source : Oracle, blog d'un contributeur à Apache
Suite au blog du developpeur lucene : Oracle a mis a jour les releases notes de java7u1
http://www.oracle.com/technetwork/ja...es-507962.html
c'est maintenant parfaitement clair : go pour java 7 en prodJIT and Loop Bugs
Three bugs reported by various parties, including Apache Lucene developers, have been fixed in JDK 7 Update 1, in addition to a fourth related bug found by Oracle (7070134, 7068051, 7044738, 7077439).
Aaahhhhhh !!!
Voila une excellente nouvelle ! Encore quelques semaines, et j'envisagerais de passer à Java 7...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager