27
août
2009
août
2009
7 (Dolphin) // Java
Première modification du langage : Diamond syntax
Un article de adiGuba
La syntaxe du langage Java vient de recevoir sa toute première modification depuis Java 5. En effet le développement de Java 7 vient d’enrichir ce dernier de la syntaxe « diamond », que l’on appellera sûrement « syntaxe en losange » en français.
Alors quoi de neuf ? Il s’agit simplement d’un sucre syntaxique évitant la duplication du paramétrages des Generics lorsque le contexte le permet (c’est à dire lorsque le compilateur peut le déduire du reste du code).
En clair, à la place de ceci :
Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
List<Reference<MyBeans>> list = null;
list = new ArrayList<Reference<MyBeans>>();
On pourra désormais écrire ceci :
Map<Integer, List<String>> map = new HashMap<>();
List<Reference<MyBeans>> list = null;
list = new ArrayList<>();
Bref rien d’extraordinaire en soit, mais cela confirme bien que le projet Coin n’est pas tombé dans l’oubli, reste à voir ce qu’ils nous proposeront par la suite…
Source : Diamond at the gate, par Rémi Forax
19 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- Recuperation du nom des parametres
- Classes, méthodes private
- [ fuite ] memoire
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- jre 1.5, tomcat 6.0 et multi processeurs
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Définition exacte de @Override
- Possibilité d'accéder au type générique en runtime
- Difference de performances Unix/Windows d'un programme?
cool
A propos, je lisais hier soir ces chiffres sur le 4eme trimestre sun : http://www.theregister.co.uk/2009/08/31/sun_f2009_numbers/
On peut notamment y lire :
Sun’s software billings in Q4 relating to Java and MySQL were bright spots in the financials, so you can see why Oracle wants to get control of these. But both are still, relatively speaking, small potatoes. Java billings in Q4 came to $108m, up 22 per cent, and MySQL database sales hit 100m, up 10 per cent. Solaris licenses, plus management and virtualization software sales, declined by 29 per cent in the fourth quarter, to 45m. For the fiscal 2009 year, Java billings came to $281m, up 28 per cent, MySQL billings came to $313m, up 51 per cent, and Solaris and add-on license billings hit $159m, down 26 per cent.
Je trouve vraiment faible l’argent fait avec Java perso, je serai curieux des chiffres similaires pour .Net.
++
Je n’ai pas d’info sur le planning.
Par contre je trouve que ces derniers temps cela se met à beaucoup bouger…
a++
Merci pour toutes ces infos bien intéressantes !
Une idée de planning pour Java 7 à propos ? Stephen Colebourne semble dire qu’il ne verra jamais le jour…
++
Oui à l’origine la JSR 292 concerne principalement les langages dynamiques destiné à être compilé en bytecode. Dans le bytecode on ne peut pas faire d’appel de méthode qui ne soit pas définit dans la classe ou l’interface. Or les langages dynamiques utilisent un typage très faible et beaucoup d’appel dynamique (en clair le compilateur ne vérifie pas l’existence de la méthode, mais cela peut générer une erreur à l’exécution si elle n’existe pas).
La JSR 292 va donc insérer un nouveau mode d’invocation de méthode (invokedynamic) qui ne vérifiera l’appel de méthode qu’à l’exécution. A l’origine cette modification ne devait pas impacter Java mais seulement le bytecode. C’est à dire qu’elle ne serait utilisé que par des compilateurs d’autres langages.
Mais le projet Coin va donc insérer cela même dans le langage… Et en effet cela pourrait être pratique dans de nombreux cas.
Petit exemple de ce que cela permettra :
On pourra donc appeler n’importe quelle méthode sur un objet sans connaitre son type exact, ni le caster dans un type spécifique.
Avant, il aurait fallut utiliser la reflection (et un paquet d’exception à traiter :
a++
Tu disais dans un autre billet que la 292 concernait principalement les autres langages.
J’ai lu par ailleurs :
Au delà des langages dynamiques qui sont les premiers destinataires de cette JSR, de nombreux frameworks pourront également profiter de cette possibilité. En effet, la manipulation de JavaBeans et d’annotations, deux concepts majeurs dans le monde JEE actuel, induisent de nombreuses invocations de méthodes découvertes au runtime. Dans de larges projets, cela conduit actuellement à la génération massive de bytecode pour éviter de très lentes introspections, induisant une forte consommation de la PermGen des JVMs.
J’ai hâte de voir dans un cas concret un avant/après ;o)
Apparemment la liste des changements apportés par le projet coin est fixé : Project Coin: The Final Five (Or So)
En plus de l’opérateur « diamond », on devrait avoir :
Si j’ai le temps j’essayerais de revenir sur tout cela…
a++
Là, je serai moins d’accord car à gauche, j’utilise Map beaucoup plus souvent que Hashmap.
Si je met Map à gauche, comment il sait le type d’implémentation ? ça fait un cas particulier !
Sinon, d’accord pour ton exemple.
Il aurait même peut être été possible d’écrire :
Hashmap « coin gauche »String, Chose « coin droit » monHash = new;
… vous ne trouvez pas ? Tout se déduit du contexte que je sache ?
+1 cela n’apportera aucune incompatibilité tout en permettant d’éviter la répétition des types paramétrés (ce qui peut parfois être un peu lourd). Et c’est surement pour cela qu’on la retrouve intégré en premier…
Je rappelle quand même que le projet Coin n’a pas pour objectif d’intégrer des modifications majeures (pas de Closures :(), mais je suis quand même curieux de voir la suite !
a++
Normalement ce n’est pas ceci qui devrait introduire une quelconque incompatibilité des binaires. C’est juste une extension/correction de la grammaire supportée par le compilateur.
Oula ce que je voulais dire bien sur c’était ca (enfin si mes < passent cette fois)
Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
et
Map<Integer, List<String>> map = new HashMap();
Je confirme la dernière phrase: « rien d’extraordinaire en soit »
Et si le prix à payer pour (et uniquement pour) ce genre de futilité est un incompatibilité du code avec les versions précédentes, mon choix sera très vite fait.
Autant les évolutions de la syntaxe du 1.5 se justifiaient par l’ajout de nouvelles [u]fonctionnalités[/u], autant là c’est juste du cosmétique qui n’apporte absolument rien.
remarque au final
Map map = new HashMap();
et
Map map = new HashMap();
ca ne change finalement strictement rien ensuite quand on utilise la map, on reste obligé d’utiliser des Integer en clef et List en valeur (tant qu’on a pas fait un truc comme ca Map map2 – map;) auquel cas on peut coller ce qu’on veut dans map2
bouye tu voulais peut-être dire ceci :
C’est en effet largement suffisant, mais il doit y avoir une volonté de forcer l’utilisation des Generics, pour éviter tout malentendu
a++
bouye, si j’interprète ton message partiel, tu veux dire qu’ils aurait pu se passer des signes inférieur et supérieur du côté du new ? (La déclaration de la variable restant toujours templaté)
mais dans ce cas, ils auraient pas pu l’appeler diamonds ;o)
Zut, le code ne s’affiche pas correctement
Je persiste a dire que le diamant en question est TOTALEMENT inutile dans la syntaxe et sera probablement abandonne lors d’une mise a jour ulterieure du language (dans une dizaine d’annee au rythme ou les specs de Java7 ont evoluees).
Faire ceci eut ete largement suffisant :
Map map = new HashMap();
Non je n’ai pas d’info en plus…
Je sais juste que le projet Coin a reçu beaucoup de proposition (plus de 60), mais que très peu seront intégré dans Java 7…
Mais en même temps j’avais un peu suivi la mailling list il y a quelques temps, et il y a vraiment de tout : on passe du sucre syntaxique plus ou moins pratique à des fonctionnalités nettement plus poussés (peut-être trop) mais dont l’utilisation se révèle parfois bien anecdotique…
Donc « Wait & See »…
a++
Le point 5 de ce post (http://www.developpez.net/forums/d758625/forums-redaction/priv-groupe-java/openjdk-evolution-langage-projet-coin/#post4478906) est donc confirmé.
Et les autres, as tu des infos ?