Article complet: Planning Java 7 : retard et plan B

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.

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

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.

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 :

• Compression des pointeurs 64bits afin de diminuer l'occupation mémoire des JVM 64bits.
• Garbage Collector "Garbage First" (G1).
• Le support en interne des langages dynamiques via l'instruction invokedynamic.
• La compilation "tiered" qui cumule les avantages des JIT client et server.

Au niveau des APIs, on pourra surement compter sur ceci :

• NIO.2 pour l'accès complet au système de fichier et les channels asynchrones
• La nouvelle API de concurrence (ForkJoin, Phaser, ...).
• La standardisation des nouveautés du JDK6u10 (nouveau plugin, Java Kernel, fenêtres transparences et non-rectangulaires, mélanges de composants AWT/Swing, LnF Nimbus, JLayer, Painter).
• L'évolution de quelques classes et package existant (ProcessBuilder, JList<T> java.net, javax.net.ssl, ...).

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 :

• Le support syntaxique des collections (à la manière des tableaux).
• La package java.dyn qui devrait permettre de supporter l'invocation dynamique dans le langage Java (InvokeDynamic et MethodHandle). En réalité ce package est déjà présent dans les derniers builds mais c'est désactivé par défaut...

Après le report des Lambdas pourraient permettre de voir arriver une API adaptée...


a++

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 :D

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...

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

@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. 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).

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.

@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 :

• Les types sont passées tels quel, sans être encapsulé dans un tableau ni "wrappé".
• Les règles de sécurité et de visibilité sont vérifiées uniquement à la création du handle, et non pas à chaque appel comme avec la reflection.
• Cela correspond en quelques sortes à un pointeur vers la méthode, donc le coût d'appel est équivalent à celui d'une méthode classique.

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++

@adiGuba merci beaucoup pour ces précisions sur invokedynamic. En effet le gain devrait être énorme!

Le projet lambda me rebute, j'attends principalement NIo2 et Coin. Le plan "B" me comblerais, je vote pour.