Pour cette keynote, Joshua Bloch, Mark Reinhold, Stephen Colebourne, Antonio Goncalves, Juergen Hoeller et Bill Venners débattent des orientations de la plateforme Java face aux questions de la communauté.
Java doit-il rester backward compatible ou devons nous avoir le courage de casser les choses ?
La question ne fait pas l'unanimité. Rien que dans le JRE, les méthodes deprecated ne disparaissent souvent pas au cours des versions suivantes. Joshua aimerait pourtant (par exemple) que la notation "32l" pour définir un long 32 (et pas l'entier trois-cent-vingt-et-un !) ne soit pas acceptée, et remplacée par "32L" moins ambigu. Evolution simple mais déjà pas si simple d'obtenir le consensus.
Quel impact d'Oracle sur la communauté Java ?
De l'avis général, tout n'a pas été positif, mais personne n'ose explicitement mettre les pieds dans le plat. Antonio prend finalement la parole pour résumer le BOF Jug d'hier qui a été positif et les opportunités qu'Oracle nous propose.
Comment gérer le problème de licence du TCK Java ?
(rappel : Apache Harmony ne peut pas être validé "Java" pour cette raison). Mark Reinhold ne veut pas se dérober à cette question (ce qui l'obligerait à porter un chapeau ridicule en alu, c'est la règle), cependant il ne peut pas répondre officiellement... mais ne voit pas Apache obtenir une licence TCK ni à court ni à long terme.
Android peut-il être la plateforme Java mobile de facto ?
Antonio élargit le problème à la gestion des communautés Groovy, Scala, et donc Android, qui font partie de l'écosystème Java sans rentrer dans le moule. Juergen ajoute Google App Engine et défend que ces initiatives permettent de défricher l'avenir de Java et doivent avoir leur place, en tout cas être "autorisées" dans la communauté. En résumé, avoir ajouté un aspect légal sur le débat est la pire chose qu'il y avait à faire.
Qu'est ce que .Net (plateforme/communauté) pourrait nous apprendre pour améliorer Java ?
Techniquement, .Net a bénéficié de Java pour ne pas faire les mêmes erreurs. Les puzzlers de Joshua, traduits en .Net, ne produisent plus de problème par exemple. Cela nous ramène à la première question ...
Va t-on voir la fin de la gue-guerre JigSaw/OSGi ?
Oracle vend en effet des produits basés sur OSGi, alors ? OSGi est utilisé sur de gros frameworks, serveurs d'application, middlewares, etc, mais est peut être un peu compliqué pour un usage plus standard. Java 8 vise plus une unification pragmatique, pour résoudre les problèmes simples dans la JVM, ce pour lequel OSGi est sur-dimensionné.
Comment gérer les JVM legacy que nous héritons du parc installé (i.e. Websphere) ?
Le passage en Java5 n'est pas encore une généralité... alors Java 7 ! Un problème dérivé est le temps entre la finalisation d'une JSR et son implémentation. Un an après JavaEE 6 les grosses implémentations ne sont pas encore là. Peut être revoir la logique du JSR pour être plus incrémental...
Java permettra t-il d'accéder aux noms des paramètres de méthodes ?
oui ! c'est possible, reste à savoir comment ... car cela va poser un problème de compatibilité (retour à la question 1 encore une fois).
L'approche fonctionnelle est-elle si pertinente qu'elle devrait être formellement intégré à Java ?
Scala, Clojure montrent la voie, doit on avoir un langage officiel pour cela ? Retour en arrière pour rappeler l'engouement pour XML et sa désaffection (relative). L'associer très officiellement à Java aurait-il eu un intérêt ? Si l'approche fonctionnelle apporte une vision intéressante, trop de choses dans le langage risquent de le scléroser. Par contre, des facilités dans le JDK pour mieux supporter les langages fonctionnels sont une option à considérer ...
Comment Oracle espère t-il faire revivre JavaME fàce à la concurrence sans Android ?
Modular Java permettrait de faire entrer Java sur des mobiles, cependant cela reste hypothétique. La question renvoie à l'organisation du JCP, et ses nombreux représentants issus du monde mobile.
Comment corriger le JCP ?
Idéalement : construire une structure indépendante, sur le modèle de la fondation Eclipse. Mais quel intérêt pour Oracle de lâcher sa main-mise sur Java ? Antonio modère le sujet en précisant que la participation au JCP reste ouverte et que certaines JSR sont pilotées par des indépendants. Toujours plus de transparence reste cependant une priorité.
Le lien avec la position dure prise par Doug Lea sur le JCP est porté par la question suivante, mais baser Java 7 sur le seul OpenJDK ne peut être la solution. Comment savoir ce qui fait foi, comment savoir si le code d'une JVM alternative est respecte la norme ou est juste compatible ? Des petites phares fusent, elles ne manqueront pas d'être reprises sur twitter :P
Jusqu'à quand l'historique desktop de Java va t-il encombrer le JRE ?
C'est l'une des raisons d'être de Java modularisation ! Sur le besoin de modularité, l'unanimité est faite.
La plateforme correspond elle à l'utilisateur "standard" de Java aujourd'hui ?
Joshua est partisan d'une simplification de la syntaxe et de l'élimination de nombreux tweaks qui font de Java un outil pas 100% satisfaisant pour la grande majorité de développeurs qui programment pour payer leur facture. Les geeks qui vont aux JUGs et à Devoxx sont une toute petite minorité. Qui par exemple a défini ses propres annotation ? Qui utilise les generics pour autre chose que des List ? Il manque peut être un niveau de langage dédié aux développeurs de librairies et un autre pour le développeur lamba...
19 novembre 2010
Dernière ligne droite ...
Dernier jour à Devoxx, les stands se démontent, beaucoup sont déjà partis. Les survivants se regroupent à l'étage au pied des salles pour un dernier café. Ce matin, la keynote sera consacrée aux attentes de la communauté sur l'avenir de Java, synthétisées après deux BOFs les jours précédents. Antonio s'y colle pour représenter les JUGs, quand on lui tend un micro il ne sait pas résister, pire qu'un gosse :P
Suivra l'enregistrement live des castcodeurs, en parallèle des quelques sessions qui terminent cette édition, et pour moi un retour express à la gare pour ne pas louper mon Thalys.
Ce que je retiens de cette édition :
Rendez-vous l'an prochain pour Devoxx 2011, si je ne vous ai pas convaincu que c'est LA conf à laquelle il faut venir, je ne peux plus rien pour vous :P Pensez aussi à l'abonnement PArleys à 79€ pour voir ou revoir toutes les sessions.
Suivra l'enregistrement live des castcodeurs, en parallèle des quelques sessions qui terminent cette édition, et pour moi un retour express à la gare pour ne pas louper mon Thalys.
Ce que je retiens de cette édition :
- la force de l'approche REST. Le programme de Devoxx a été mis à disposition via une API Rest, s'en est suivi une poignée de clients pour iPhones, iPad, Android, GWT, Flex, JSF+HTML5 (et pas JavaME, tiens?). Ce petit exemple montre que REST est peut être l'approche qu'on attendait de longue date pour découpler la présentation du métier, laissant chaque couche choisir sa technologie d'implémentation.
- le Cloud, très présent sur cette édition même si j'ai suivi peu de sessions, avec des retours d'expérience de FaceBook et Twitter pour lesquels les volumétries tiennent du délire.
- la communauté Java qui s'organise et Oracle qui a clairement appris à l'écouter. Après un passage à vide, la reprise du flambeau par Oracle semble donc bien engagé.
Rendez-vous l'an prochain pour Devoxx 2011, si je ne vous ai pas convaincu que c'est LA conf à laquelle il faut venir, je ne peux plus rien pour vous :P Pensez aussi à l'abonnement PArleys à 79€ pour voir ou revoir toutes les sessions.
18 novembre 2010
JavaPuzzlers et BOF
Dernière session de la journée, un bon vieux Java Puzzler de Joshua Bloch. Si vous ne connaissez pas, procurez-vous le bouquin ! En gros, ce sont des fragments de code qui cachent un bug auquel on ne pense pas du tout au premier abord. Un raffinement dans la gestion du compilateur ou dans la structure des collections, bref un truc qui peut vous plomber une appli. Avec une mise en scène qui donne un style très spécifique aux présentations de Joshua Bloch, 6 puzzlers de ce type sont présentés puis décortiqués, avec à chaque fois une lesson à retenir.
Votre serviteur s'en tire avec 2 bonnes réponses (avec la bonne explication, sinon ça ne compte pas) sur 6, on va dire que la journée était rude pour me trouver une excuse ;)
On enchaine avec la dernière soirée autour des stands des sponsors, qui seront démontés dans la soirée. C'est l'occasion de récupérer tous les goodies qu'on a pas réussi à gagner par tirage au sort parce qu'il faut écouler les stocks avant de remballer - hop, une clé USB IBM et un TShirt Capgemini ;)
Ajoutons à cela quelques bières sur le stand Oracle (je ne sais pas si je vous l'ai dit, mais à Devoxx on boit pas mal de bières), et voila que je loupe le BOF JDuchess, c'est malin ...
Je me rattrape en rejoignant le BOF JUG-Leaders qui à lieu juste après. Jackie, représentant Oracle, vient renouer le lien avec les JUG-Leaders, lien qui avait été mis à mal par les petites erreurs de communications d'Oracle après sa reprise de la communauté Java. Pour résumer, après les propositions déplaisantes dont j'ai déjà parlé sur ce blog, Oracle laisse au JUGs carte blanche pour organiser leur activité, par contre il propose - au dela de ce que SUN faisait - de nous joindre aux réunions annuelles des OUG pour bénéficier :
Ce dernier point est important car il nous permettrait de rentrer dans une dynamique bien plus puissante que ce que nous connaissons aujourd'hui, avec des JUG qui s'entraident pas copinage. Par contre, cela suppose un minimum de structuration, une hiérarchie des JUGs pour qu'Oracle n'ai pas 200 interlocuteurs.
En pratique, ce n'est pas vraiment un problème : tous les JUG-Leaders ne sont pas disponibles pour se libérer 2 jours je ne sais où, et nous sommes déjà organisés en réseaux informels en fonction de notre taille et de notre représentativité respective. Aucun JUG-Leader français ne reprochera à Antonio de s'être exprimé en notre nom lors du premier contact avec Oracle, car il le fait en toute transparence et n'hésite pas à donner de sa personne au ParisJug pour laisser une place aux JUGs de province.
Oracle opère donc un virage à 180° et a retenu la leçon de sa communication ratée des premiers jours. Jackie est une représentante sympathique et très ouverte, prête à nous entendre et à adapter l'organisation des meetings OUG pour nous y faire une place. Et pour finir sur une touche de bonne humeur, on termine le BOF au mexicain d'à côté autour ... d'un Mojito (une fois n'est pas coutume).
Votre serviteur s'en tire avec 2 bonnes réponses (avec la bonne explication, sinon ça ne compte pas) sur 6, on va dire que la journée était rude pour me trouver une excuse ;)
On enchaine avec la dernière soirée autour des stands des sponsors, qui seront démontés dans la soirée. C'est l'occasion de récupérer tous les goodies qu'on a pas réussi à gagner par tirage au sort parce qu'il faut écouler les stocks avant de remballer - hop, une clé USB IBM et un TShirt Capgemini ;)
Ajoutons à cela quelques bières sur le stand Oracle (je ne sais pas si je vous l'ai dit, mais à Devoxx on boit pas mal de bières), et voila que je loupe le BOF JDuchess, c'est malin ...
Je me rattrape en rejoignant le BOF JUG-Leaders qui à lieu juste après. Jackie, représentant Oracle, vient renouer le lien avec les JUG-Leaders, lien qui avait été mis à mal par les petites erreurs de communications d'Oracle après sa reprise de la communauté Java. Pour résumer, après les propositions déplaisantes dont j'ai déjà parlé sur ce blog, Oracle laisse au JUGs carte blanche pour organiser leur activité, par contre il propose - au dela de ce que SUN faisait - de nous joindre aux réunions annuelles des OUG pour bénéficier :
- d'un peu de pub sur les produits Oracle (faut bien justifier l'hotel qu'il nous réservent),
- d'échanges privilégiés avec les représentants Oracle,
- de temps pour échanger entre JUG-Leaders, bien plus que l'heure consacrée au BOF une fois par an à Devoxx.
Ce dernier point est important car il nous permettrait de rentrer dans une dynamique bien plus puissante que ce que nous connaissons aujourd'hui, avec des JUG qui s'entraident pas copinage. Par contre, cela suppose un minimum de structuration, une hiérarchie des JUGs pour qu'Oracle n'ai pas 200 interlocuteurs.
En pratique, ce n'est pas vraiment un problème : tous les JUG-Leaders ne sont pas disponibles pour se libérer 2 jours je ne sais où, et nous sommes déjà organisés en réseaux informels en fonction de notre taille et de notre représentativité respective. Aucun JUG-Leader français ne reprochera à Antonio de s'être exprimé en notre nom lors du premier contact avec Oracle, car il le fait en toute transparence et n'hésite pas à donner de sa personne au ParisJug pour laisser une place aux JUGs de province.
Oracle opère donc un virage à 180° et a retenu la leçon de sa communication ratée des premiers jours. Jackie est une représentante sympathique et très ouverte, prête à nous entendre et à adapter l'organisation des meetings OUG pour nous y faire une place. Et pour finir sur une touche de bonne humeur, on termine le BOF au mexicain d'à côté autour ... d'un Mojito (une fois n'est pas coutume).
Modularisation de la JVM
Cette session présente JigSaw, qui continue son lobbying pour imposer à la JVM une modularisation autre que celle proposée par OSGi ...
A quoi ça sert ? A sortir du classpath Hell, à accélérer le lancement de la JVM, à alléger le runtime, à approvisionner automatiquement (comme le font les Linux avec apt ou yuml), et à assurer la prédictibilité de l'environnement d'exécution.
La vérification du classpath à l'installation plutôt qu'au runtime, associé à la construction de profils pour une application (liste des classes effectivement chargées lors du premier lancement) doivent nous apporter un gain significatif de fiabilité et de réactivité. La mise en cache des description des classes (i.e. conversion des .class dans un format plus efficace) est aussi une astuce exploitée pour améliorer encore l'environnement d'exécution Java. Toutes ces optimisations sont liées à la possibilité de traiter les problèmes de classpath lors de l'installation, et non au runtime.
Le fichier module-info.java (non qui est en principe invalide pour une classe normale) sert de descripteur à la définition d'un module - à une autre époque on aurait choisi un descripteur XML, les temps changent. Le module permet de définir les requirements de notre module (en gros, les dépendances runtime si vous raisonnez comme moi en langage Maven), y compris avec la notion de requirement optionnel et bien sûr cela implique la gestion de la transitivité - espérons que le modèle choisi pour cela sera compatible avec Maven et OSGi, sinon ça promet...
Avec cette possibilité de définir des modules, il devient facile de découper un gros projet en modules et de les référencer dans un module aggrégateur (tout ce vocabulaire me rappelle bizarrement quelque chose).
A l'usage, le compilateur javac proposera une nouvelle option -modulepath permettant d'indiquer les emplacements de nos modules - en gros, notre localRepository :P. La nouvelle commande jpkg permet alors de construire un livrable selon un nouveau format (oubliez vos jars). La commande jmod quand à elle nous apporte l'approvisionnement des modules pour pouvoir lancer la JVM avec un paramètre -mlib indiquant l'emplacement des modules nécessaires à l'exécution. Et comment fait-elle cet approvisionnement ? Avec un dépôt de modules ! Et bien sûr, le repo maven2 est supporté comme source de modules. Qui a dit "standard de fait" ?
Avec ce mécanisme, une application Java va donc pouvoir démarrer avec une version "allégée" de la JVM, typiquement le lancement d'un batch en ligne de commande ou d'un serveur d'application va s'épargner toute la couche graphique AWT et Swing.
Comment tout ça va s'intégrer au JRE ? Un slide nous présente les dépendances entre packages Java, et on a un magnifique effet spaghetti à l'écran, surtout avec l'ajout des API JavaEE par dessus couleur sauce tomate... Après un gros refactoring, la JRE est descendue à un graphe de 25 noeuds et 97 relations, qui devient raisonnablement affichage dans un slide. Ca a du être un sacré boulot :) En terme de compatibilité, cela suppose néanmoins que les applications existantes ne dépendent que des API publiques et pas de leurs détails d'implémentation.
Et OSGi dans tout ça ?
Au moins on écarte pas le débat lors de cette session... Mark Reinhold répond en un exemple : un module A requiert un module B. Avec la modularité Java, A et B peuvent être packagés en paquet debian et résolus à l'installation. De même, Maven gère sans soucis ce cas d'utilisation. Dans le cas d'OSGi, deux bundles peuvent exporter la même API publique sans définir de moyen de résolution privilégié. Le modèle OSGi est donc implicitement plus complexe, focalisé sur un niveau de granularité package, ce qui est souvent un niveau trop fin pour modulariser du code.
A quoi ça sert ? A sortir du classpath Hell, à accélérer le lancement de la JVM, à alléger le runtime, à approvisionner automatiquement (comme le font les Linux avec apt ou yuml), et à assurer la prédictibilité de l'environnement d'exécution.
La vérification du classpath à l'installation plutôt qu'au runtime, associé à la construction de profils pour une application (liste des classes effectivement chargées lors du premier lancement) doivent nous apporter un gain significatif de fiabilité et de réactivité. La mise en cache des description des classes (i.e. conversion des .class dans un format plus efficace) est aussi une astuce exploitée pour améliorer encore l'environnement d'exécution Java. Toutes ces optimisations sont liées à la possibilité de traiter les problèmes de classpath lors de l'installation, et non au runtime.
Le fichier module-info.java (non qui est en principe invalide pour une classe normale) sert de descripteur à la définition d'un module - à une autre époque on aurait choisi un descripteur XML, les temps changent. Le module permet de définir les requirements de notre module (en gros, les dépendances runtime si vous raisonnez comme moi en langage Maven), y compris avec la notion de requirement optionnel et bien sûr cela implique la gestion de la transitivité - espérons que le modèle choisi pour cela sera compatible avec Maven et OSGi, sinon ça promet...
Avec cette possibilité de définir des modules, il devient facile de découper un gros projet en modules et de les référencer dans un module aggrégateur (tout ce vocabulaire me rappelle bizarrement quelque chose).
A l'usage, le compilateur javac proposera une nouvelle option -modulepath permettant d'indiquer les emplacements de nos modules - en gros, notre localRepository :P. La nouvelle commande jpkg permet alors de construire un livrable selon un nouveau format (oubliez vos jars). La commande jmod quand à elle nous apporte l'approvisionnement des modules pour pouvoir lancer la JVM avec un paramètre -mlib indiquant l'emplacement des modules nécessaires à l'exécution. Et comment fait-elle cet approvisionnement ? Avec un dépôt de modules ! Et bien sûr, le repo maven2 est supporté comme source de modules. Qui a dit "standard de fait" ?
Avec ce mécanisme, une application Java va donc pouvoir démarrer avec une version "allégée" de la JVM, typiquement le lancement d'un batch en ligne de commande ou d'un serveur d'application va s'épargner toute la couche graphique AWT et Swing.
Comment tout ça va s'intégrer au JRE ? Un slide nous présente les dépendances entre packages Java, et on a un magnifique effet spaghetti à l'écran, surtout avec l'ajout des API JavaEE par dessus couleur sauce tomate... Après un gros refactoring, la JRE est descendue à un graphe de 25 noeuds et 97 relations, qui devient raisonnablement affichage dans un slide. Ca a du être un sacré boulot :) En terme de compatibilité, cela suppose néanmoins que les applications existantes ne dépendent que des API publiques et pas de leurs détails d'implémentation.
Et OSGi dans tout ça ?
Au moins on écarte pas le débat lors de cette session... Mark Reinhold répond en un exemple : un module A requiert un module B. Avec la modularité Java, A et B peuvent être packagés en paquet debian et résolus à l'installation. De même, Maven gère sans soucis ce cas d'utilisation. Dans le cas d'OSGi, deux bundles peuvent exporter la même API publique sans définir de moyen de résolution privilégié. Le modèle OSGi est donc implicitement plus complexe, focalisé sur un niveau de granularité package, ce qui est souvent un niveau trop fin pour modulariser du code.
Critéria & JavaPosses
Histoire de ne pas me retrouver à nouveau sur les marches, je m'installe dans la salle qui accueillera tout à l'heure l'enregistrement live de JavaPosses pour une session de présentation de l'API Critéria JPA 2.0. Je ne suis pas le seul vu que - pour une fois - la session finit avec une salle deux fois plus remplie qu'à son démarrage.
Rien de fondamental à dire sur cette session Critéria, qui expose clairement le problème des requêtes écrites sous forme de String - donc sans contrôle à la compilation - et l'intérêt du modèle type-safe des Criterias et du méta-modèle JPA 2.0.
Une question tout de même qui retient mon attention : les requêtes par l'exemple sont toujours exclues, et pourtant elles sont si pratiques pour de la recherche multi-critères...
Suit donc l'enregistrement de JavaPosses (les castcodeurs en version US si vous ne connaissez pas). La session commence par une distribution de bières offertes et décorées aux couleurs d'Atlassian, avant de se lancer dans un sondage délirant, mesuré très scientifiquement à l'applaudimètre, et destiné à aider le JCP à orienter l'avenir de Java : quel est notre langage préféré sur la JVM, notre feature favorite pour Java 7, etc... les 4 cow-boys (dont un en duplex des US) mettent l'ambiance.
Un très bon moment, certes sans grande révélation, mais on est pas là que pour apprendre des choses compliquées ou boire de la bière ;)
Rien de fondamental à dire sur cette session Critéria, qui expose clairement le problème des requêtes écrites sous forme de String - donc sans contrôle à la compilation - et l'intérêt du modèle type-safe des Criterias et du méta-modèle JPA 2.0.
Une question tout de même qui retient mon attention : les requêtes par l'exemple sont toujours exclues, et pourtant elles sont si pratiques pour de la recherche multi-critères...
Suit donc l'enregistrement de JavaPosses (les castcodeurs en version US si vous ne connaissez pas). La session commence par une distribution de bières offertes et décorées aux couleurs d'Atlassian, avant de se lancer dans un sondage délirant, mesuré très scientifiquement à l'applaudimètre, et destiné à aider le JCP à orienter l'avenir de Java : quel est notre langage préféré sur la JVM, notre feature favorite pour Java 7, etc... les 4 cow-boys (dont un en duplex des US) mettent l'ambiance.
Un très bon moment, certes sans grande révélation, mais on est pas là que pour apprendre des choses compliquées ou boire de la bière ;)
Getting things done & OpenJDK
Seconde session "méthodologie", une mise en pratique du "Getting Things Done" au métier de programmeur. La promesse d'être efficace et d'améliorer sa productivité et sa focalisation sur son travail, qui dirait non ?
Le début de la présentation est très théorique, en dehors d'une citation de l'excellent EverNote pour la collecte des tâches individuelles et de tous les documents associes. Je finit par quitter la salle a mi-session, pas convaincu d'y apprendre grand chose (NB : j'utilise déjà un kanban personnel). Si ça peut paraître indélicat, c'est une pratique courante dans ces salles gigantesques, et on se rassure en sachant que le speaker a 4 spots en pleine tronche et ne nous voie pas sortir. Il y a deux ans, IBM avait placé des puces RFID sur les badges et mesurait le remplissage des salles. Au final les courbes n'ont pas été diffusées, pour diverses raisons, mai peut être aussi parce qu'elles montraient parfois une désaffection de plus de 30% dans le premier quart d'heure - il ne faudrait pas se mettre mal avec les speakers ;)
J'en profite pour descendre dans le hall et collecter deux trois goodies supplémentaires sur le stand IBM ;)
On enchaine donc avec la session consacrée à OpenJDK.
Petit rappel de l'engagement pris par Oracle à JavaOne concernant sa contribution à OpenJDK, le maintien de la licence open-source, de la distribution gratuite de Oracle JRE et l'accueil fait aux contributeurs. La grosse contribution d'Oracle sera le transfert dans OpenJDK du résultat de la fusion d'HotSpot avec JRockit, ce qui n'était pas forcément évident en terme de positionnement commercial de des deux JVM du portefeuille d'Oracle.
En Octobre, IBM a annoncé rejoindre le projet OpenJDK. Allié de poids, en particulier avec la définition de deux JSR pour clarifier le contenu des JDK 7 et 8. Le JCP reste donc l'entité qui définit Java et pilote son implémentation de référence, dans un fonctionnement communautaire.
En Novembre, Apple rejoint à son tour OpenJDK pour assurer l'avenir de Java sur sa plateforme. En particulier, dans les prochains mois, Apple va proposer une intégration graphique Cocoa native, et non pas son pâle reflet X11 comme le propose Soylatte. Il reste cependant certaines parties du Java6 d'Apple qui ne sont pas "ouvrables"...
Trois poids lourds au chevet du projet, voilà ce qui devrait assurer à la fois la bonne santé d'OpenJDK en terme de ressources de développement et un équilibre en terme d'influence de chaque éditeur : sur 250 développeurs, 60 ne sont pas affiliès à Oracle. La richesse de l'écosystème OpenJDK est présenté au travers d'exemple de contributions externes, issues de RedHat, Google ou du MIT.
On passe quelques instants du côté obscur : comment contribuer, comment builder sa propre version du JDK, comment postuler chez Oracle en tant que contributeur ! Si la commande "make" ne vous fait pas peur et que vous voulez essayer Mercurial, ...
Pour conclure, afin de ne pas se noyer dans les 50 mailing list du projet et ces diverses variantes, l'aggrégateur de blogs PlanetJDK est le meilleur moyen pour se tenir au courant de l'activité du projet.
Le début de la présentation est très théorique, en dehors d'une citation de l'excellent EverNote pour la collecte des tâches individuelles et de tous les documents associes. Je finit par quitter la salle a mi-session, pas convaincu d'y apprendre grand chose (NB : j'utilise déjà un kanban personnel). Si ça peut paraître indélicat, c'est une pratique courante dans ces salles gigantesques, et on se rassure en sachant que le speaker a 4 spots en pleine tronche et ne nous voie pas sortir. Il y a deux ans, IBM avait placé des puces RFID sur les badges et mesurait le remplissage des salles. Au final les courbes n'ont pas été diffusées, pour diverses raisons, mai peut être aussi parce qu'elles montraient parfois une désaffection de plus de 30% dans le premier quart d'heure - il ne faudrait pas se mettre mal avec les speakers ;)
J'en profite pour descendre dans le hall et collecter deux trois goodies supplémentaires sur le stand IBM ;)
On enchaine donc avec la session consacrée à OpenJDK.
Petit rappel de l'engagement pris par Oracle à JavaOne concernant sa contribution à OpenJDK, le maintien de la licence open-source, de la distribution gratuite de Oracle JRE et l'accueil fait aux contributeurs. La grosse contribution d'Oracle sera le transfert dans OpenJDK du résultat de la fusion d'HotSpot avec JRockit, ce qui n'était pas forcément évident en terme de positionnement commercial de des deux JVM du portefeuille d'Oracle.
En Octobre, IBM a annoncé rejoindre le projet OpenJDK. Allié de poids, en particulier avec la définition de deux JSR pour clarifier le contenu des JDK 7 et 8. Le JCP reste donc l'entité qui définit Java et pilote son implémentation de référence, dans un fonctionnement communautaire.
En Novembre, Apple rejoint à son tour OpenJDK pour assurer l'avenir de Java sur sa plateforme. En particulier, dans les prochains mois, Apple va proposer une intégration graphique Cocoa native, et non pas son pâle reflet X11 comme le propose Soylatte. Il reste cependant certaines parties du Java6 d'Apple qui ne sont pas "ouvrables"...
Trois poids lourds au chevet du projet, voilà ce qui devrait assurer à la fois la bonne santé d'OpenJDK en terme de ressources de développement et un équilibre en terme d'influence de chaque éditeur : sur 250 développeurs, 60 ne sont pas affiliès à Oracle. La richesse de l'écosystème OpenJDK est présenté au travers d'exemple de contributions externes, issues de RedHat, Google ou du MIT.
On passe quelques instants du côté obscur : comment contribuer, comment builder sa propre version du JDK, comment postuler chez Oracle en tant que contributeur ! Si la commande "make" ne vous fait pas peur et que vous voulez essayer Mercurial, ...
Pour conclure, afin de ne pas se noyer dans les 50 mailing list du projet et ces diverses variantes, l'aggrégateur de blogs PlanetJDK est le meilleur moyen pour se tenir au courant de l'activité du projet.
Keynote day 2
Après le traditionnel tour des stands à la pêche aux goodies - pas de canard Adobe cette année :'( - je m'y prend un peu plus tôt ce matin pour m'installer dans les confortables fauteuils de la salle 8, qui accueille la keynote. L'immense écran (Devoxx se tient dans un cinéma multiplex) affiche un twitt-wall gigantesque sur lequel nous sommes quelques-un a jouer au social-network sur écran géant :
Stéphan Jansen fait une rapide intervention - et interrompt le jeu des twitts :'( - pour nous annoncer qu'il y a déjà 70 inscrits au channel payant de Devoxx 2010, qui donnera accès dans quelques jours à TOUS les talks de devoxx, alors que les autres devront attendre leur publication au compte goute au cours de l'année, et qui permet de suivre les keynote en streaming direct.
On passe ensuite (enfin ?) à la keynote, consacrée à l'avenir de JavaEE.
Si JavaEE propose un modèle fiable et reconnu, lorsqu'on considère la montée en puissance du Cloud il manque de nombreuses API standardisées pour la gestion propre à ce mode de fonctionnement (stockage distribué à la S3 par exemple). JavaEE doit aussi repenser son modèle de packaging : le déploiement de versions concurrentes d'une même application, l'upgrade de version, le versionning des données associées, sont des éléments indispensables pour une utilisation en mode cluster/cloud, mais encore absents de la norme.
Pour ne pas rester sur de la théorie, on passe maintenant à une démo de ce que propose GlassFish en mode cloud. Pour la petite histoire, la démo est faite sur un MacBook ... sous Ubuntu ! C'est vraiment une conférence de geeks ;) Sur la base d'une image JeOS ("Just Enough OS", un OS réduit et optimisé pour la VM) Glassfish, un cluster virtuel est lancé. Les commandes asadmin proposée par glassfish permettent de lancer et d'administrer un cluster Glassfish en trois commandes sur une IaaS.
Retour sur les slides. JavaEE 7 exploitera la modularité JavaSE 7 (donc, oubliez OSGi pour l'instant). La modularité permet d'identifier les composants redondants et de les partager automatiquement, évitant les doublons et autres conflits dans le classpath.
JSF de son côté va profiter de quelques évolutions dans la version 2.1, mais le plus intéressant viendra avec JSF 2.2 et le support d'HTML 5. JMS va également subir un lifting pour clarifier quelques points et s'ouvrir aux nouvelles tendances expérimentés dans le monde du MOM. La couche Web se met à jour avec le support des web-Sockets, de JSON, de HTML5, et l'utilisation des nouvelles nouvelles I/O (NIO-2) pour le connecteur HTTP (ce qui devrait reléguer le couple Apache-JK au rang d'antiquité).
Linda DeMichiel prend la parole pour faire un focus plus approfondi sur JPA 2.1. Basé sur les demandes de la communautés, une liste de fonctionnalités candidates est présenté :
Globalement, JPA 2.1 cherche donc à consolider sa place de norme largement adoptée en restant à l'écoute du terrain et en intégrant les extension / évolutions réclamées par les utilisateurs. Exemple : l'unwrapping de l'EntityManager pour accéder à l'implémentation sera explicite, permettant d'utiliser quand c'est nécessaire les fonctionnalités propres à Hibernate ou EclipseLink.
On passe enfin à JAX-RS. Exclu du web profile de JavaEE 6, JAX-RS est cependant une norme majeure avec de nombreuses implémentations open-source. Dans les deux années qui nous séparent de JAX-RS 1.0, ces framework ont beaucoup évolué et innové. Il est temps d'intégrer les innovations qui ont fait leur preuve dans la norme : Premature Standardization is Evil ;)
La fonctionnalité la plus attendue et l'API cliente JAX-RS. Jusqu'ici on pouvant écrire des service mais pas les consommes sans partir sur du code propre à une implémentation, c'est donc un complément indispensable. L'intégration avec les autres briques JavaEE avance, avec le support de @Inject et de gros progrès dans l'intégration avec CDI. De nombreux points restent encore en suspens pour une syntaxe légère et non surchargée d'annotations.
La gestion asynchrone, basée sur Atmosphere, est aussi au rendez-vous. L'API de @Broadcast est d'une grande simplicité et masque complètement la complexité de la technologie. Il faudra qu'on fasse une session sur le sujet au BreizhJUG ;)
Stéphan Jansen fait une rapide intervention - et interrompt le jeu des twitts :'( - pour nous annoncer qu'il y a déjà 70 inscrits au channel payant de Devoxx 2010, qui donnera accès dans quelques jours à TOUS les talks de devoxx, alors que les autres devront attendre leur publication au compte goute au cours de l'année, et qui permet de suivre les keynote en streaming direct.
On passe ensuite (enfin ?) à la keynote, consacrée à l'avenir de JavaEE.
Si JavaEE propose un modèle fiable et reconnu, lorsqu'on considère la montée en puissance du Cloud il manque de nombreuses API standardisées pour la gestion propre à ce mode de fonctionnement (stockage distribué à la S3 par exemple). JavaEE doit aussi repenser son modèle de packaging : le déploiement de versions concurrentes d'une même application, l'upgrade de version, le versionning des données associées, sont des éléments indispensables pour une utilisation en mode cluster/cloud, mais encore absents de la norme.
Pour ne pas rester sur de la théorie, on passe maintenant à une démo de ce que propose GlassFish en mode cloud. Pour la petite histoire, la démo est faite sur un MacBook ... sous Ubuntu ! C'est vraiment une conférence de geeks ;) Sur la base d'une image JeOS ("Just Enough OS", un OS réduit et optimisé pour la VM) Glassfish, un cluster virtuel est lancé. Les commandes asadmin proposée par glassfish permettent de lancer et d'administrer un cluster Glassfish en trois commandes sur une IaaS.
Retour sur les slides. JavaEE 7 exploitera la modularité JavaSE 7 (donc, oubliez OSGi pour l'instant). La modularité permet d'identifier les composants redondants et de les partager automatiquement, évitant les doublons et autres conflits dans le classpath.
JSF de son côté va profiter de quelques évolutions dans la version 2.1, mais le plus intéressant viendra avec JSF 2.2 et le support d'HTML 5. JMS va également subir un lifting pour clarifier quelques points et s'ouvrir aux nouvelles tendances expérimentés dans le monde du MOM. La couche Web se met à jour avec le support des web-Sockets, de JSON, de HTML5, et l'utilisation des nouvelles nouvelles I/O (NIO-2) pour le connecteur HTTP (ce qui devrait reléguer le couple Apache-JK au rang d'antiquité).
Linda DeMichiel prend la parole pour faire un focus plus approfondi sur JPA 2.1. Basé sur les demandes de la communautés, une liste de fonctionnalités candidates est présenté :
- les types custom
- les fetch plans
- de nouvelles méta-données de mapping
- des stratégies de nommage définies par l'utilisateur
- plus de flexibilité sur les valeurs générées (et pas seulement les clés)
- la gestion des attributs immuable (readonly)
- plus de flexibilité dans le descripteur XML
Globalement, JPA 2.1 cherche donc à consolider sa place de norme largement adoptée en restant à l'écoute du terrain et en intégrant les extension / évolutions réclamées par les utilisateurs. Exemple : l'unwrapping de l'EntityManager pour accéder à l'implémentation sera explicite, permettant d'utiliser quand c'est nécessaire les fonctionnalités propres à Hibernate ou EclipseLink.
On passe enfin à JAX-RS. Exclu du web profile de JavaEE 6, JAX-RS est cependant une norme majeure avec de nombreuses implémentations open-source. Dans les deux années qui nous séparent de JAX-RS 1.0, ces framework ont beaucoup évolué et innové. Il est temps d'intégrer les innovations qui ont fait leur preuve dans la norme : Premature Standardization is Evil ;)
La fonctionnalité la plus attendue et l'API cliente JAX-RS. Jusqu'ici on pouvant écrire des service mais pas les consommes sans partir sur du code propre à une implémentation, c'est donc un complément indispensable. L'intégration avec les autres briques JavaEE avance, avec le support de @Inject et de gros progrès dans l'intégration avec CDI. De nombreux points restent encore en suspens pour une syntaxe légère et non surchargée d'annotations.
La gestion asynchrone, basée sur Atmosphere, est aussi au rendez-vous. L'API de @Broadcast est d'une grande simplicité et masque complètement la complexité de la technologie. Il faudra qu'on fasse une session sur le sujet au BreizhJUG ;)
17 novembre 2010
Devoxx, quand y'en a plus, y'en a encore
D'une part il y a la soirée frite + bière, avec un petit bonus sur chaque stand. JBoss offre de la bière (des fois que les 10 bombones ne suffiraient pas), Oracle fait son super-tirage (j'ai gagné un stylo qui clignote, cool), IBM sort le champagne. Au final on est donc bien frais.
Ensuite il y a "officiellement" les BOF (Birds Of a Feather flock together) de 19h à 23h, permettant à chaque communauté de se rencontrer "In Real Life". BOF Jug-leaders demain, BOF Parleys ce soir, BOF JavaFx, BOF Scala, etc.
A côté il y a les BOF non-officiels, comme le rencard Play! suivi du rencard JUG au resto mexicain d'à côté (le seul resto du coin en fait, en dehors du MacDo)
Et si ça ne suffit pas il y a les plans tribus, comme le repas opensource dieux sait ou dans un resto en centre ville (les infos circulent sur twitter : voir le twittwal).
Inutile de dire qu'une semaine de Devoxx, ça calme ...
Performance Anxiety
Joshua Bloch fait salle ultra-comble, comme Brian Goetz il y a une heure que je n'ai pas pu suivre. Les allées et les escaliers sont pris d'assaut, le couloir reste encombré, n'imaginez même pas accéder à la salle (je ne suis pas complètement sur que ce soit conforme aux règles de sécurité pour la salle d'ailleurs). Dur pour les speakers qui sont programmés au même moment dans l'une des 5 autres salles. Sujet du jour - les performances :D
En attendant que la conf démarre (parce qu'il ne suffit pas d'arriver 10 minutes à l'avance, je suis assis sur les marches et je ne suis pas le moins bien lotti) un détail sur Devoxx pour ceux qui voudraient venir l'an prochain : Devoxx c'est 3000 personnes et beaucoup de français. On peut donc y rencontrer plein de gens biens, en plus d'assister à des confs passionnantes, à condition de bien gérer son emploi du temps. L'effet de bord c'est qu'on se retrouve convié à des BOF le soir et/ou à des repas de JUG-leaders, Opensource-man, Truc-community. Ce soir je vais devoir me cloner ;)
Joshua est sur les starting blocs et commence avant l'enregistrement, ils faut donc l'arrêter déjà lancé dans son discours - comme quoi les problèmes de performance ne sont pas limités à l'informatique :P Bon, ça suffit pour les crétineries, soyons sérieux deux minutes.
Parlons donc performances et optimisation, avec un disclaimer "Premature Optimization is Evil" ...
Avec l'augmentation de l'abstraction et la programmation devenue une discipline empirique, on ne peut plus que mesurer les performance et plus les estimer. librairies, langage, VM ou processeurs sont de plus en plus complexes et abstrait, et introduisent une dimension d'imprévisibilité dans nos estimations de performance. Que ceux qui peuvent dire qui d'un AND conditionnel (&&) et d'un AND logique (&) est le plus rapide lèvent la main ;) La prédiction de branchement dans nos processeurs fausse notre interprétation naïve du problème. La réponse est ... ça dépend !
La performance de lecture d'un attribut dans un objet ? ça dépend ! Est-il volatile ? Sur quel processeur ? Est-il un attribut d'une classe imbriquée - dans ce cas, c'est un appel de méthode, sauf si le compilo l'à inliné. Ca dépend, il faut mesurer !
Un bench simpliste montre déjà l'effet du premier lancement par rapport à la répétition : le warm-up de la JVM et la stabilisation de ses optimisations. Pas de grosse surprise jusqu'ici. Cependant, après plusieurs tirs (même si Joshua n'arrive pas de le montrer sur sa démo) les résultats peuvent être très différents sur un autre tir. Il est donc très difficile de comparer des résultats, et donc de voir les effets de changements dans le code.
La complexité de notre stack matérielle et logicielle nous oblige à renoncer à la prédictibilité. Rien qu'en analysant les possibilités d'inlining que la VM peut appliquer à un fragment de code simpliste, la combinatoire donne des résultats très variables. Or le "Compilation Planing" de la JVM Just-In-Time est un processus en tâche de fond, non-déterministe lors de notre mesure :'( Les mêmes dérives sont constatées sur du code C/C++ (la VM n'explique donc pas tout) ni même sur du code assembleur. L'outillage (comme un profiler) peut d'ailleurs fausser la mesure au point d'invalider toute l'analyse : 6 profilers testés sur un même code on détecté des "hot-spots" différents :'(
Notre seule solution : une approche statistique ! En multipliant les runs, en groupant les données et en effectuant une analyse statistique on obtient une meilleure vision de nos performances, et la moyenne n'est pas le seul résultat à retenir : l'étalement des mesures peut être impressionnant.
En tant que développeur d'application nous ne pouvons donc que reposer sur des constructions validées et stables en conservant un niveau d'abstraction maximal. En tant que développeur de librairie, nous devons étudier soigneusement les recommandations des spécialistes pour éviter les constructions hasardeuses (classes imbriquées de visibilité private par exemple) qui ajoutent du flou dans le traitement du compilateur, et donc dégradent d'autant la prédictibilité. Comment les connaître ? Demandez à Doug Lea - ou achetez son livre ;)
L'art du benchmark est très délicat, largement détaillé par Cliff Click (JavaOne 2009). Caliper est un framework qui peut aider à en construire avec un bon niveau de fiabilité. Quoi qu'il en soit, Joshua conclut que nous vivons une époque passionnante dans laquelle le prédictif se perd et où nous devons apprendre à mesurer notre travail avec de nombreuses précautions.
En attendant que la conf démarre (parce qu'il ne suffit pas d'arriver 10 minutes à l'avance, je suis assis sur les marches et je ne suis pas le moins bien lotti) un détail sur Devoxx pour ceux qui voudraient venir l'an prochain : Devoxx c'est 3000 personnes et beaucoup de français. On peut donc y rencontrer plein de gens biens, en plus d'assister à des confs passionnantes, à condition de bien gérer son emploi du temps. L'effet de bord c'est qu'on se retrouve convié à des BOF le soir et/ou à des repas de JUG-leaders, Opensource-man, Truc-community. Ce soir je vais devoir me cloner ;)
Joshua est sur les starting blocs et commence avant l'enregistrement, ils faut donc l'arrêter déjà lancé dans son discours - comme quoi les problèmes de performance ne sont pas limités à l'informatique :P Bon, ça suffit pour les crétineries, soyons sérieux deux minutes.
Parlons donc performances et optimisation, avec un disclaimer "Premature Optimization is Evil" ...
Avec l'augmentation de l'abstraction et la programmation devenue une discipline empirique, on ne peut plus que mesurer les performance et plus les estimer. librairies, langage, VM ou processeurs sont de plus en plus complexes et abstrait, et introduisent une dimension d'imprévisibilité dans nos estimations de performance. Que ceux qui peuvent dire qui d'un AND conditionnel (&&) et d'un AND logique (&) est le plus rapide lèvent la main ;) La prédiction de branchement dans nos processeurs fausse notre interprétation naïve du problème. La réponse est ... ça dépend !
La performance de lecture d'un attribut dans un objet ? ça dépend ! Est-il volatile ? Sur quel processeur ? Est-il un attribut d'une classe imbriquée - dans ce cas, c'est un appel de méthode, sauf si le compilo l'à inliné. Ca dépend, il faut mesurer !
Un bench simpliste montre déjà l'effet du premier lancement par rapport à la répétition : le warm-up de la JVM et la stabilisation de ses optimisations. Pas de grosse surprise jusqu'ici. Cependant, après plusieurs tirs (même si Joshua n'arrive pas de le montrer sur sa démo) les résultats peuvent être très différents sur un autre tir. Il est donc très difficile de comparer des résultats, et donc de voir les effets de changements dans le code.
La complexité de notre stack matérielle et logicielle nous oblige à renoncer à la prédictibilité. Rien qu'en analysant les possibilités d'inlining que la VM peut appliquer à un fragment de code simpliste, la combinatoire donne des résultats très variables. Or le "Compilation Planing" de la JVM Just-In-Time est un processus en tâche de fond, non-déterministe lors de notre mesure :'( Les mêmes dérives sont constatées sur du code C/C++ (la VM n'explique donc pas tout) ni même sur du code assembleur. L'outillage (comme un profiler) peut d'ailleurs fausser la mesure au point d'invalider toute l'analyse : 6 profilers testés sur un même code on détecté des "hot-spots" différents :'(
Notre seule solution : une approche statistique ! En multipliant les runs, en groupant les données et en effectuant une analyse statistique on obtient une meilleure vision de nos performances, et la moyenne n'est pas le seul résultat à retenir : l'étalement des mesures peut être impressionnant.
En tant que développeur d'application nous ne pouvons donc que reposer sur des constructions validées et stables en conservant un niveau d'abstraction maximal. En tant que développeur de librairie, nous devons étudier soigneusement les recommandations des spécialistes pour éviter les constructions hasardeuses (classes imbriquées de visibilité private par exemple) qui ajoutent du flou dans le traitement du compilateur, et donc dégradent d'autant la prédictibilité. Comment les connaître ? Demandez à Doug Lea - ou achetez son livre ;)
L'art du benchmark est très délicat, largement détaillé par Cliff Click (JavaOne 2009). Caliper est un framework qui peut aider à en construire avec un bon niveau de fiabilité. Quoi qu'il en soit, Joshua conclut que nous vivons une époque passionnante dans laquelle le prédictif se perd et où nous devons apprendre à mesurer notre travail avec de nombreuses précautions.
Cassandra
NoSQL est à l'honneur de cette édition de Devoxx, avec des speakers de Facebook, Twitter ou LinkedIn. Cassandra, projet Apache opensourcé par FaceBook, basé sur les travaux de Google BigTalbe et Amazon Dynamo, est présenté au cours d'une de ces sessions.
Retour en arrière sur les documents d'architecture d'eBay et l'approche BASE, qui prend le contrepied de l'ACID qui sous-tend nos bases de données relationnelles. En considérant la base de donnée comme un flux de données et non comme un ensemble synchronisé à coup de verrous pessimistes, une nouvelle architecture se profile.
Cassandra utilise des tables en mémoire qui sont flushées sur disque de manière asynchrone. Ce découplage avec les I/O donne à la base un avantage qui booste ses performances, le risque étant compensé par une gestion de version des données via un commit log. Contrairement au mythe, la scalabilité de la base ne concerne pas exclusivement les énormes sites de réseaux sociaux. De la même manière, l'abandon de l'ACID ne signifie pas que les données stockées ne peuvent pas être stratégiques : la gestion de version assure qu'aucune donnée n'est perdue. L'argument type pour justifier un stockage NoSQL est de considérer les applications qui ajoutent un cache distribué au dessus de leur accès base. Le résultat est équivalent sans avoir la puissance d'une base NoSQL.
Une fois cette nouvelle logique acceptée, Cassandra apporte une souplesse sans précédent en terme de scalabilité, de réplication, d'absence d'un "single point of failure". Voilà qui chamboule fondamentalement notre point de vue sur les bases de données et leur administration : la réplication naturelle des noeuds assure une fiabilité et une re-synchronisation des données sans opération d'administration dédiée.
Le format de données utilisé par Cassandra, comme pour Google BigTable, est une série de clé:valeur libres associée à un ID (ColumnFamily). Ce formalisme particulier, très différent du SQL traditionnel, change la donne au problème du dimensionnement et de l'indexation. twissandra (démo ici) sert de base aux démos et explication sur la structure et la manipulation très particulière de ces données. Le modèle simple et connu de tous de twitter et la comparaison avec l'équivalent SQL en font un exemple concret et très parlant. Les requêtes en base ne se basent plus sur des approches ensemblistes mais sur des parcours "sliceQuery" des entrées d'une "table".
La manipulation des données de Cassandra peut monter d'un niveau d'abstraction, avec des frameworks comparables à notre pile Driver / JDBC / JPA. Un portage de Lucene (Lucandra) permet par exemple pour apporter la recherche à notre base NoSQL.
Retour en arrière sur les documents d'architecture d'eBay et l'approche BASE, qui prend le contrepied de l'ACID qui sous-tend nos bases de données relationnelles. En considérant la base de donnée comme un flux de données et non comme un ensemble synchronisé à coup de verrous pessimistes, une nouvelle architecture se profile.
Cassandra utilise des tables en mémoire qui sont flushées sur disque de manière asynchrone. Ce découplage avec les I/O donne à la base un avantage qui booste ses performances, le risque étant compensé par une gestion de version des données via un commit log. Contrairement au mythe, la scalabilité de la base ne concerne pas exclusivement les énormes sites de réseaux sociaux. De la même manière, l'abandon de l'ACID ne signifie pas que les données stockées ne peuvent pas être stratégiques : la gestion de version assure qu'aucune donnée n'est perdue. L'argument type pour justifier un stockage NoSQL est de considérer les applications qui ajoutent un cache distribué au dessus de leur accès base. Le résultat est équivalent sans avoir la puissance d'une base NoSQL.
Une fois cette nouvelle logique acceptée, Cassandra apporte une souplesse sans précédent en terme de scalabilité, de réplication, d'absence d'un "single point of failure". Voilà qui chamboule fondamentalement notre point de vue sur les bases de données et leur administration : la réplication naturelle des noeuds assure une fiabilité et une re-synchronisation des données sans opération d'administration dédiée.
Le format de données utilisé par Cassandra, comme pour Google BigTable, est une série de clé:valeur libres associée à un ID (ColumnFamily). Ce formalisme particulier, très différent du SQL traditionnel, change la donne au problème du dimensionnement et de l'indexation. twissandra (démo ici) sert de base aux démos et explication sur la structure et la manipulation très particulière de ces données. Le modèle simple et connu de tous de twitter et la comparaison avec l'équivalent SQL en font un exemple concret et très parlant. Les requêtes en base ne se basent plus sur des approches ensemblistes mais sur des parcours "sliceQuery" des entrées d'une "table".
La manipulation des données de Cassandra peut monter d'un niveau d'abstraction, avec des frameworks comparables à notre pile Driver / JDBC / JPA. Un portage de Lucene (Lucandra) permet par exemple pour apporter la recherche à notre base NoSQL.
Next Big Java Language
Qu'y aura t-il après Java ? Il ne s'agit pas de trouver ici le prochain langage de geek, mais celui qui accompagnera les millions de développeurs "collet bleu" qui ne vont pas aux conférences, ne bénéficient pas de formation avancées.
Partant de ce que 15 années de Java nous a appris, XX établit une liste de constats.
D'où quelques critères - le prochain "gros" langage de la JVM devra :
Que donnent les langages alternatifs actuels au travers de ce prisme ?
Groovy est un assez bon candidat, mais son aspect dynamique le rend trop souple et mal adapté pour remplacer Java. Par contre il en est un excellent complément.
Scala est trop puriste du fonctionnel, trop strict, trop élitiste, trop différent de l'historique C/Java
Fantom a un bon potentiel, mais ne propose pas un modèle de typage suffisant. L'absence de génériques (en dehors des listes et maps) est un recul inacceptable.
Alors ? La solution pourrait être un Java ... sans compatibilité ascendante. On prend Java et on en retire tout ce qu'on sait aujourd'hui ne pas être un bon choix. L'outillage peut assurer la conversion du legacy si besoin. Peut être pour Java 9 ... à suivre sur twitter via #bijava !
Partant de ce que 15 années de Java nous a appris, XX établit une liste de constats.
- les exceptions"checked" compliquent le code plus qu'elles nous aident
- le fait que les primitifs et les tableaux ne soient pas des objet complique le langage (mais améliorent les perfs), en particulier avec la surcharge des méthodes : foo( (short) 2) appel t-il foo( Integer ), foo( int ) ou foo( Object ) ?
- les génériques de Java, avec leurs "super" et "extends" sont un nid de confusion
D'où quelques critères - le prochain "gros" langage de la JVM devra :
- avoir une syntaxe C-like pour s'apprendre facilement - considérant la base installée de développeurs
- être orienté-objet ET fonctionnel, non puriste d'un de ces deux paradigmes
- typé statiquement, mais sans la rigueur excessive de Java, en particulier pour la réflexion. Invoquer dynamiquement une méthode devrait être trivial
- intégrer nativement les patterns que nous employons couramment et qui alourdissent le code : JavaBeans vs Propriétés, gestion du Null, Concurrence et Threads, Modules et visibilité, etc
- être adapté pour l'outillage, IDE, debuggers et profilers. L'IDE ne peut pas tout deviner tout seul, le langage peut l'aider dans son travail
- Etre raisonnablement ouvert aux extensions
Que donnent les langages alternatifs actuels au travers de ce prisme ?
Groovy est un assez bon candidat, mais son aspect dynamique le rend trop souple et mal adapté pour remplacer Java. Par contre il en est un excellent complément.
Scala est trop puriste du fonctionnel, trop strict, trop élitiste, trop différent de l'historique C/Java
Fantom a un bon potentiel, mais ne propose pas un modèle de typage suffisant. L'absence de génériques (en dehors des listes et maps) est un recul inacceptable.
Alors ? La solution pourrait être un Java ... sans compatibilité ascendante. On prend Java et on en retire tout ce qu'on sait aujourd'hui ne pas être un bon choix. L'outillage peut assurer la conversion du legacy si besoin. Peut être pour Java 9 ... à suivre sur twitter via #bijava !
Dev/Ops, mais sans le "/"
Devoxx propose toujours des sessions plus "méthodologie" avec une mise en avant de l'agilité. Cette session se consacre au mouvement DevOps, sur fond de licornes, de vampires et de loup-garous - illustration inhabituelle mais bien menée.
Le constat est simple : nous, développeurs, ne sommes pas sensibles au problématiques de opérationnels, qui n'ont aucune considération pour nos choix organisationnels. L'agilité de nos développement ne peut-elle pas être transposée au monde de l'opérationnel ?
L'idée des DevOps est d'intégrer les opérationnels à l'équipe, comme nous l'avons fait des testeurs. Déployer, c'est compliqué, ça marche parfois mal. Donc déployons souvent, avec un maximum d'automatisation. Déployons sur des plateforme de développement et de test iso-production, et toujours avec le même outillage. Gérons en configuration tous nos environnements.
Ce discours rejoint "Continuous Delivery" que je lis en ce moment, livre passionnant qui pousse de nombreuses idées très novatrices (au moins pour moi). On retrouve les concept du "Stop the line", de la tolérance 0 au défauts, de la gestion de la dette technique, etc.
Si organisationnellement les choses doivent être bien moins simples que sur les slides (un peu comme Scrum qui nous dit qu'il n'y a qu'un seul Product Owner, sans dire comment on en arrive là), c'est un mouvement à suivre de près et dont sortirons certaines des pratiques de développement de la prochaine décennie (enfin, d'après ma petite Mme Irma de poche).
Le constat est simple : nous, développeurs, ne sommes pas sensibles au problématiques de opérationnels, qui n'ont aucune considération pour nos choix organisationnels. L'agilité de nos développement ne peut-elle pas être transposée au monde de l'opérationnel ?
L'idée des DevOps est d'intégrer les opérationnels à l'équipe, comme nous l'avons fait des testeurs. Déployer, c'est compliqué, ça marche parfois mal. Donc déployons souvent, avec un maximum d'automatisation. Déployons sur des plateforme de développement et de test iso-production, et toujours avec le même outillage. Gérons en configuration tous nos environnements.
Ce discours rejoint "Continuous Delivery" que je lis en ce moment, livre passionnant qui pousse de nombreuses idées très novatrices (au moins pour moi). On retrouve les concept du "Stop the line", de la tolérance 0 au défauts, de la gestion de la dette technique, etc.
Si organisationnellement les choses doivent être bien moins simples que sur les slides (un peu comme Scrum qui nous dit qu'il n'y a qu'un seul Product Owner, sans dire comment on en arrive là), c'est un mouvement à suivre de près et dont sortirons certaines des pratiques de développement de la prochaine décennie (enfin, d'après ma petite Mme Irma de poche).
The State of the Web
"The State of the Web" seconde partie de la keynote de ce mercredi, présentée par Dion Almaer et Ben Galbraith est rodée de longue date. Si le sujet a déjà été présenté, le contenu reste d'actualité.
Qu'est ce qui fait le succès d'une application ? Partant du constat que les applications actuelles sont consommées comme le contenu multimédia, avec un "hit" au lancement, un effet de masse, etc, les rouages du succès sont décortiqués. Trois piliers fondamentaux :
Les applications web souffrent de ce point de vue.
Toutes les briques ne sont pas en place, mais le web et la norme HTML 5 promettent un écosystème applicatif sans précédent en terme de diffusion.
Qu'est ce qui fait le succès d'une application ? Partant du constat que les applications actuelles sont consommées comme le contenu multimédia, avec un "hit" au lancement, un effet de masse, etc, les rouages du succès sont décortiqués. Trois piliers fondamentaux :
- une plateforme largement distribuée.
- un marchandising soigné pour accueillir le consommateur
- une capacité adaptée de la plateforme
Les applications web souffrent de ce point de vue.
- La plateforme est très largement distribuée mais pas du tout homogène, ce qui est un prérequis (avec quelques citations à l'appui de grosses réussites commerciales comme Microsoft ou Apple). Une norme réellement supportée est nécessaire.
- Le marchanising s'appelle de nos jour un "AppStore". Google ou Mozilla explorent cette piste mais il n'y a pas encore d'équivalent aussi incontournable que l'AppleStore pour le web
- Les capacités de la plateforme web sont largement sous-évaluées. Habitués aux limites d'IE6 les applis "web" sont un pâle reflet de leur équivalent iPhone; pourtant la même ergonomie est techniquement possible. Chrome Frame est la contribution de Google pour ne pas devoir attendre 10 ans la migration massive vers IE 9.
Toutes les briques ne sont pas en place, mais le web et la norme HTML 5 promettent un écosystème applicatif sans précédent en terme de diffusion.
Devoxx Keynote
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.
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.
16 novembre 2010
rendez-vous à Antwerppen
Je pars cet après-midi pour Anvers, pour rejoindre mes petits camarades sur Devoxx.
On ne présente plus Devoxx, ex-JavaPolis, LA conférence européenne autour des technologies Java qui s'étale sur 5 jours dans 6 salles de 800 places, bref la grosse artillerie.
Devoxx c'est une journée chargée en conférences de très haut niveau, un concentré de toutes les formations que j'aurais pu demander au cours de l'année
Devoxx c'est des échanges nombreux, en particulier lors des BOF qui permettent à une communauté de se rencontrer "In Real Life" et de faire le point
Devoxx c'est aussi de l'ambiance, après tout on est en Belgique et les bars à bière ne manquent pas
Devoxx c'est encore les Quickies, ou comment présenter en 1/4 heure un outil sympa devant un public qu'on aurait jamais pu espérer
Devoxx c'est aussi les universités, auxquelles je n'ai pas participé cette année, mais qui sont un bon complément aux trois journées de conférence
Devoxx c'est aussi le stand Pearson, soit la meilleure librairie spécialisée d'Anvers ;) Pour l'occasion, mon bouquin sera proposée pour une séance dédicace mercredi 17, à 13h30, en compagnie d'Arnaud. Double dédicace, on croirait du VanDamme, mais ça fera de ces bouquins des exemplaires uniques.
Au plaisir de vous croiser si vous êtes sur place, dommage pour tous les autres ;)
On ne présente plus Devoxx, ex-JavaPolis, LA conférence européenne autour des technologies Java qui s'étale sur 5 jours dans 6 salles de 800 places, bref la grosse artillerie.
Devoxx c'est une journée chargée en conférences de très haut niveau, un concentré de toutes les formations que j'aurais pu demander au cours de l'année
Devoxx c'est des échanges nombreux, en particulier lors des BOF qui permettent à une communauté de se rencontrer "In Real Life" et de faire le point
Devoxx c'est aussi de l'ambiance, après tout on est en Belgique et les bars à bière ne manquent pas
Devoxx c'est encore les Quickies, ou comment présenter en 1/4 heure un outil sympa devant un public qu'on aurait jamais pu espérer
Devoxx c'est aussi les universités, auxquelles je n'ai pas participé cette année, mais qui sont un bon complément aux trois journées de conférence
Devoxx c'est aussi le stand Pearson, soit la meilleure librairie spécialisée d'Anvers ;) Pour l'occasion, mon bouquin sera proposée pour une séance dédicace mercredi 17, à 13h30, en compagnie d'Arnaud. Double dédicace, on croirait du VanDamme, mais ça fera de ces bouquins des exemplaires uniques.
Au plaisir de vous croiser si vous êtes sur place, dommage pour tous les autres ;)
Inscription à :
Articles (Atom)
