Pierre Chauvin – Java, JEE, WebSphere, LWCM

Un article de Petrus    18 Commentaires

S’achève une deuxième journée de conférences à Anvers, pendant laquelle j’ai à nouveau tenté de varier les sujets. Concernant le village des exposants, il faut bien avouer que c’est relativement mort. Coté WiFi aussi, RIP Twitter. Je ne pense pas avoir eu 10 minutes de connexion ininterrompue. Une session a également été annulée : Wicket in Action, en espérant qu’elle soit replanifiée vendredi.

Keynote

Après la projection du trailer du film 2012, c’est Ivar Jacobson qui c’est installé au pupitre pour débuter cette journée. Lors de la conférence JAOO de Aarhus (2005), j’avais déjà eu l’occasion d’apprécier l’orateur ; et finalement on retrouve les mêmes idées, version 2.0 (le fameux smart/unsmart). M’intéressant beaucoup aux méthodologies de l’industrie logicielle, son constat reste valable (Scrum n’est qu’une n^ième méthode/approche de plus (UP, RUP, XP, Agile), la roue est sans cesse réinventée, etc.), mais je suspecte une tentative de lobbying de Ivar Jacobson International, plus que d’un réel désir de normalisation.

Cette initiative appelée SEMAT (pour Software Engineering Method and Theory) paraît pleine de bon sens, mais même avec toute ma bonne volonté, j’ai du mal à imaginer que son modèle reposant sur un noyau de bonnes pratiques auxquelles viennent se greffer d’autres pratiques propres aux processus des entreprises aboutisse à quelque chose de concret. Et ce n’est pas une liste de signataires de renom qui m’encouragera à penser le contraire. Je ne suis pas à convaincre sur le constat, mais sur la forme de l’initiative.

Vous pouvez néanmoins prendre connaissance des assertions de Ivar Jacobson et de son initiatve sur SEMAT.org.

La seconde partie de la Keynote fut un peu plus spectaculaire ;-), avec le show de Oncle Bob, aka Robert C. Martin (ObjectMentor Inc.). Vous l’aurez compris, l’auteur du best seller Clean Code (prentice Hall, ISBN 978-0132350884) a fait un petit show humoristique plutôt réussi…Vous pouvez prendre connaissance du Manifesto for Software Craftsmanship pour devenir un vrai professionnel… Et entre temps, IBM, partenaire des Devoxx 2009, a livré quelques statistiques issues de l’utilisation de puces RFID dans les badges des visiteurs et de la fréquentation des sessions. Rien de très intéressant.

Spring Framework 3.0

La conférence Wicket ayant été annulée en dernière minute, j’ai fais un mauvais choix. Pas que la conférence était inintéressante, mais j’avais dernièrement traité du sujet avec Gildas au YaJUG (Luxembourg). Arjen Poutsma (SpringSource ) a simplement énuméré les nouveautés de Spring 3.0 de manière relativement exhaustive. Si vous souhaitez connaître le détail de cette session, je vous invite à regarder la vidéo de la dernière présentation de Gildas Cuisinier au YaJUG, en attendant d’obtenir les slides des Devoxx.

Pro JavaFX – Developing Enterprise Applications

Après des sessions sur JEE, Cloud, le Web, voici donc une session sur RDA et plus particulièrement JavaFX. Mon regret est que Stephen Chin n’a finalement présenté que les composants pour JavaFX qu’il a développé dans son projet JFXtras: XCalendarPicker, XShelfView, XTableView, ainsi que son outil de test pour JavaFX: FEST. J’aurais aimé quelques chose de plus indépendant, car nous aurions presque pu ranger cette session dans Partner Slot. JFXtras est un projet intéressant, mais je m’attendais à une conférence permettant à l’audience d’observer l’alignement possible de JavaFX avec les problématiques d’entreprise. (et non, ce n’est pas un composant XTableView permettant de gérer 16.000.000 de lignes qui permet de l’affirmer).

Session un peu décevante donc…

Google AppEngine (GAE) Java: Groovy baby!

Retour du coté du Cloud et de PaaS cette fois, avec Patrick Chanezon (Google) et Guillaume Laforge (SpringSource), qui ont rappelé les fonctionnalités de la plateforme Google AppEngine, ces limitations, puis ont présentés la programmation GAE avec Groovy.

L’argument principal avancé pour le recours à GAE est le coût de l’hébergement d’une infrastructure Java, ainsi que la possibilité de scaling garantie par Google. Guillaume Laforge a listé les différents modules et APIs disponibles pour le développement sur Google AppEngine:

• MemCache
• BigTable
• URLFetch
• Mail
• XMPP
• Task Queue
• Images
• Users

La possibilité de pouvoir « monitorer » simplement sa solution SaaS grâce au dashboard GAE est aussi mise en avant. Des problèmes de connexion dans la salle de conférence n’ont pas permis de réaliser les démonstrations prévues initialement. GAE, outre les fonctionnalités citées ci dessus, propose un support d’un certain nombre de langages, en plus des classiques Python et Java:

• Scala
• JRuby
• Groovy
• Quercus (PHP)
• Rhino
• Jython (en plus de Python :-P)
• GWT

Un point positif de cette session est qu’ils n’ont pas hésité à rappeler les limitations actuelles de la plateforme:

• Naked domains
• SSL
• Mauvaises performances lors du premier appels à un script (Groovy, JRuby, etc.)
• No MapReduce
• No SQL
• No sockets
• No threads

Guillaume Laforge a consacré la seconde partie de la conférence à présenter une boîte à outil pour l’utilisation de Groovy avec Google AppEngine: Gaelyk. Les fragments de code et les slides sont d’ores et déjà disponibles via SlideShare.

J’ai également découvert l’outil Groovy web console qui permet de tester ses scripts Groovy et la capacité de Groovy à créer des DSLs. Très bonne session à mon gout.

Using BTrace and DTrace to Instrument and Analyse Java Applications

Ouch, session délicate avec Simon Ritter (Sun Microsystems) qui s’attaque à DTrace et BTrace pour la résolution des problèmes d’instrumentation des programmes Java. Très intéressant. Simon Ritter, qui cette année présentait 3 sujets très différents (DTrace & BTrace, JavaFX et Nintendo Wiimote, Managing Glassfish on OpenSolaris), a rapidement abordé les bases de DTrace (qui fonctionne uniquement sous Solaris et MacOS), un outil résolument tourné vers la production (safe, minimal performance impact), et la terminologie correspondante: Probes & Providers, jstack, DVM, JSDT (JDK 7), etc.

Son équivalent BTrace, non typé pour un OS particulier permet l’instrumentation dynamique du Bytecode, proposant ainsi un tracing au niveau application et plus uniquement au niveau de la JVM. BTrace et la définition des Probes est accessible via un système d’annotation (@BTrace), et dispose d’un plugin pour VisualVM. La différence majeure entre un tracing activé via JMX et BTrace est que BTrace est low-level et permet de définir des traces de granularité plus fine.

Session à nouveau intéressante mais plus ardue. Les slides utilisés lors de cette présentation sont disponibles sur le site de Sun Microsystems : DTrace – Bridging the Observability Gap for Java and Scripting Applications.

Android – resolution independence and high performance graphics

Dernière conférence de la journée orientée vers la mobilité avec Romain Guy (Google) qui intervient sur la capacité de l’OS de Google Androïd à résoudre les problèmes d’indépendance de résolution et sur l’obtention de bonnes performances graphiques.

Romain a présenté les différents concepts et unités manipulées par Androïd pour résoudre les problèmes d’affichage de l’OS et des applications sur des appareils différents :

• T-Mobile G1 initialement, puis compatibilité nécessaire pour HTC, Samsung, Sony, Motorola
• Taille d’écran initiale supportée: HVGA 320*480 ; Désormais de nombreuses autre tailles doivent être gérées (incluant des tailles non proposées encore par les frabricants) : QVGA, FWWGA, etc.
• Densité initiale de 160 dpi, mais support nécessaire de 120 dpi, 240 dpi, etc.

Romain a ensuite abordé les différents points essentiels pour la gestion de ce besoin:

1. Resolution independance units
2. Layouts
3. Resources management
4. Density compatibility
5. Size compatibility
6. Best practices (use layouts, use dips not pxs, don’t hardcode pixel dimensions, use resources, etc.

Concernant la partie Androïd Graphics, Romain a expliqué que Java ne permet pas d’obtenir des performances satisfaisantes dans certains cas, et qu’il demeure non adapté pour certaines choses. D’un autre coté, l’utilisation de primitives natives via JNI est souvent compliqué et le support d’architectures variées est rapidement couteuse. Ainsi Google a développé son propre langage de rendu graphique bas-niveau, basé sur du C, et parfaitement intégrable avec Java: Le RenderScript (RS). RenderScript est une abstraction de OpenGL ES. Les scripts *.rs sont gérés comme des ressources par Androïd, et sont compilés à l’exécution. RS constitue donc un moyen pratique d’obtenir des performances satisfaisantes et de manipuler les bitmaps.

Google RenderScript sera disponible à partir d’Androïd « Flan » courant 2010.

Voila pour cette seconde journée, j’ai conscience d’être en retard sur la rédaction du feedback, mais à nouveau, avec l’indisponibilité du réseau sur place, j’ai pris beaucoup de retard… A suivre donc mes impressions sur la matinée de vendredi, et mes conclusions sur Devoxx 2009 !