new Blog( perso );

La première journée de conférence de Devoxx s'ouvre sur le traditionnel Keynote. J'ai loupé l'heure et me retrouve déporté dans une seconde salle ou la session est retransmise live, nettement moins vivant que d'avoir le speaker en face, ça me servira de lesson ...

Après quelques chiffres sur l'événement (3000 inscrits, et quelques centaines qui sont restés derrière la porte... ça fait rêver), Stephan Jansen nous fait une démo du nouveau Parleys et de ses clients mobiles (Android, iPhone, iPad) - démo live basée sur le réseau wifi doppé aux stéroïdes cette année, le touilleur peut même uploader ses vidéos en live ! Leçon à retenir pour ceux qui ont un réseau wifi pourri, et qui invoquent des limites techniques infranchissables - Parleys va devenir une plateforme incontournable pour la diffusion de vidéos avec toutes ces avancées techniques : mpeg4, meilleure résolution vidéo, client mobile qui se synchronise au client desktop (et peut alors servir de télécommande :P) et même streaming live (allez voir les keynotes !)

Suit la keynote de Mark Reinhold, consacrée à la roadmap Java. Les évolutions de la syntaxe Java 7 sont présentées, ce qui n'est pas une révolution vu que c'était déjà annoncé l'an dernier. Disons que ça confirme, ce qui est déjà bien vu les changements et les délais associés à Java 7 depuis plusieurs années.

On aborde ensuite un sujet clé : le parallélisme. Les processeurs à 128 coeurs sont déjà dans les labs et équiperont sous peu les serveurs haut de gamme. Comment programmer efficacement sur de telles architectures ? La réponse semble être dans un changement de paradigme, porté par le projet lambda. Les lambda expression permettent d'exprimer des traitements selon une approche ensembliste, ce qui laisse au compilo / JVM la possibilité de paralléliser massivement. Une idée pour Java 7 est de "compléter" l'API des collections avec des notions de filtres, regroupements, conversion, ce qui apporte une syntaxe fluide pour transformer sur des collections. Avec cette évolution, le même code pourra ainsi fonctionner sur mono-processeur (pensez à Java SE Embedded sur les mobiles) et sur serveur massivement multi-coeur. "Run anywhere", ça vous dit quelque chose ? On va passer au "Scale anywhere" (© nmartignole)

Plusieurs autres évolutions sont présentées, je note en particulier la notion de "value Class" qui permet de manipuler des propriétés SANS définir les méthodes accesseurs. Je vous en est déjà parlé sur ce blog, c'est une évolution que je soutiens de tout mon modeste poids ;)

La JVM ne se limite pas au seule langage Java, mais supporte un joli pannel de langages alternatifs, dont Groovy, jRuby ou Jython ne sont que la partie émergée et médiatisée de l'iceberg. La JSR 292 "DaVinci Machine" propose d'améliorer ce support avec les invocations dynamiques de méthodes. Si ça n'a l'air de rien, cela ouvre la voie à un développement beaucoup plus ouvert sur d'autres langages, d'autres pratiques. Pas forcément évident pour éviter de se disperser, mais potentiellement fort si o,n veut définir des DSL groovy pour une partie métier, intégrer une interface web avec des développeurs PHP, et que sais-je.

On revient ensuite sur l'arlésienne de la modularité Java, qui chasse sur les terres d'OSGi avec une syntaxe différente et bien moins d'expérience du terrain, et reprend une partie des fonctionnalités de gestion de dépendances de Maven / ivy. Je n'arrive pas à me faire une opinion claire sur la pertinence de cette approche et sur son intérêt pour notre quotidien de développeur. L'idée de base est de faire disparaître le concept de classpath, qui prend le risque d'être incomplet pour une exécution correcte de l'application, et de reposer sur des descripteurs pour valider les dépendances au démarrage. L'approvisionnement reposerait donc sur des mécanismes de dépot à la RPM, DEB ou Maven. Si cela permettrait de mettre un peu de standardisation dans tout ça, je ne suis pas sûr que mon client s'attende sur ses serveurs à une installation de ce type ... surtout sans accès à Internet depuis les machines de production.

Point sur la convergence des JVM : Hotspot et JRockIt fusionnent dans OpenJDK, rejoint par IBM (et donc sa JVM J9) ainsi que Apple qui renonce à sa JVM spécifique. Si une meilleur JVM peut émerger de ces efforts conjoints, et que chacun peut apporter son expérience, on perd tout de même en diversité. Chaque éditeur va probablement garder ses outils de diagnostic comme chasse gardée, étant la base de la plus-value qu'ils peuvent vendre sur une JVM payante.

On conclut sur le "plan B", qui repousse les fonctionnalités les plus polémiques de Java 7 (lambda et modularisation) à ... plus tard, mais permet d'avoir (enfin) une roadmap réaliste pour la sortie de Jav 7 en 2011. Un point important est qu'une JSR est (enfin aussi) définie pour porter Java 7, qui ne reposera donc pas exclusivement sur le fonctionnement "de fait" d'OpenJDK pour définir le future version majeur  de Java.