Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Agilité

• Votre équipe est-elle cross-fonctionnelle ?

RIA

• Un état de l’art, vu par les évangélistes.
• La bataille (des annonces) fait rage dans l’univers Mobile.

Le coin de la technique

• Sortie de Spring 3.0 M2
• Sortie de GridGain 2.1.1
• Un petit GIN ?
• L’initiative Swing 2 critiquée

Agilité

Votre équipe est-elle cross-fonctionnelle ?

Dans cet article, Henrik Kniberg nous rappelle la signification d’avoir une équipe cross-fonctionnelle. Cela ne signifie en aucun cas que tous les membres de l’équipe doivent posséder toutes les connaissances. C’est l’équipe dans son ensemble qui doit posséder les connaissances nécessaires à la mise en place du produit.
Ensuite, il propose une méthode afin de répertorier les connaissances de chacun. Il en résulte une simple matrice où les membres de l’équipe listent leurs connaissances ainsi que leur niveau :

• Etoile : principale domaine d’expertise
• Point : quelques connaissances
• Vide : aucune connaissance et/ou ne veut pas acquérir de connaissance sur ce domaine

Cette matrice possède l’avantage d’identifier rapidement une ‘ressource’ et donc de faciliter le partage. Cela permet aussi de répertorier les personnes voulant progresser dans d’autres domaines. Voilà une idée simple et efficace !

RIA

Un état de l’art, vu par les évangélistes.

En résonance au RIA contest de Xebia (réalisé par des architectes / développeurs, autour du développement d’une application), InfoQ a organisé un panel (basé sur une série de question) avec six acteurs majeurs du monde RIA, un pour chaque framework (Ajax, GWT, Curl, Flex, Silverlight, JavaFx).
Faute de débat contradictoire (les participants ont été interviewés par email), on a l’impression que chacun prêche pour sa chapelle et il ne ressort pas grand chose de cette étude que l’on ne sache déjà. Cependant, cet article reste un bon point de départ pour ceux qui aurait raté les développements récents du marché des RIA.

Même problématique, approches différentes : Sony Mathew, architecte chez Prime Therapeutics, a comparé, sous forme matricielle, les forces / faiblesses de quelques uns de ces frameworks (GWT, Flex, Lazlo, Ajax ‘pur’). Une aide au choix de plus.

Quoi qu’il en soit, il est clair que la bataille des RIA sera l’un des sujets majeurs de 2009 (après avoir agité une bonne partie de 2008), et que celui (ou ceux) qui ne sera pas présent sur la scène, aussi bien marketing (pour convaincre les décideurs), que technique et communautaire (pour rallier les développeurs), risque la marginalisation à l’horizon 2010.

La bataille (des annonces) fait rage dans l’univers Mobile.

Après la sortie de JavaFx mobile, c’est au tour d’Adobe d’annoncer une avancée pour Flash (et indirectement Flex) dans le monde des smartphones. Flash 10 sera disponible nativement, en version complète sur une très grande majorité de plate formes en 2010 : Windows Mobile, Android, Nokia S60/Symbian, et Palm webOS (à l’exclusion de l’iPhone, mis sous coupe réglée par Apple). Celà ne signifie pas l’abandon de Flash Lite, mais compromet sérieusement les chances du modèle de déploiement ‘à la demande’ qu’Adobe a vainement tenté d’imposer (en grande partie à cause du poids du player Flash Lite).
Coté Microsoft, Silverlight 2 Mobile reste pour l’instant un voeu pieux.

Le coin de la technique

Sortie de Spring 3.0 M2

Notons cette semaine la sortie du second milestone de Spring 3.0. Chaque nouvelle version majeure de ce framework fait vibrer la communauté. Nous n’avons pas dérogé à la règle. Vous avez d’ailleurs probablement constaté que nous étions fiers de vous faire de découvrir les nouveautés de cette prochaine version 3.0. Nous avons ensuite profité de la sortie de la M1 pour consolider nos dire. Cette fois-ci, nous ne nous éterniserons pas sur la sortie de la M2. Elle n’apporte que peu de réelles nouveautés que nous n’ayons déjà annoncées (la principale concerne à notre sens le support de JPA 2). Notez juste qu’elle est sortie. Relevez également que cette M2 sera suivie d’un troisième et dernier milestone.

Sortie de GridGain 2.1.1

La plateforme de cloud computing qui monte, GridGain, vient de sortir en version 2.1.1. Il s’agit d’une version de stabilisation et d’amélioration. Peu de nouveautés donc, mais plusieurs correctifs de bug levés depuis la 2.1. Pour rappel, GridGain offre une intégration à Spring ainsi qu’un jeu d’annotations permettant de « gridifier » facilement et rapidement une application.

La possiblité de lancer vos tests unitaires JUnit 3 ou 4 sur une grille d’agents GridGain, moyennant une simple annotation de votre suite de tests, est très intéressante également. Pour ceux qui ne connaissent pas encore ce produit, c’est l’occasion de télécharger cette dernière version à la stabilité accrue.

Un petit GIN ?

GIN (GWT INjection) n’est autre que Guice pour GWT côté client (vu sur onGwt).

Comme d’habitude en GWT, l’utilisation d’une nouvelle librairie passe par la case module.xml et l’ajout d’une nouvelle entrée inherits :

Il faudra ensuite coder la classe module afin de configurer le binding de nos classes. Cette classe devra étendre AbstractGinModule :

public class MyWidgetClientModule extends AbstractGinModule {  
   protected void configure() { 
      bind(MyWidgetMainPanel.class).in(Singleton.class);    
      bind(MyRemoteService.class).toProvider(MyRemoteServiceProvider.class); 
   }
}

L’adaptation GWT de Guice se fait par la création d’une interface qui étend Ginjector.
Celle-ci définit les objets à récupérer (par des getters) ainsi que le module qui lui est appliqué (ici MyWidgetClientModule) par l’annotation @GinModules.
On obtient ainsi un injecteur tel que :

@GinModules(MyWidgetClientModule.class)
public interface MyWidgetGinjector extends Ginjector {
   MyWidgetMainPanel getMainPanel();
}

Cet injecteur est alors instancié par GWT.create(class) que l’on pourra alors utiliser pour récupérer notre panel :

public class MyWidget implements EntryPoint {
   private final MyWidgetGinjector injector = GWT.create(MyWidgetGinjector.class);  
   public void onModuleLoad() {    
      MyWidgetMainPanel mainPanel = injector.getMainPanel();    
      RootPanel.get().add(mainPanel);  
   }
}

Les exemples ci-dessus se trouve sur cette page, une petite FAQ est aussi à disposition.

Néanmoins, on peut toujours s’étonner du choix de Google de mettre en avant l’intégration avec Struts 2 (sous forme de plugin) plutôt qu’avec GWT (Gin est maintenu par une équipe distincte de celle de Guice, même si certains membres appartiennent aux deux équipes).

L’initiative Swing 2 critiquée

L’API Swing a évolué au cours des dernières années : ses performances se sont améliorées, elle a gagné en composants graphiques et constitue actuellement, malgré les investissements de Sun dans JavaFX, un choix privilégié pour le développement de clients lourds. Malgré tout, comme toute API vieillissante, on lui reproche souvent son manque de productivité et sa complexité parfois inutile.

Il y a un mois nous vous parlions du projet Swing 2 initié par Jonathan Giles suite à son très médiatisé billet. Depuis, on compte une cinquantaine de commits sur le SVN du projet. Le but affiché est de rafraîchir l’API de Swing en profitant de certaines nouveautés de Java 5 (generics, enums et varargs). Dans la pratique, il s’agit ni plus ni moins d’un fork open source de Swing. La démarche est pour le moins audacieuse et comme on pouvait s’y attendre, un certain nombre de réactions sont apparues au sein de la communauté.

Rapidement, Danny Coward, représentant Sun, s’est exprimé sur ce projet et sur les demandes d’évolution de Swing de manière générale, en affichant ses réserves quant à une cassure de la compatibilité ascendante de l’API, bien que reconnaissant le besoin réel d’amélioration. Il citait malgré tout la possibilité de s’appuyer sur Jigsaw, à partir du JDK 7, pour permettre l’utilisation conjointe de deux APIs incompatibles.

Elliott Hughes, jugeant la réaction de Sun assez légère et peu engagée, a émis une critique sévère de l’initiative Swing 2 en lui reprochant principalement son inutilité : aucun des problèmes qu’il rencontre au quotidien en utilisant Swing ne se trouve réglé par l’ajout de generics ou d’enums. Dès lors, ce travail de refonte manquerait d’intérêt puisqu’il n’atteindrait pas sa cible.

Que peut-on dire sur ces critiques ? En fait, il est clair que le véritable problème de Swing est que l’API proposée aux développeurs reste bas niveau et, en raison de son âge, repose sur des principes de designs qui peuvent sembler lourds en comparaison des frameworks ultra productifs que l’on trouve autour de JEE de nos jours. Lui faire profiter des nouveautés de Java 5 ne ferait donc que partiellement camoufler ces défauts. Mais si l’API n’évolue pas, faut-il abandonner Swing pour autant ? Cela semble surréaliste du fait de la capitalisation des développeurs, des éditeurs et des entreprises autour de cette technologie, d’autant qu’elle remplit parfaitement son rôle. La solution intermédiaire entre révolution et immobilité pourrait se trouver dans la multitude de librairies qui s’est créée autour de Swing depuis quelques années, permettant de simplifier le travail du développeur (nouveaux layouts, nouveaux composants, utilitaires et support pour IDE).

Quelle que soit l’issue de la démarche, le projet Swing 2 aura attiré l’attention de la communauté sur cette problématique et provoqué de nombreux débats susceptibles d’amener des idées neuves sur le sujet.