Je n’ai pas vraiment de point de comparaison avec les autres grands conférences de l’ecosystème Java (JavaOne, Devoxx), mais voici mon sentiment par rapport à celle-ci.

Je m’attendais à beaucoup plus de participants. Compte tenu de la portée, des sujets et de la renomée de la conférence. Sans être réellement confidentielle, la quantité de personnes présentes n’est pas plus impressionante que cela.

J’ai identifié une demi-douzaine de français, Emmanuel Bernard (RedHat, JBoss, Hibernate) qui était conférencier, et des représentants de Xebia et Sfeir. Il y avait d’autres francophones, venant de suisse romande, mais je ne suis pas combien. La grande majorité des participants étaient des germanophones.

La totalité des conférences était en anglais. Seul un évènement attaché, concernant un retour d’expérience sur la mise en place d’une carte/certificat pour signatures électroniques était en allemand (et partant je ne suis pas en mesure de vous en parler).

L’infrastructure est bien prévue et très bien gérée. Rien à redire, si ce n’est les problèmes de connexion WIFI le premier jour, qui ont été réparés par la suite. A charge des participants de faire attention à leur ligne : une consommation excessive de muffins ou de croissants est contre-indiquée pour la santé. L’évènement a lieu dans un énorme complexe cinématographique, ce qui présente des avantages (fauteuil, bar, toilette en conséquence, …), mais un petit inconvénient : il n’y a pas de tablette pour prendre des notes ou poser son portable. En ce qui me concerne, le lattitude E6500 a tendance à enormément chauffer au bout d’un moment, et prendre des notes en permanence n’a pas toujours été une partie de plaisir.

Les stands des sponsors (SSII ou clients finaux, surtout des banques) ne sont pas intrusifs et pas gênant du tout.

En ce qui concerne le fond, le choix des conférences, et surtout la répartition entre la grande salle et les autres, les choix n’ont pas toujours été pertinents. Par exemple, parmi les sessions auxquelles j’ai participé, celles sur la gestion des tests unitaires, et celle sur la programmation parallèle auraient été bien mieux dans la grande salle. Certains sujets n’étaient à mon sens plus vraiment à la mode.

Session technique : Building DSL with Eclipse, Peter Friese, Itemis

Cette session porte sur la création d’un DSL externe, en utilisant essentiellement l’outil Xtext, qui est un plugin Eclipse.

Il vallait mieux avoir suivit la conférence de Neal Ford sur les DSL au préalable, pour suivre celle-ci.

Peter Friese rappelle qu’un DSL est un language:

• qui permet d’exprimer son intention
• qui permet de résoudre uniquement UN problème

A cet égard, Java est un couteau suisse, un langage général avec lequel on peut tout faire, un DSL ne permet de faire qu’une seule chose.

Le conférencier donne deux exemples de DSL:

• SQL
• Ant

Selon lui, SQL est un bon exemple de DSL, on exprime uniquement ce que l’on a besoin d’exprimer, et il n’est pas possible de faire autre chose avec.

Il est important, dans cet exemple que le FROM soit avant le WHERE, même si, d’un point de vue sémantique, tout serait identique en inversant ces deux lignes, parce que si on a pas écrit auparavant la ligne 2, aucun IDE ne serait en mesure de vous faire de la completion automatique à partir des informations précédentes (il faut savoir que les colonnes proviennent de la table maTable pour proposer les champs champX et champY).

Il montre ensuite un exemple de script Ant, et exemple que, dans ce cas, on met dans le script beaucoup plus de choses que juste ce dont il y a besoin pour exprimer un build. Cela est du à des raisons historiques, l’auteur de Ant aurait créé cet outil dans lors d’un voyage, et il n’avait qu’un parser XML sous la main, et pas envie de redévelopper un parser.

Un SQL interne (ce qui n’est pas le sujet de cette session) est une API qui permet de faire une seule chose, comme par exemple :

Le conférencier cite l’ouvrage suivant : The definitive ANTLR reference, Building DSL de Terence Parr.
Ce livre donne une liste de ce qu’il y a à faire pour créer un DSL externe:
1/ Créer une grammaire ANTLR
2/ Générer un parseur lexical à partir de la grammaire
3/ Le parseur va créer un arbre représentant le parsing
4/ Transformer l’arbre en modèle sémantique
5/ Itérer sur le modèle
6/ Donner les élément du modèle à un template

Le conférencier a passé des extraits d’une vidéo introductive sur les DSLs dans laquelle Martin Fowler expliquait qu’il y avait des problématiques spécifiques concernant l’écriture de DSL externes :

• Manque d’éléments symboliques d’intégration (accolades, …)
• Ecriture d’un parseur compliquée
• Intégration des DSL non native dans les IDE (complétion automatique, navigation par ctrl-click, outlines, …)

A fin de résoudre ces problèmatique, il existe un outil : Xtext, qui est un plugin Eclipse permettant de définir formellement des grammaires dans une syntaxe proche de EBNF.

La syntaxe de définition de ces grammaires est elle même définie par une grammaire (DSL) qui, à l’aide du moteur interne de Xtext permet de bénéficier des avantages d’un IDE pour ce language (complétion, outlines, navigation rapide, …).

Xtext contient à la fois la définition de la grammaire pour l’écriture des grammaires, mais également un mécanisme qui fabrique un meta-modèle ecore à partir d’une grammaire particulière. Ecore est l’API interne d’Eclipse permettant de modéliser un méta-modèle.

A partir de ce meta-modèle ecore, Xtext génère un IDE pour cette grammaire, et donc pour ce DSL.

Il y a ensuite un exemple d’utilisation pour créer un DSL de création d’application mobiles. Les étapes sont:

• 1/ Analyser la problématique métier (du domaine)
• 2/ Etablir une relation entre les concepts métier du domaine et un langage
• 3/ Ecrire un générateur

Pour générer du code (en Objective-C en l’occurence, pour les applications mobiles) à partir des données exprimées avec ce DSL, il utilise un autre plugin Eclipse qui s’appelle Xpand (language specialized on code generation based on EMF models). Je ne connais pas ce plugin, mais visiblement, compte-tenu des réactions de certaines personnes dans la salle, ce plugin ne serait pas très pratique, ou très stable.

Pour conclure, implémenter un DSL avec Xtext est, sinon facile, au moins aussi facile que possible. Xtext fournit un support important des DSL ansin décrit sous Eclipse. Par ailleurs, une intégration entre des DSL et Java est possible (Xtext fournissant un meta-modèle ecore nativement pour Java).

Le présentateur a annoncé un futur (8 juin) Webinar sur Xtext.

Technical Session : Easy to use, Highly available, High performance, Java Database access: seriously ? Craig Russell, Oracle

Cette session parle d’un outil, ClusterJ, permettant d’établir des clusters sur des bases MySQL.

High Performance File I/O The Perl/Java battle, Daniel Echhorn, Stephan Rufer

Cette session ansi que la suivante étaient des sessions courte, d’une vingtaine de minute et présentant donc trés rapidement une chose/une idée. C’est à mon sens un très bon format de présentation.

La problématique de cette mini-session, avec un titre ayant une odeur de troll, était de montrer les différences de performances d’I/O entre un code legacy écrit en Perl et un code plus récent écrit en Java.

La forme de la présentation était très intéressante :

• On pose le contexte, on explique ce qu’on a fait
• Test qui se déroule en live (démo), sous une forme graphique qui fait penser à un « Google fight », et les conférenciers qui en rajoute (« Allez Java ! »)
• On discute du résultat

En l’occurence, il s’agissait d’un batch qui traitait et parsait des lignes avec un format contraint. Le résultat, graphiquement est que Java est beaucoup plus mauvais au départ et rattrape quasiment au bout d’un moment les perfomances de Perl, sans toutefois tout à fait les atteindre.

Je n’ai pas la possibilité (ni le temps) de faire un audit sur leur code, mais à mon avis leurs conclusions sont un peu erronées. Il y a peu de chance que le programme Java optimise ses performances sur proprement les IO, je pense que le gain de performances observé entre le début et la suite est surtout du à la gestion des String en Java. Les mêmes patterns doivent se retrouver dans les jeux de données, et au début, cela instancie beaucoup de String, qui se retrouve dans le pool de String au bout d’un certain temps. Je leur ai demandé à la suite de la conférence s’ils avaient examiné cela, ce qui n’était pas le cas.

DROIDinfo and DROIDparade, two little helpers for Android developers, Jörg Pleumann & Felic Jost, Noser Engineering AG

2010 est une bonne année pour les smartphones en général et pour les Androids en particulier.

Google fait en sorte de faciliter les choses pour les développeurs

http://developer.android.com/resources/dashboard/platform-versions.html

http://developer.android.com/

DROIDinfo développé par la société du conférencier permet d’avoir:

• des informations supplémentaires sur le matériel d’un Android particulier
• des résultats de benchs

Cela a permit de se rendre compte que:

• Le HTC Dream contient un thermometre
• Le péripharique de stockage externe n’est pas toujours récupéré par « /sdcard »
• La CPU et les différence d’IO varient énormément d’un modèle à l’autre

Conclusion:

• Supposer que les smartphones sont lents
• Réalisez les traitements de manière asynchrone par rapport aux actions de l’interface
• DROIDinfo est disponible sur l’AndroidMarket (attention deux versions différentes selon la version d’Android)
• DROIDparade (beta) est une base de donnée des périphériques Android avec les caractéristiques déterminées par DROIDinfo

End keynote : Software in the service of handicapped people, Hans-Willem van Vliet, R et D at Otto Bock

Je n’ai malheureusement pas pu rester à la keynote de fermeture, pour cause d’avion à prendre, et donc je n’ai pu assister à la conclusion de cette présentation.

Vous pouvez néanmoins vous référer au compte-rendu officiel de Jazoon sur cette troisième journée.

Comme la keynote d’ouverture de la journée, cette keynote commence (et je n’ai eu que le début) par des explications techniques métiers.

Otto Bock était un prothésiste qui a inventé la prothèse modulaire en 1919. En 1919 également, la fondation Otto Bock a été créée, originellement pour opérer les amputés de la première guerre mondiale, puis elle a été fermée pour réouvrir à l’issue de la seconde guerre mondiale.

En 2010, la fondation a 4000 employés, est le leader mondial de la prothèse avec 40 sites internationaux et une R et D très importante.

J’ai appris que l’essentielle des amputations dans les pays industrialisés n’est pas du aux accidents, mais au diabète qui créé des infections.

Conclusion

Je suis content d’avoir passé ces trois jours à Jazoon, j’ai la tête un peu pleine comme un melon (mais je deverse dans ce blogue pour faire de la place).

Les sessions les plus intéressantes à mon sens ont été celles sur:

• La programmation parallèle
• La sécurité (mais pas toutes)
• Les DSLs
• Le management de la boite à outils de tests unitaires
• Les chargeurs de classe

N’hésitez pas à poser des questions dans le forum si vous voulez que je détaille quelque chose.

Keynote d’ouverture : The Gaïa satellite, data processing and challenges, William O’Mullane, ESAC

L’ESAC est le Centre Européen d’Astronomie Spaciale. Le présentateur est un spécialiste à l’ESAC du data mining. Le sujet de la keynote concerne les problématiques liées à la mise en place d’un satellite embarquant un télescope géant, Gaia.

Le présentateur commence en donnant un petit cours d’astronomie dont j’ai essentiellement retenu que l’origine du terme « voie lactée » vient du sein de Junon qui l’aurait généré.

Willian O’Mullane explique quelles sont les problématiques techniques physiques liées à l’environnement terrestre qui limitent fortement la précision possible pour les télescopes (atmosphère, gravité supérieure, …) qui imposent de créer des télescope sur un satellite. Il explique ensuite quel sont les besoins de précision, les quantités de données qui sont récupérées, puis persistées (de l’ordre de 10TB par jours il me semble).

Il donne ensuite les besoins des utilisateurs, par rapport au format de données récupérée et indique les types de traitement à effectuer pour avoir des rapports pertinents.

Compte tenu des problématiques on pourrait penser que la taille du projet informatique est gigantesque, mais il relative en comparant les nombres de ligne de code avec celles de projets comme Linux. D’un point de vue ordre de grandeur, le projet est cent fois plus petit que des projets comme Linux.

L’ESAC utilise Java pour le traitement des données, de manière quasiment exclusive, depuis 2000. Les raisons en sont :

• La portabilité : cela doit pouvoir fonctionner au moins jusqu’en 2020
• C’est plus facile d’écrire du code correct (typage statique : Eclipse!)

L’ESAC utilise :

• JUnit, Hudson;
• Apache common Math, log4J
• JBoss
• Aucun MPI particulier ou bibliothèque de grid

Du point de vue des performances, ils constatent de fait que le Java est plus rapide que le C, pour un code équivalent, métier, grâce au JIT sur un processeur Intel.

Il y a néanmoins un certain nombre d’inconvénients/limitation en Java :

• Java n’est pas la balle traçante (cela peut s’interpréter de différentes manière, je vous laisse interpréter);
• Trop peu de bibliothèques mathématiques maintenues (la meilleure étant ApacheCommon Math);
• Support numérique natif prévu non implémenté;
• Un respect des standards IEEE souvent défaillant et quasiment jamais corrigé.

Remarques supplémentaires :

• Il y a beaucoup de tests unitaires sur le projets;
• Les standards ont souvent besoins d’être adaptés sur mesure pour répondre aux besoins;

Des tests de virtualisation, en particulier de data grid ont été fait. Il semblerait qu’il y ait des problèmes sur le cloud d’Amazon quand on fait du DataGrid avec plus de 1000 noeuds (parce qu’en dessous ça vaut pas la peine, les noeuds sont même pas des super calculateurs, alors hein!).

Présentation très intéressante, comme tous les retours d’expérience, mais en l’occurrence, pour moi, le métier était trop pointu pour que je profite de tous ses apports.

Session technique : Essential of testing: the tools you need to know, Bettina Polasek, Marco Sicolini, AdNovum Informatik AG

On peut ajouter un sous-titre : One tool, one purpose

C’est fait, visiblement le sujet de cette présentation intéresse beaucoup: toutes les places (petite salle) sont prises et il y a une quarantaine de personnes assises sur les marches ou debout.

Les sessions d’aujourd’hui commencent fort avec cette présentation remarquable, qui portent plus sur la politique à avoir vis-vis des outils de tests, et de manière générale la manière de gérer ses outils, que sur les aspects les plus techniques, même si on a eu droit à toute une série de démo illustrant différents usage de tests.

Les équipes d’AdNovum ont poussé très loin les pratiques en matière de management des outils de travail, et en particulier des outils de développement.

Ces équipes ont fait le constat suivant :

• il y a de nombreux outils;
• chaque outils a ses avantages et ses inconvénients;
• il y a un recouvrement non négligeable entre ces outils.

Les objectifs sont:

• Savoir déterminer établir une bonne adéquation objectif / outil ;
• Pouvoir gérer et maintenir à niveau les compétences des équipes par rapport aux outils sélectionnés;
• Sélectionner un ensemble restreint mais suffisamment complet d’outils;
• Pouvoir gérer la mise à jour de cette boite à outil (et donc les compétences liées et l’historique de code).

Les critères de sélection sont:

• Technologiques:
  • Java
  • .NET
  • JavaFX
  • …
• Méthodologiques:
  • Statiques
  • Fonctionnels
  • De robustesse, de performance
  • D’ergonomie
  • De maintenabilité, de non-régression
  • …
• Couche concerné:
  • Web (UI)
  • Métier
  • Donnée

Ils considèrent que les décisions se prennent à différents niveau et qu’il faut en être conscient:

• Stratégique. Exemple: on choisit un contexte JEE
• Tactique. Exemple: on choisit JUnit
• Opérationnel. Exemple: on choisit JUnit 4.7

Les choix des différents niveau doivent être remis en question périodiquement, avec une période plus grande pour les hauts niveaux.

Avec cette approche, au jour présent, en ce qui concerne les tests, leur choix s’est porté vers les outils suivants (dans des catégories différentes):

• Grinder
• JUnit
• Selenium
• HtmlUnit
• Mockito
• Grinder
• Glassfish (embeddable)
• SOAP/REST Drivers
• SOAPUI
• PMD
• jDepends

Il y a ensuite toute une série de démos.

Avec Selenium, un test de niveau (UI). Remarque: il est possible de spécifier une vitesse inférieur pour voir le déroulement du test s’il est trop rapide.
Avec HtmlUnit, test de niveau UI également. Les développeurs ont le choix entre les deux, il y a un compromis à faire lorsqu’ils implémentent leurs tests sachant que :

• HtmlUnit est beaucoup plus rapide que Selenium;
• En contrepartie, Selenium utilise les vrais moteurs des navigateurs, alors que HtmlUnit comprend son propre interpréteur de requête, par ailleurs, avec Selenium, on peut vérifier la présence d’éléments dans le DOM, et donc tester des interactions Javascript, en particulier AJAX, alors que HtmlUnit est au niveau des requêtes HTTP.

Il y a ensuite un test d’un composant métier EJB, avec le moteur d’EJB embedabble de Glassfish (Dans la spéc. JavaEE6), sans démarrer le serveur d’application.
En dernier une démo d’un test d’un composant logique métier avec Mockito et JUnit.

Le message qui voulait être passé par ces démonstrations, est que, en fonction des développements, il faut faire des tests au niveau approprié, avec les outils appropriés.

Les retours d’expérience qui leurs semblent importants sont les suivants :

• Communiquer sur la stratégie de test à ses clients (internes ou externes);
• Concevoir des tests simples et performants;
• Décider de manière claire ce que l’on test;
• Avoir le bon niveau de test;
• Traiter votre code de tests comme un citoyen de première classe !! (documentation, qualité, performance, respect des patterns) Faites comme si vos tests allaient en production.
• Un outil : un usage;
• Les outils doivent simplifier les tests;
• Mettre en place des recommandations d’utilisation et de la documentation;
• Former des experts de référence pour ces outils;
• Entrainer les développeurs à l’usage des outils.

Les présentateurs nous ont également fait part des pistes qu’ils regardent pour intégrer de nouveaux outils à leur boite à outils :

• Tests unitaires polyglottes (Groovy ?) : L’idée serait de rendre les tests moins verbeux et partant faciliter leur maintenance;
• DSL ? Cela pourrait permettre que les analystes métiers puissent écrire leur tests.

Ils concluent en disant qu’une boite à outils (de test ou en général) de développement est extrêmement puissante, mais que cela nécessitait une maintenance régulière.

La salle était comble et le sujet et la présentation (et les présentateurs) étaient largement à la hauteur. Très bonne présentation.

Session technique : Spring Framework 3.0, Key themes and features, Jürgen Höller, SpringSource

Je pensais apprendre beaucoup de chose pendant cette conférence, des détails techniques et des annonces croustillantes. En fait Jörgen Höller s’est contenté d’introduire la manière intrusive de faire du Spring (c’est-à-dire avec des annotations, disponibles depuis Spring 2.5) et d’expliquer qu’avec Spring 3.0 (sorti en décembre dernier quand même), cela avait été amélioré, et en partie standardisé. J’ai donc passé la présentation, qui n’a pas semblé passionner grand monde non plus en dehors de moi, à rédiger les notes de la présentation précédente pour les lecteurs du Blogue.

Transition

Je prend l’avion ce soir et ne pourrai rédiger le compte-rendu des conférences de cet après-midi pour que vous l’ayez avec votre café demain matin. J’interromps donc ce billet après les sessions du matin, et vous proposerai un autre billet pour l’après-midi demain ou après-demain.

Si vous avez des commentaires, rendez-vous sur le forum

Cette seconde journée commence par une keynote de Ken Schwaber, inventeur, avec Jeff Sutherland de la méthode Scrum, puis enchaine sur les sessions, avant de finir sur les « Jazoon Rookies ». Les Jazoon rookies sont un format de conférences spécifique à Jazoon, où des intervenants qui ne sont pas encore des stars de la scène (Java) internationale, peuvent faire leurs premiers pas dans une conférence à caractère international.

Keynote d’ouverture de la seconde journée : Total Cost of Ownership, Ken Schwaber

A part la présentation de ce que présente scrum.org en terme de formation, certification, Ken Schwaber explique un principe et énonce une idée forte.

Scrum est très léger et est un « framework », au sens où il pratique le principe de Hollywood. En particulier, lors des itérations, il faut donner un sens à « done ». Il nous demande de nous interroger entre participants voisins (ce qui n’est pas évident quand ses voisins parlent uniquement allemand), pour savoir ce que l’on entend par « done », dans le cadre d’une itération de développement (sprint).

Puis il demande si les réponses que l’on a reçu comprennent :

• Les benchs de performances
• Les tests de robustesse (stabilité)
• Les tests de réponse immunologique (si vous savez ce que c’est, merci de mettre un commentaire)
• La vérification de la bonne intégration avec les six autres équipes (en supposant qu’il y ait six autres équipes)
• Tests d’intégration avec les incréments des six autres équipes, pour valider un incrément global
• Mise à jour des releases notes
• Internationalisation du produit dans les six locales des utilisateurs du produit
• Tests d’acceptance utilisateur
• Tests anti-regression
• Revue de code

La « stabilisation » est ce qu’il faut faire après les itérations pour avoir un produit fini. Si notre définition de « done » n’est pas rigoureusement définie, la stabilisation augmente après chaque itération de manière exponentielle (ou peu s’en faut).

Session technique : Unleash your processor(s), Vaclav Pech, JetBrains

Cette session très technique intéresse beaucoup de monde. La salle dans laquelle elle a lieu, qui n’est pas la grande salle, suffit à peine pour tous les participants.

Vaclav Pech est employé par JetBrains, mais est impliqué, ainsi que Dierk König (cf plus loin) dans l’équipe de développement de GPars, une librairie Groovy qui propose des abstractions de haut niveau pour programmer de manière parallèle en utilisant les patterns les plus modernes.

Vaclav commence par dire qu’il va nous faire peur. Je pensais qu’il allait nous sortir des horreurs comme on en rencontre que en programmation concurrente. Il nous a juste montré qu’avec un code très simple invoquant beaucoup de calculs, en ayant un quadri-processeur, double coeurs, notre programme n’utilise qu’un huitième de la ressource CPU disponible.

Selon lui, la plupart des programmes utilisant plusieurs coeurs le font par hasard.

Peut-on faire mieux ?

Il existe des patterns de conception modernes permettant de programmer du code essentiellement métier, en profitant du parallélisme.

Il y a une distinction entre parallélisme et concurrence :

• On parle de parallélisme quand il y a deux exécutions simultanées : il faut au moins deux processeurs, ou un processeur multi-coeur;
• On parle de concurrence quand il y a parallélisme ou émulation : pour le programmeur client, les problématiques sont semblables.

Patterns de concurrence

• Map/Filter/Reduce
• Fork/Join
• Actors
• Software Transactional Memory (STM)
• Invocations asynchrones

Les invocations asynchrones se font en utilisant, en Java, les Parallel*Array définis dans la spécification JSR166y. Comment ? Vous ne connaissez pas et ce n’est pas dans votre JDK ? En réalité c’est une API qui n’a pas été inclue dans le JDK 6, et donc a été sortie de la JSR166, pour être incluse dans le JDK7 avec JSR166y.
Le principe des ces invocations asynchrones est qu’elles sont bloquantes de manière lazy, c’est-à-dire qu’on manipule des références vers le résultats d’un calcul, mais tant qu’on utilise pas le résultat du calcul, on n’est pas bloqué (au sens verrou).

Les STM (Software transactional memory) sont à la manipulation d’objets en mémoire ce que la transaction JTA est à l’INSERT SQL (raccourcis opportun pour faire comme si j’avais vraiment compris). Il faut faire très attention quand on fait des choses transactionnelles dans un contexte de concurrence (et donc encore plus dans un contexte de parallélisme, si vous avez suivis). Par ailleurs, il n’y a rien de magique, l’usage des transactions, quelqu’en soient les objets pénalisent fortement les performances (création de logs, utilisation de verrous et synchronisation, scheduling …).

Je n’entrerais pas plus dans le détail, dans ce billet, pour vérifier la validité de mes notes, mais j’ai appris en vrac que :

• il existe des inter-blocages sympathiques (enfin, plus sympathiques que d’autres: ceux qui se reproduisent de manière déterministe) !
• les acteurs, n’ont pas leur propres threads, ils interagissent avec le provider de thread (pool ou plus complexe)
• la communication entre acteurs se fait par des messages immutables

Le présentateur a pris le soin de préciser que la session s’adressait à des développeurs Java, que la session de l’après-midi sur GPars serait plus focalisée sur Groovy, mais que les exemples de code serait en Groovy, en Scala ou en Clojure, parce que les exemples en Java ne tiennent pas sur un slide !!!

Indépendamment des futurs API disponibles dans Java7, il existe des frameworks pour disposer de telles API. Par exemple, Akka, très utilisé en Scala, est également utilisable en Java.

Session technique : Harnessing the Power of HTML 5 WebSocket to Create Scalable Real-Time Applications, Peter Lubbers, Kaazing

Le présentateur a fait parti du groupe d’experts qui ont établis la spécification des WebSockets au sein du W3C. Il est employé par la société Kaazing qui propose des solutions clients/serveurs pour utiliser les WebSockets.

Peter Lubbers commence par rappeler certains principes de HTTP, pour présenter pourquoi, pour certains usages, HTTP n’est pas adapté et les WebSockets permettent de résoudre un pain-point :

• HTTP a été conçu initialement pour transférer des documents (pas des données, pas des applications);
• HTTP est « half-duplex », c’est-à-dire que le flux de données est monodirectionnel à un moment donné;
• C’est compliqué de faire du temps réel, pour différentes raisons et limitations.

Quand on a pas de WebSockets, on utilise les techniques AJAX et Comet pour palier à ces limitation. Mais

• Cela ne résoud pas réellement la problématique du temps réel;
• Pour simuler du temps réel, on utilise souvent des techniques de polling ou de long-polling (COMET ou reverse AJAX, c’est-à-dire qu’on fait un ping régulièrement en AJAX)
• COMET est un hack (une requête reçue devrait avoir une réponse de manière synchrone), qui manque donc de spécifications et de standards.

Il résume « Use COMET to spell COMplExiTy », parce qu’il n’y a pas de socket nativement.

A propos de la technique du polling, qui consiste à pinger régulièrement le serveur, il parle de « temps réel approximatif », ce n’est qu’une simulation, et que trop de connections sont établies.

La technique du long polling consiste faire en sorte que le client envoie une requête HTTP, que le serveur réponde partiellement, sans fermer la réponse. Eventuellement, de temps à autre, il y a fermeture de la réponse puis émission d’une nouvelle requête, de manière à supporter les proxies qui ferment automatiquement les réponses au bout d’un certain time out. Cela fonctionne, mais il y a un overhead inutile de données dans les en-têtes de requête et de réponse, de plus c’est un hack (d’après la spécification, une requête HTTP attend une réponse synchrone).

Le streaming est encore plus efficace, mais parfois problématique. Il peut y avoir des complications avec les proxies et les firewalls. Les réponses doivent être flushées périodiquement. Il y a des problématiques de limitations dues au nombre de connexions maximale que le navigateur autorise pour un même domaine (et la navigation par onglets).

Il peut y avoir avec ces techniques, des overhead allant jusqu’à 2 kilo octets par requête HTTP.

Si on imagine comme cas d’utilisation 1000 clients (application de chat ou de jeu en ligne) qui ping toute les secondes (Polling), il y a une sur-utilisation d’un méga par seconde.

Kaazing a implémenté un serveur TCP pour la compatibilité avec les WebSockets HTML5. L’API des WebSocket fait partie de HTML5, spécifié par le W3C et le protocole WebSocket est spécifié par l’IETF.

• Ce sont des sockets plein texte, full-duplex
• Elles permettent une communication avec un host distant.
• Elles traversent les firewalls, proxies et routeurs de manière (à peu près) transparentes.
• Elles utilisent un port HTTP.

Il y a deux schémas de protocoles pour les WebSockets, à savoir ws et wss, le second pour la version sur TLS (WebSocket Secure). Il y a un handshake établi en HTTP. Pour établir une connexion WebSocket, le navigateur envoie une requête HTTP, avec un en-tête « Upgrade: WebSocket ».

Exemple:

Une fois l’upgrade obtenu, il peut y avoir des communications dans les deux sens. Le modèle programmatique, à ce moment devient celui des sockets asynchrones.

Dans les browser le supportant, on a une API Javascript, pour manipuler ces WebSockets:

Evidemment, cet exemple n’a aucun sens, on n’ouvre pas une socket pour envoyer un unique message et fermer la connexion quand on peut envoyer des requêtes HTTP.

Les navigateurs actuels supportant les WebSockets sont les suivants :

• Chrome 4.0+
• WebKit nightly builds
• Planned for Opera and Firefox

Il semblerait que ce ne soit pas dans la prochaine version de IE (parce qu’ils ne l’ont pas annoncé)

L’inspecteur natif de Chrome permet une inspection des WebSockets.

Un certain nombre de librairies permettent d’établir une dégradation gracieuse (gracefull degradation), par une émulation des WebSockets (entre autre la ‘classe’ Javascript WebSocket est créée) :

• Kaazing Websocjet gateway;
• Flash WebSocket Emulation: web-socket-js sur github

Parmi les usages envisageables on a:

• XMPP, Jabber;
• Stomp, AMQP;
• Protocole de jeux spécifiques (voire propriétaires);
• Binaires;
• Tout protocole au dessus de TCP;
• LE navigateur devient un citoyen de première classe au niveau des protocoles de communication.

Parmi les exemples en production, on a :

• des applications financière temps réel;
• un portage par Google de Quake II.

Les WebSockets peuvent ne pas bien passer les répartiteurs de charges, proxies et firewalls de niveau 7 (HTTP, applicatifs). Par contre, la version sur TLS passe sans problème. Il est donc possible d’utiliser wss pour être sûr de passer en environnement inconnu (cela ne me semble pas satisfaisant intellectuellement).

Il finit en donnant un exemple de site réel de poker en ligne, dont la réactivité est déjà satisfaisante, puis montre la version de Kaazing, (« Kaasino » ha! ha! ha!), dont la réactivité est effectivement impressionnante.

Session technique : GPars : Parallel programming concepts for the jvm in Groovy, Dierk Koenig

L’objectif de cette session est de présenter GPars, une API Groovy permettant d’utiliser la plupart des patterns dont il était question dans la première session.

Il a fait une démonstration pour les concepts suivants : Fork/Join, Map/Filter/Reduce, Dataflow et a montré le code sur des slides pour les Agents et les Actors.

En fonction de l’API utilisée, la coordination est :

• Pour le Fork/Join et le Map/Filter/Reduce: predefinie;
• Pour les Dataflow: implicite;
• pour les Agents: déléguée;
• Pour les Actors: explicite.

Les nouvelles API essaient de faire en sorte que la coordination ne puisse être erronée.

Le principe avec les Data Flow est que si ça marche en developpement (ou en test), ça marche en production (coordination implicite).

Il y a également une API pour les CSP (Communication Sequence Processing) et il devrait prochainement en avoir une pour les STM (Software Transaction in Memory).

Avec l’approche Map/Filter/Reduce, on a plus de contrôle sur l’ordonnancement qu’avec le Fork/Join.

Les Agents sont une façon de proteger les objets (pour assurer une contrainte de manière concurrente). Souvent une variable d’une instance d’un agent est appelée « guard ».

Le présentateur conclus que :

• GPars rend la programmation concurrente simple;
• Il faut apprendre les concepts;
• Groovy et Java sont prêts pour les nouveaux défis (multicoeurs, …)

Session technique : Cloud Computing with Scala and GridGain, Nikita Ivanov, GridGain

Avec la session suivante, on passe de Groovy à Scala. Le présentateur montre l’usage d’une API développée en Scala pour non seulement rédiger du code qui sera déployé sur le Cloud, mais également pour configurer les instances des noeuds de son cloud et pour déployer automatiquement son code sur les différents noeuds, pour faire du grid computing.

Le présentateur explique qu’ils ont choisit de faire l’API en Scala pour les raisons suivantes:

• Langage scalable
• Post-fonctionnel
• Performances équivalentes à Java
• Statiquement typé
• Pleinement compatible avec Java

Gridgain a étudié une série de language avant de choisir Scala. L’avantage le plus important de Scala à leurs yeux est que l’on peut ajouter des mots-clés TOUT EN RESTANT statiquement typé.

Il a dit plus ou moins que Martin Odersky avait créé Scala parce qu’on lui avait dit que ce ne serait pas possible de le faire.

Il a introduit également Scalar, un DSL de cloud computing Scala basé sur Gridgain.

A suivit une séance de codage en direct, dans lequel il créé une application de grid computing en quelques minutes, sans copier-coller, sans code pré-compilé ou pré-buildé, sans configuration spécifique. Dans un premier temps, il a utilisé juste GridGain, puis avec Scalar il a fait la même chose avec un mot clé additionnel qui simplifie encore la syntaxe (en gros une ligne de code en moins de 80 colonnes suffit pour une application de grid computing).

Session technique : How Java Powers Large Online Retail Sites, Robert Brazile ATG

Cette session n’était pas vraiment technique, au sens le plus strict. ATG est un des fournisseurs de solution de e-commerce les plus importants au monde. Ce sont également des early adopter de Java. En 1996, ils utilisaient le serveur d’application Dynamo (rien à voir avec la solution de persistance NoSQL d’Amazon).

La sessions concernait essentiellement les problématiques auxquelles ils ont été confrontés, des retours d’expérience, des chiffres que je n’ai pu noter de manière complète, donc je préfère ne pas énumérer. Je vais uniquement énumérer les tendances business et technologiques qu’ils suivent :
Business:

• Mobile
• Remarque: dans les pays émergents, le mobile est le seul vecteur de e-commerce
• Social networks
• Convergence of these and other channels
• Growing use in the developing world
• ease of use in the business user
• spawning of many smaller sites rather that changing big one

Technologiques:

• Virtualization/Cloud computing
• NoSQL
• Scripting (PHP, Ruby, Groovy, Scala, Clojure, Erlang, …)
• Framework (Rails, Grails, Lift, …)
• Multi-core, more concurency, STM

Jazoon Rookies

Il s’agissait de trois conférences réalisées par des conférenciers débutants, auxquels l’opportunité de faire une présentation auprès d’un auditoire international était offert.

La première conférence était une présentation de l’API OpenSocial. Le sujet est très à la mode, mais je ne suis pas sûr que cela valait le coup de faire une conférence. C’est un standard. On prend les spécifications et on sait implémenter.

La seconde portait sur la problématique du facteur humain et sa prise en compte dans les réalisations logicielles d’un point de vue sécurité. La forme de la conférence était originale, avec une sorte d’histoire qui mettait en parallèle des chevaliers … avec … j’ai oublié. Impossible de prendre des notes. La présentation était bien mise en scène, mais en tant qu’auditeur, on perd le fil. Même si j’ai compris le message final, j’ai perdu le cheminement de la présentation.

La troisième conférence voulait démontrer l’intérêt de l’outil Eclipse Memory Analyzer récemment disponible avec Eclipse. La présentation était essentiellement deux démo. Prévoir une démo dans une présentation est risqué. Quand c’est la première présentation, c’est vraiment courageux. De surcroit, l’infrastructure était défaillante (exceptionnel depuis deux jours à Jazoon – sauf pour le WIFI hier. Tiens, je vous ai dit qu’aujourd’hui c’était bon ?). Bref, il s’est débrouillé comme un chef, sauf qu’il a manqué quelques explications préalables à sa démo pour nous indiquer l’intérêt de sa deuxième démo. (en gros Eclipse Memory Analyzer analyze les fichiers dump.hprof et propose une vue qui permet assez facilement de déterminer les memory leaks et dans la seconde démo, il le faisait à distance sur un serveur de production, mais sous des hypothèses que je n’ai pas comprises).

Conclusion

Cette journée était beaucoup technique et intéressante (subjectivement) qu’hier, mais je commence à saturer. Je comprend certain compatriotes qui ont pris le chemin du retour ce soir. A demain pour de nouvelles aventures !

Si vous avez des commentaires, rendez-vous sur le forum

D’après d’autres participants, le nombre de personnes présentes est beaucoup moins important que l’année dernière, sans doute 400 personnes à peu près contre plus de 600 l’année dernière. Est-ce que ça reflète une diminution de budget de la part de certaines boites ou un flou dans l’implication des Javaïstes du aux incertitudes suite au rachat de Sun par Oracle ?

Certains sujets sont bien présents en terme de nombre de sessions :

• Onze sessions parlent de Java EE 6 ou d’une partie (Servlet 3.0, JPA 2.0, JSF 2.0, …), mais on pouvait s’en douter, puisque la spécification est sortie le 10 décembre 2009;
• Cinq sessions parlent d’OSGi;
• Six évènements sont relatifs à la sécurité;
• Huit évènements (sessions ou keynotes) sont relatifs à la conception ou à l’artisanat logiciel (software craftmanship).

D’un point de vue infrastructure, l’organisation est impeccable, à part le WIFI qui est passé de mauvais, pendant les trois quarts de la journée, à inexistant à partir de 16 heure (c’était comique, d’ailleurs, puisque les twits #Jazoon étaient affichés, et que l’un des derniers se plaignait justement du mauvais réseau).

Keynote d’ouverture : Java SE and JavaFX : the road Ahead

Nous n’avons évidement pas eu droit à James Goslin cette année, mais Oracle nous a quand même envoyé un représentant: Danny Coward.

Oui, voilà voilà, Danny Coward, est Chief Architect, Client Software chez Sun Microsystems, ce qui signifie qu’il connait bien, entre autres JavaFX.

Il a commencé sur un historique de Java, pour continuer sur l’avenir et évoquer les nouveautés promises dans Java7 (qui ont été largement évoquées sur Developpez.com).
Il explique également que le JDK est devenu trop important et qu’il y a un refactoring important interne au JDK et que c’est essentiellement pour ces besoins internes qu’est apparu le besoin de modularité (et la JSR 294 et le project Jigsaw).

Danny Coward, en rappelant que Java a officiellement 15 ans depuis le 14 mai dernier, a montré une vidéo dans laquelle James Gosling montre un PDA en 1992 Star7 (Green project).

Il part de cette vidéo pour prouver qu’il y avait déjà des interactions modernes (il évoque le multitouch) avec des widgets à l’époque, dans les labo de Sun.
Puis il passe à JavaFX, pour lequel il énumère les versions avec les apports et indique qu’aujourd’hui JavaFX est rapide et a une quantité phénoménale de widgets.

Ma faible connaissance de JavaFX me fait peut-être rapporter les choses de manière incorrecte, mais j’ai noté :

• qu’il y a eu 4 releases en 18 mois ;
• avec la version 1.3, il y a eu beaucoup de nouveaux widgets ;
• avec la version 1.2 il y a eu un support des téléviseurs ;
• dans la version à venir, ce support des téléviseurs va aller en s’améliorant (navigation), et il y aura un émulateur comme outil fournit dans le JDK.

Il a fini en montrant un usage réel de JavaFX pour une application web utilisée dans le cadre des jeux Olympiques de Vancouver, avec beaucoup de widgets dans tous les sens.

Les sessions du jour

Je ne vais pas détailler les sessions que j’ai suivies, pour dormir un peu avant la seconde journée, mais en donner un bref résumé.

J’ai suivis trois sessions sur la sécurité :

• Pattern Driven Security Design, for Web Tier, par Manish Kumar Maheshwari
  VeriSign Services : Il ne s’agissait que de revenir sur les patterns de JAAS et/ou d’évoquer leurs alternatives à base de framework, en particulier Spring Security
• Framework & Security : how web applications frameworks kill your security scanning : Christian Hang Armorize Technologies
  Cette session parlait essentiellement des outils de SCA (Static Code Analysis) qui essaient de détecter les failles de sécurité dans votre code pour que vous les corrigiez. Il explique les mécanismes qu’utilisent ces CSA et montre qu’il y a des problèmes quand le code qui est analysé utilise de la reflexion, ou des suites d’invocation avec propagation de contexte (lors d’un forward de requête par exemple). C’est évidemment le cas quand vous utilisez un framework comme Spring, Struts, … Il montre enfin quelque pistes pour essayer de rendre les SCA compatibles avec l’usage des frameworks.
• Security as intrisinc part of any Java EE developement, Wolfgang Giersche : Parmi les limites de JAAS, il y a le fait que les rôles sont des chaines de caractères prévues à l’avance et que l’on ne peut en rajouter. Le speaker montre ici qu’il y a des patterns et des efforts de standardisation (XSPA Profile for XACML) de définition sémantique de politique d’accès, qui permettent de définir applicativement des nouveaux rôles, avec une définition dynamique des habilitations.

J’ai suivi ensuite une session de Neal Ford sur les DSL. Il nous a appris entre autre que Java n’est pas forcément pertinent pour faire des DSL internes, c’est-à-dire des DSL qui s’expriment en Java. On peut par contre, faire un programme en Java, qui interprète un DSL en Groovy par exemple.

La dernière session suivie par moi de la journée était menée par Jevgeni Kabanov, le CTO de ZeroTurnaround, la société qui édite JRebel, l’outil magique qui modifie le runtime en même temps que vous modifiez votre code, à la barbe de la JVM. Cette session était intitulée « Do you really get class loader ».

En ce qui me concerne, je croyais que c’était le cas, mais j’ai quand même appris des choses très intéressantes.
Jevgeni a dit qu’il est amoureux des classloaders.

Il explique que l’exception qui est faite, dans le cas des serveurs d’application qui fait qu’une classe est recherchée en premier dans les classloaders des webapps avant les classloaders parent est source de nombre de bugs et il nous le montre dans plusieurs cas unitaires.
Il nous recommande de reconnaître les différentes exceptions et de savoir comment elles peuvent arriver (eg. java.lang.LinkageError) et penser qu’on peut accéder au chemin d’une classe en faisant :

 this.getClass().getClassLoader().getRessource(MaClasseACharger.class.getName()).replace('.', "/")

et souvent on peut récupérer le classpath en faisant :

 ((URLClassLoader)getClass().getClassLoader()).getURLs()

Il nous a montré aussi comment reproduire (facilement) les leaks memory que l’on obtient sous Tomcat.

Keynote de fermeture : 97 Things Every Programmer should know, Kevlin Henney

Kevlin Henney a d’abord passé un peu de temps à expliquer pourquoi et comment il avait écrit ce livre, avant d’aborder un certain nombre d’items.

Il a écrit ce bouquin pour savoir ce que les autres pensent, par rapport au codage, puis parce qu’il s’est rendu compte qu’en demandant les dix items les plus importants on passait à côté de beaucoup de choses.

Pourquoi 97 ? Il répond souvent que c’est parceque 97 est premier, puis que ce livre fait tout bêtement parti d’une série de livre qui s’appellent tous comme cela.

C’est à ce moment que je suis tombé en rade de batterie, donc je vous laisse découvrir la liste sur le wiki du livre.

Il a évoqué lors de cette énumération le fait que le singleton sur cette image a été souvent meilleur que le pattern singleton.

Maintenant je vais me reposer pour être en forme pour vous prendre en notes les conférences de demain.

N’hésitez pas à partager vos impressions ou vos retours via le forum : http://www.developpez.net/forums/d841589/java/communaute-java/jazoon10-1er-3-juin-y-va-quen-pensez/

Voici l’annonce rien que pour vous : James Gosling

Après la mise en ligne et l’enrichissement de JavaSearch (idée originale de Laurent Perron, maintenu par Baptiste Wicht), l’équipe Java a le plaisir de vous annoncer ce nouveau service que nous mettons à dispositions gratuitement à nos partenaires et contributeurs bénéficiant déjà d’un hébergement classique.

Parmi les heureux bénéficiaires, on retrouve notamment 2 JUGs :

• Le Tours JUG
• Le Lyon JUG

Ces 2 JUGs ont choisi XWiki comme outil, et l’équipe Java leur met à disposition, tout comme le fait XWiki SAS pour l’ensemble des JUGs, à la seule nuance près que nous ne nous limitons (limiterons) pas à cette technologie et accompagnerons ces communautés tout au long de leur évolution et ceci quelle que soit la solution logicielle retenue (pourvu qu’elle repose sur Java).
Avis aux autres JUGs francophones naissants ou déjà existants, n’hésitez pas à nous contacter via le forum ou par email.

Mais l’hébergement Java prend également une autre forme : celle de la mise en ligne d’applications de type démo
Vous trouverez une première démo illustrant l’article CRUD avec JSF et JPA de Jawher Moussa à l’adresse suivante : http://demo.java.developpez.com/crud-jsf-jpa/ (ne cherchez pas, il n’y a rien pour l’instant sur la home du domaine demo). Cette possibilité sera désormais offerte à tous les rédacteurs de l’équipe Java souhaitant illustrer leurs publications par des exemples concrets.

Je tiens tout particulièrement à remercier lunatix, administrateur bénévole de cet hébergement, sans qui tout ceci ne serait possible, ainsi que les membres de l’équipe bénévole Java participant à ce projet, mais également les administrateurs de Developpez.com pour l’aide à la mise en place.

Si vous avez des remarques constructives, l’envie de participer à ce projet en apportant vos idées et votre aide, n’hésitez pas à revenir vers nous que ce soit ici, par message privé sur le forum, ou par mail, car nous ne nous arrêterons bien sur pas là

Pour la rubrique Java
Eric

Vos commentaires

Cette session de 2h, qui aura lieu à l’Ecole des Mines de Nantes, est intitulée GlassFish v3, en route pour Java EE 6 et le développement Java indolore!. Elle sera certainement très riche en information et l’occasion pour les heureux participants de découvrir l’environnement modulaire basé GlassFish v3 Prelude sur OSGi.

Pour vous inscrire (actuellement 23 inscrits !) suivez ce lien

N’oubliez pas qu’Alexis est présent sur les forums Developpez et se fera un plaisir de répondre à vos questions techniques dans le forum GlassFish.

Le Keynote commence par une présentation de Joshua Bloch, l’auteur du livre « Java Efficace ». C’est vraiment un speaker doué pour faire passer simplement un message complexe. Il a présenté quelques cas issus de son livre : les collections et notamment l’utilisation de super et extends dans les Generics., les bonnes pratiques sur les énumerations et enfin un tips sur la Lazy Initialisation.

Dans la seconde partie du keynote, Mark Reinhold a parlé de Java 7. La modularisation de Java avec l’abandon de la JSR 277 pour le projet Jigsaw qui sera compatible avec OSGi. Il a aussi parlé de ce qui pourrait être et ne sera pas dans Java 7. Dans les élus on trouve la modularisation (JSR 294 + Jigsaw), les langages dynamiques (JSR 292), new new I/O (JSR 203 avec enfin une vraie API pour le filesystem), et quelques changement du langages (JSR à determiner). Ces changements sont le safe rethrow, l’inférence de type, le multicatch. Swing n’est pas mort, il y aura aussi le Swing Application Framework (JSR 296).

Enfin, autre sujet polémique, il y aura un Forward port des fonctions de Java 6u10 dans Open JDK ( Java Kernel, QuickStart, plugin…)
Dans les changements plus petits on trouve un upgrade de l’architecture du ClassLoader, support Unicode 5, des changements à Swing (JXLayer, DataPicker et peut être le CSS Styling).

Il y aura aussi des améliorations de performances de la JVM (G1 Garbage collector, compressed Pointer 64 Bits, Multiple Virtual Machine…).

Pour les améliorations ne venant pas de SUN, il y aura les annotations sur les types Java (JSR 308 avec son @NonNull), et les améliorations à la concurrence et aux Collections de Doug Lea et Josh Bloch.

Pour ce que l’on ne trouvera pas dans Java7, il y aura les closures (deux ans de discussions n’ont pas permis d’atteindre un accord), first-class properties, les « reifed generics », la surcharge d’opérateur. Bean Binding (JSR 295) est aussi exclu car cela devient trop complexe. Cela tombera sans doute en faveur d’une solution plus simple comme le bind de JavaFX.

Enfin le plus important la sortie est pour début 2010.

Ensuite, Stephan Janssen a pris la parole pour donner quelques infos sur la conférence.
L’équipe de JavaFX a pris la parole pour une présentation rapide des capacités de JavaFX et la liste de Danny Coward sur les 10 points important de JavaFX.
Le second sponsor a parler était IBM pour l’utilisation du RFID cette année à la conférence. Cela permet de savoir quelles sont les présentations attirant les foules et quelles sont celles dont les gens s’enfuient vite…..

Ma première session technique était sur les patterns de sécurité en entreprise. Après une présentation des failles classiques (injection sql, XSS…) nous avons eu une présentation des patterns comme l’intercepteur (utilisé dans les Bean Validator de la JSR 303) ou le SAO (Single Access Point) et dont l’opposé est SOA (Surely Open Access…)

Le midi, un petit Quicky sur l’utilisation de Derby et les Tables Function ou Virtual Table qui permettent par exemple de rechercher rapidement les différences entre des fichiers de localisation.

Après la pause déjeuner, j’ai commencé par une présentation sur « Effective Pairing ». Le présentateur faisait descendre sur scène des personnes ayant eu un problème avec le pair-programming pour le mettre en scène et ensuite parler du problème. J’ai assisté au deux premières mises en scène, mais la mauvaise utilisation du micro rendait l’expérience difficile. De plus le speaker présentait la difficulté rencontrée mais ne donnait pas vraiment de solution….

J’ai donc fuit la présentation après 20 minutes pour aller errer du coté des stands. J’ai alors discuté avec VIncent Massol qui m’a fait une présentation de Xclipse et des dernières nouveautés de XWiki depuis le repository….. Il y a vraiment des nouveautés puissantes sur lesquelles je prendrai le temps de revenir.

Comme 2009 est aussi l’année de Android, je suis allé voir Romain Guy pour sa présentation sur « filthy rich client with Android ». Peu d’effets cette année car il a passé plus de temps à expliquer l’API de Android notamment les différences avec celle de Swing.

Enfin j’ai fini la série des conférences par une session sur Web Beans. Les exemples choisis n’étais pas forcément judicieux à mon gout et surtout j’en suis sorti plutôt inquiet en pensant aux longues journées de débuggage qui nous attentent. Le container fait de l’injection, outjection sur tout un tas d’annotation qu’on peut en plus redéfinir. J’ai peur que cela ressemble trop à une tentative de faire une puzzle en mettant un ensemble de pièces dans une boite et en secouant fort.

Après la session était le Meet and Greets avec Frites et Bière à volonté. Il y avait aussi le JUG Leader BOF. Les JUG Européens sont en train de s’organiser, on devrait voir des initiatives intéressantes pour 2010. Pour nos amis du sud de la France, si les choses se concrétisent, vous devriez prochainement avoir deux JUG.

Le midi j’ai vu deux morceaux de Quickies sur le développement d’un jeu en JavaFX et l’utilisation de JDBC dans JavaFX.

L’après midi, j’ai fait un morceau de la session sur GWT puis je suis sorti me battre avec le Wifi pour poster mon blog d’hier. J’ai finalement fini l’après midi en discussion entre les stands et dans les couloirs.

La soirée s’est terminée par un diner organisé entre les speakers, les sponsors et les JUG Leaders. L’occasion de discuter des différentes organisations des JUGs, des différences culturelles entre les différents pays (carrière de développeurs, formation par les entreprises…), rencontrer quelques « stars » de mon aggrégateur de flux et naturellement boire des bières Belges.

Aujourd’hui, c’est Keynote, puis le début des conférences, des sessions de 1 heure qui seront plus techniques que l’université, mais c’est pour un autre billet. Le wifi ayant fait des progrès dans la nuit, nous pourrons poster plus souvent.