Troisième et dernier jour du symposium…je n’ai pas
gagné l’iPod qui était en jeu, dommage, j’aurais pu tester GWT dessus ;)
On commence par une conférence de Geert Bevin: Boldly go where the
Java language has never gone before. On le sait, Java ce n’est pas
qu’un langage, c’est un langage, une JVM et une plateforme, qui ont chacun
leurs points forts mais aussi leurs limites. Dès lors, l’idée, qui est à la
mode ces derniers temps, c’est que l’on peut remplacer ou modifier un de ces
composants pour “pousser l’enveloppe” lorsque les limites se font sentir.
Geert cite 4 exemples pour illustrer cette approche.
- Terracotta: il s’agit d’une extension de la JVM qui
facilite la scalabilité des applications, en permettant de mettre des JVM en
cluster. Déclarativement, certains objets (“shared objects”) sont répliqués
entre toutes les JVM, et accédés indifféremment (avec du lazy loading) par
toutes les instances. On a ainsi étendu le comportement natif de la JVM.
- RIFE continuations: déjà évoqué hier au sujet de Comet, il
s’agit pour prendre une image de prendre une photo de l’état d’un thread, comme
un “save game” (c’est l’image donnée par Geert). On peut à tout moment appeler
pause(), ce qui crée une sauvegarde et rend la main immédiatement, puis
reprendre à partir de n’importe quel état avec resume(). Les continuations sont
organisées en arbre (parent = continuation à partir de laquelle on a restauré).
Encore une fois, on change la sémantique habituelle de la JVM dans sa gestion
des threads.
- GWT: on ne présente plus GWT, Geert fait un rappel des
principes de fonctionnement (translation Java->Javascript, mode hosted vs.
compilé, debugging, etc.). Ici on a remplacé l’ensemble du stack Java
par une plateforme web pure, et seul le développement utilise le stack
Java standard. Un participant pose la question du JavaScript généré, et Geert
dit que pour lui c’est un problème, car le JavaScript généré est illisible et
impossible à débugger… je bondis intérieurement, et j’irai voir Geert à la fin
pour lui expliquer que pour GWT, le browser est la plateforme, la
lisibilité du JavaScript généré est aussi peu importante que la lisibilité du
bytecode généré par le compilateur Java! Je ne pouvais pas laisser passer
ça…
- Android: la plateforme mobile de Google. Comme pour GWT,
le développement et debugging se font en Java, avec les IDEs habituels, et un
émulateur de la plateforme mobile (équivalent au mode hosted de GWT). En
revanche pour le déploiement, le bytecode Java est converti en bytecode (.dex)
pour la machine virtuelle Dalvik, qui est l’équivalent de la JVM.
On aurait pu multiplier les exemples, notamment les langages dynamiques qui
fleurissent sur la JVM, mais le point est fait. A mon sens, ces multiples
extensions et détournements sont plus des preuves de la puissance de Java que
de sa faiblesse, car Java reste toujours au centre d’un écosystème qui est plus
bouillonnant que jamais.
Deuxième conf: JCR: TheServerSide as a Content Application.
David Neuscheler (days.com) introduit JCR, version 1.0 (JSR 170) et 2.0 (JSR
283), les diférentes fonctionnalités d’un système de CM, etc. Puis il fait une
démo en prenant une page du site TheServerSide.com, et en la transformant en
appli client JCR. Pour tout dire c’est un peu fastidieux, et d’où je suis on
n'arrive pas à lire le code ! J'aurais peut-être dû choisir la conf sur
MapReduce dans l'autre salle...
Dernière conf du matin, Michael Keith présente What's new in JPA
2.0. Les objectifs étaient multiples:
- standardiser les propriétés
- remplir les manques de l'ORM
- rendre la modélisation objet plus flexible
- fournir une abstraction du contrôle du cache
- contrôle du verrouillage (locking)
- fournir des "hooks" pour des frameworks propriétaires
- améliorations JPQL
- etc.
Je ne vais pas détailler les nouveautés, mais globalement il semble que le
groupe de travail JPA a bien écouté les utilisateurs, et lorsque JPA 2.0 sera
sorti, il sera difficile de justifier l'utilisation directe d'une API de
persistence propriétaire.Au passage, la présentation a été agrémentée d'une
page culturelle sur les oies du Canada...
Comme hier et avant-hier, déjeuner avec un lance-pierres... et en plus ils
ont enlevé les machines à café !
L'après-midi commence avec Choosing a Web framework, par
Shashank Tiwari. En fait de conseils pratiques, il s'agit d'une énumération de
définitions, de généralités, de questions (quel problème résout un framework,
quel problème crée-t-il?), tout ça pour finir par dire que toutes les raisons
sont bonnes de choisir un framework, y compris parce qu'il est à la mode ou
pour faire bien sur son CV !!! Au final si on est en recherche d'un framework,
cette conférence ne fait qu'ajouter à la confusion et à l'incertitude. Ou
comment gâcher un bon sujet.
Case Study: Better Software with the Spring portfolio, par
Eberhard Wolff (SpringSource Allemagne). Pour info, SpringSource est la société
qui emploie tous les committers de Spring, mais aussi certains de
Tomcat et Apache. Spring, outre le framework bien connu, c'est aussi dynamic
modules, batch, integration, webflow, etc.
On nous propose un cas de système de traitement de commande à architecturer
autour de Spring. Le système peut recevoir des commandes par Web Services. La
démarche classique est de définir une interface Java, implémentée par un POJO,
et de générer le WSDL à partir de cette interface. Or cette démarche présente
des inconvénients: le WSDL expose de facto l'interface d'une classe
interne.. que se passe-t-il si le WSDL doit changer? D'autre part certains
types communs en Java, comme Map, ne sont pas supportés en WSDL...Eberhard
propose d'inverser la démarche: puisque le contrat avec les clients est le
WSDL, on part du WSDL et on base le traitement d'une commande sur le schéma XML
correspondant. Ansi on n'expose pas d'interface interne, on traite un objet
Java généré à partir du message envoyé, via un système de mapping
(JAXB/XStream). La logique est découplée de l'interface. La classe qui traite
le message est un Endpoint qui est annoté via les annotations Spring.
Eberhard en profite pour rappeler que Spring est trop souvent assimilé à XML,
mais qu'on peut très bien faire du Spring sans XML (ou presque, soyons
honnête..)
Pour rendre robuste le WebService, on peut aussi baser le traitement du
message sur des expressions XPath. Ceci permet d'avoir un contrôle plus fin sur
des messages qui seraient incomplets, et donc ne pourraient pas être mappés
avec la solution précédente.
Eberhard introduit également les notions de pipes et filtres, qui sont des
pipelines de traitement, supportés par Spring Integration, et configurables par
XML (tiens donc).
Spring fournit également une approche à la notion de batch, mal résolue en
Java; notamment le problème des redémarrages en cas d'interruption volontaire
ou non. Un batch Spring c'est une série d'étapes, chaque étape lit quelque
chose (un record dans une base probablement) et écrit quelque chose (résultat
du traitement). Cette notion est supportée par Spring batch.
Dernière conf de la journée, et du symposium: Real GWT
applications, par Jeff Dwyer. Une énième présentation rapide des
principes de GWT, et une petite démo sur le site tocollege.net, dont une partie
est réalisée en GWT. Jeff fait une petite séance rapide de live coding, et
montre le débugging en mode hosted. Puis il insiste, un peu trop peut-être, sur
les problèmes pour envoyer des objets métier au client provenant d'hibernate:
les proxies dynamiques cassent le mécanisme de sérialisation GWT. Il existe des
solutions: Hibernate4GWT et GWTHibernateFilter. Je lui ferai remarquer à la fin
que ce n'est pas forcément la meilleure idée, et qu'avec Dozer il est facile de
populer des objets spécialisés pour les transmette au client, car je n'ai pas
forcément envie de voir mes objets métier transiter sur le fil, on ne sait
jamais ce qui peut s'y trouver demain...
Jeff conseille judicieusement d'utiliser un pattern Command pour les
communications du client. Il aborde la sécurité, notamment les attaques XSRF,
et présente Goggle Gears pour les applis offline.
La présentation était un peu rapide, mais l'intérêt pour la techno est
évident. J'espère que cette présentation (qui a été donnée deux fois lors du
symposium suite à la forte demande !) y aura contribué.
Ouf, le marathon est fini ! Beaucoup de choses passionnantes ont été
présentées, et on sent qu'on est à un tournant car pour ainsi dire "ça part
dans tous les sens", l'écosystème Java, aux frontières autrefois bien nettes,
commence à devenir une galaxie en expansion avec des projets qui poussent
l'enveloppe et repoussent sans arrêt les limites, des polémiques (et encore, on
n'a pas abordé les closures !). Le monde Java de demain sera certainement bien
différent de celui d'aujourd'hui, mais Java en restera probablement le centre
de gravité...
Il me reste à visiter Prague (superbe ville) et regarder les Turcs se
qualifier sur l'écran géant au centre ville...
