SpringOne, question pour des champions

29 avril 2009 Olivier Croisier

Vu les pointures qu’on croise à SpringOne, on serait fou de se 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.

Nous avons 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 dse 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, nous avons interviewé Keith Donald, créateur de SpringWebFlow.
Actuellement, la configuration des flows est réalisée grâce à des fichiers de configuration XML, ce qui est très verbeux et peu pratique pour exprimer les traitements à exécuter lors des transitions entre les étapes. D’où la question bête : un système alternatif est-il prévu ?
En réalité, 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. Mais chut, ne le répétez pas !
Enfin, nous avons coincé et monopolisé Jürgen Höller en personne 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 ? Ce n’est pas prévu car le besoin ne s’en fait pas sentir. Ils préfèrent donc travailler de concert avec les communautés des frameworks existants pour s’assurer de la qualité de leur 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.

Enfin, dernier scoop : Rod Johson au piano, utilisant son PC comme lecteur de partition !