Vu les pointures qu'on croise à SpringOne, j'aurais été fou de me priver de poser des questions. Des questions naïves de préférence, lancées un peu au hasard, mais qui peuvent fournir des réponses intéressantes, voire un scoop ou deux.

J'ai d'abord demandé à Guillaume Laforge ce que l'inclusion de la fonction invokedynamics dans Java7 changerait pour Groovy.
Guillaume explique que le processus de résolution des méthodes (qui permet de déterminer quel bytecode exécuter à l'appel d'une méthode) est relativement coûteux en Groovy : non seulement le langage Java lui-même est complexe (var-args, génériques, promotion des types des paramètres, covariance, overloading/overriding...), mais Groovy ajoute encore des niveaux d'indirection (Metaclass, GroovyObject, conversion des GStrings en Strings...).
Depuis Groovy 1.6, le résultat de la résolution est mis en cache, ce qui se traduit par des gains de performance importants. Dans Groovy 1.7, la nouvelle méthode invokedynamic permettra de placer (au niveau bytecode) des liens directs vers les méthodes une fois celles-ci résolues ; Guillaume s'attend donc à des performances très proches de celles de Java.

Ensuite, j'ai interviewé Keith Donald, créateur de SpringWebFlow, àa la sortie d'une session de présentation sur ce framework.
Actuellement, la configuration des flows est réalisée grâce à des fichiers de configuration XML, ce que je trouve très verbeux et peu pratique pour exprimer les traitements à exécuter lors des transitions entre les étapes (il faut utiliser des expressions type EL). D'où la question bête : un système alternatif est-il prévu ?
Tenez-vous bien, il y en a même deux :

• Par annotations sur des POJOs, à la mode SpringMVC : @Flow, @Transition...
• En Groovy

Ces deux nouveautés devraient être annoncées avant SpringOne, c'est-à-dire dans deux mois. En attendant, faites comme si vous n'aviez rien entendu !

Enfin, j'ai coincé et monopolisé Jürgen Höller en personne (et retardé involontairement la session suivante) pour l'interroger sur sa vision du portfolio web de SpringSource dans son ensemble.

• SpringSource compte-t-il développer son propre framework web par composants ? Apparemment, ce n'est pas prévu car le besoin ne s'en fait pas sentir : il y a déjà JSF, Wicket, Tapestry... SpringSource préfère donc travailler de concert avec leurs communautés respectives pour s'assurer de la qualité de leur bonne intégration avec Spring ("play nice with the community").
• Et qu'en est-il d'un système de templating HTML ? Pour le moment, l'intégration avec Tiles2 est disponible, mais Jürgen n'est pas très satisfait de la qualité de ce framework ni de la stabilité de son API (beaucoup de changements entre les versions 2.0 et 2.1 par exemple). L'effort d'intégration devrait donc être maintenu pendant les quelques mois restant avant la sortie de Spring 3.0, mais si le résultat est décevant, il n'est pas impossible que SpringSource se retrousse les manches et développe une solution maison.

Et pour le fun : Rod Johnson au piano, utilisant son PC comme une partition !