By Olivier Gérardin
For those of you not familiar with the Who’s Who of IT, Tim Bray is best known for the central role he played in the initial specification of XML. I should know because I spent countless hours studying it back in 2000. If you really really have to read it too, I urge you to read instead the annotated XML specification, with invaluable insight from said Tim Bray. Almost entertaining compared to the plain spec…
Anyway, Tim joined Google with focus on the Android platform. I’m glad to see that we share the same feeling about the iPhone and Apple’s AppStore policies:
The iPhone vision of the mobile Internet’s future omits controversy, sex, and freedom, but includes strict limits on who can know what and who can say what. It’s a sterile Disney-fied walled garden surrounded by sharp-toothed lawyers. The people who create the apps serve at the landlord’s pleasure and fear his anger.
I hate it.
While I don’t have much hope that this reality will ever bother the vast majority of iPhone users, I strongly hope that more and more developers move away from the iPhone because of the way Apple treats them.
I’m sure Tim will add to the reasons to move to Android…
By Olivier Gérardin
I’ve been pondering a replacement for my (still reliable but aging) Treo 680. Since I have decided not to get an iPhone as long as the App Store has such insane policies, I’ve narrowed my search down to:
The Pre has a groundbreaking OS called webOS which is almost entirely built on JavaScript and web technologies. It’s the phone that was designed for “always on” operation; it integrates seamlessly with online services such as mail and calendar from several providers (including Google of course). On the down side, it’s only available in a handful of countries in Europe, Luxembourg NOT being one of them. I called all three mobile network operators and none of them had even heard the name “Palm Pre”, so I don’t suppose I should wait for it to arrive here anytime soon. I could get a German one, but apparently you need to activate it on a German network, plus it comes with a QWERTZ keyboard.
Android phones are not that much easier to get, but they exist. There was an offer for an HTC Hero not long ago, but most reviewers found the hardware a bit lagging, so I decided to wait.
But now it seems that Google might be selling soon its own Android 2.1 device, unlocked GSM, with no carrier messing with the software… How great is that ? My own Christmas might be a little late this year 
By Olivier Gérardin
An interesting fact about the new support for Java in the Google App Engine, is that it supports real, standards based Java; in other words it runs JVM bytecode. It might sound like something trivial, but it’s not. In fact, before the announcement many people had speculated that the Java support in GAE would be based on some sort of variant of Java. Maybe they would use only the Java syntax, but not the compiler.
See GWT: on one hand you’re developing in Java, and you’re lead to believe that you are actually writing a Java application, but when the source gets translated for deployment, it’s JavaScript that is generated. There is no trace of Java whatsoever in the code that runs in your browser. Using Java as a source language is just a way to leverage existing tools and developer skills.
See also Android: here it’s not the source code that gets translated to a target code, it’s the compiled JVM bytecode that gets translated to another kind of bytecode, the Dalvik executable bytecode. And the Dalvik bytecode runs in Dalvik VM, Android’s own virtual machine. Again, no trace of Java at runtime. Again, Java is used because of the existing tools and skills.
But apparently, it goes differently with the GAE. It runs true, standard JVM bytecode. It supports WAR deployment, JDO and JPA mapping, etc. This is already a good thing in itself, but there’s an added benefit to this, which is maybe the reason why Google choose to make it this way: it can run bytecode generated by the emerging galaxy of languages that compile to JVM bytecode or run in a JVM, such as JRuby, Groovy, Jython, Scala, and others.
That’s what you call killing many birds with one stone…
By Olivier Gérardin
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…
For those of you not familiar with the Who’s Who of IT, Tim Bray is best known for the central role he played in the initial specification of XML. I should know because I spent countless hours studying it back in 2000. If you really really have to read it too, I urge you to read instead the annotated XML specification, with invaluable insight from said Tim Bray. Almost entertaining compared to the plain spec…