septembre
2010
Un article de adiGuba
Mark Reinhold, qui dirige les travaux sur la plateforme Java chez Oracle, vient de publier sur son blog personnel un billet intéressant quand à la prochaine version de Java : Re-thinking JDK 7.
Comme on s’en doutait un peu, suite au rachat de Sun par Oracle et à l’ajout de nouveaux projets (Lambda, Jigsaw et Coin), le planning originel n’a pas été respecté (Le JDK7 aurait dû sortir demain !) alors que la version actuellement en développement n’a même pas encore atteint le status de « feature-complete« , et qu’il manque toujours plusieurs JSRs…
Et dans ces cas là, il y a toujours une bonne et une mauvaise nouvelle…
La bonne, c’est qu’Oracle ne va pas abandonner les JSRs pour le développement de Java.
La mauvaise c’est que le JDK7 arrivera bien plus tard qu’on ne le pensait. Tel qu’il est défini actuellement, le JDK7 ne pourrait pas voir le jour avant la mi-2012 !
Toutefois, Oracle semblerait privilégier un « plan B » qui verrait le JDK7 sortir à la mi-2011 (une année plus tôt donc), mais amputé de certaines de ses fonctionnalités (en particulier les projets Lambda, Jigsaw et une partie du projet Coin).
Les fonctionnalités manquantes serait reportées au JDK8 pour la fin de l’année 2012.
11 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- Recuperation du nom des parametres
- Classes, méthodes private
- Difference de performances Unix/Windows d'un programme?
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Possibilité d'accéder au type générique en runtime
- [ fuite ] memoire
- Définition exacte de @Override
- jre 1.5, tomcat 6.0 et multi processeurs
Le projet lambda me rebute, j’attends principalement NIo2 et Coin. Le plan « B » me comblerais, je vote pour.
@adiGuba merci beaucoup pour ces précisions sur invokedynamic. En effet le gain devrait être énorme!
@Uther : Tu veux parler de la JSR 310 (Date and Time API) : c’était seulement pressentie, mais déjà absent du planning de février 2009 : http://openjdk.java.net/projects/jdk7/features/
Peut-être que cela intègrera le JDK8…
@Loic : L’intérêt de l’invokedynamic c’est que c’est géré au niveau de la JVM via une instruction spéciale. Actuellement les invocations de méthode sont trop rigide, et cela nécessite de manipuler un méthode connu sur un type connu. Bref tout l’inverse de ce qu’on peut faire avec un langage dynamique. Une des solutions consiste à passer par une méthode generique, qui utilisera la reflection pour rechercher et exécuter la bonne méthode.
Mais la réflection reste assez lourde, même s’il y a eu d’énorme progrès dans le domaine.
Surtout si l’on compare à un simple appel de méthode : cela impose plusieurs vérifications (type de l’instance, des paramètres, visibilité de la méthode, …) une conversion des types primitifs vers leurs types Wrapper et l’utilisation d’un tableau pour stocker les paramètres.
Avec invokedynamic, le premier appel de la méthode exécute une méthode bootstrap qui va se charger de rechercher la méthode à invoquer, puis de retourner un MethodHandle vers cette dernière. Les appels successif utiliseront directement ce MethodHandle.
Or les MethodHandles apportent plusieurs avantages :
Donc en théorie cela devrait booster les performances des implémentations de langages dynamiques sur une JVM
Maintenant cela imposera d’utiliser une JVM 1.7, ce qui risque de retarder les implémentations.
L’invokedynamic est très important pour la JVM et les langages dynamiques.
a++
C’est dommage, mais en même temps je préfère ça que d’avoir des lambda a moitié finis.
@Adiguba> Il me semblait que l’intégration de JodaTime était prévue à une époque, ce n’est plus d’actualité?
@Loic> Il me semble que Groovy n’en tire pas encore partie. Ça nécessite tout de même des changements en profondeur du compilateur.
Mais d’après quelques tests qui ont été fait sur certains langage dynamiques, le gain potentiel est très conséquent.
@Loic
Scal offre certainement des paradigmes très intéressants, les traits, les acteurs, la programmation fonctionnelle, et d’autres trucs…
Cependant Scala n’est pas sans défaut, typiquement à propos des dates :
« Java’s class libraries define powerful utility classes, such as Date and DateFormat. Since Scala interoperates seemlessly with Java, there is no need to… »
cf. http://www.scala-lang.org/docu/files/ScalaTutorial.pdf
Honnêtement les objets Date sont connus pour être mutable, avec une API mal conçue, et avec des problèmes de performance. C’est typiquement le genre d’objet à ne pas utiliser dans une architecture concurrente (et je pense là aux acteurs sur lequel Scala repose entre autres).
Pour ce qui est du invokedynamic, ça améliore vraiment la rapidité d’execution des langages dynamiques?
ça donne quoi sur groovy par exemple, quelqu’un a essayé?
Loic
Je suis vraiment déçu qu’on doive encore encore attendre au mois 2 ans pour lambda…
Je crois qu’il est vraiment temps d’apprendre le Scala
Avec le temps qu’ils ont en plus si ils pouvaient apporter un support des properties, c’est pas indispensable mais ça allégerait toujours un peu les classes…
Si on se base sur les derniers builds du JDK7, on peut avoir une idée de ce à quoi ressemblerait le JDK7 « B ».
On peut déjà noter des améliorations de la JVM :
Au niveau des APIs, on pourra surement compter sur ceci :
Quand au projet Coin, il est quasiment totalement implémenté dans les derniers builds (litéraux numériques, switch sur String, opérateur en losange, multicatch et rethrow, try-with-resources).
En fait il ne manque que deux éléments originellement prévu :
Après le report des Lambdas pourraient permettre de voir arriver une API adaptée…
a++
On aura apparemment une partie des updates du projet Coin, faudra voir lesquelles.
Faudrait voir précisement ce qu’ils vont inclure dans le JDK7 Plan B.
Hum, sans jigsaw closures lambdas : reste pas grand chose non ? Datetime et nio2 ?
Java 6.1 en gros
Ou alors j oublie un gros truc
Personnellement, je pense que la bonne solution serait le plan B. Ce serait cool d’avoir une sortie assez vite même avec un peu moins de fonctionnalités et d’avoir ensuite le reste plus tard.