Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Sortie de VirtualBox 2.0

Agilité

• Martin Fowler à propos de Scrum

RIA

• ActionScript 3 vu par les programmeurs Java

Le coin de la technique

• Comparaison avec le code de Wicket à GWT
• Liste de question à se poser lors du choix d’un framework d’application de bureau

Evènements de notre communauté en France et à l’étranger

• Forum SOA 2008
• Soirée Groovy au Paris JUG ce Mardi 09 Septembre

Actualité éditeurs / SSII

Sortie de VirtualBox 2.0

Cette semaine est sortie la première évolution de VirtualBox depuis l’acquisition d’InnoTek par Sun en février dernier. Pour mémoire, VirtualBox est disponible sous licence GPL depuis janvier 2007 et se positionne comme concurrent sérieux à VMware, VirtualPC, QEmu ou Xen. Un tableau comparatif avec VMWare est d’ailleurs disponible sur le site officiel ou vous pouvez également y retrouver la liste des systèmes d’exploitation compatibles.

La principale nouveauté de cette version 2.0 est la gestion des hôtes 64 bits.

Autres nouveautés notables :

• L’interface a été refaite : montée de version de QT (QT4) améliorant l’intégration avec Gnome et utilisation de l’interface native sous Mac OS X
• Support Native Command Queuing améliorant les performances des disques durs SATA
• Structure permettant la collecte d’informations sur l’utilisation des ressources des machines virtuelles
• Nouveau système d’avertissement de mises à jour
• Nouveau kit de développement
• Compatibilité avec les images ‘Microsoft VHD’ utilisées par Virtual PC

Agilité

Martin Fowler à propos de Scrum

Martin Fowler est interviewé par Jacky Li d’InfoQ China sur Scrum et le futur de l’Agile. À retenir :

• L’adoption des méthodes agiles est particulièrement difficile à cause des changements de mentalité que cela implique. Beaucoup de monde se concentre sur les pratiques plutôt que sur la philosophie, ce qui aboutit généralement à l’échec de l’adoption.
• Les impacts de l’Agilité se sentiront dans plusieurs décennies. En comparaison, la Programmation Orientée Object – apparue il y a 40 ans – a mis 20 ans à devenir le courant principal, et encore même aujourd’hui le code est écrit en Java mais il n’est pas orienté Objet.
• La certification Scrum dure seulement 2 jours et le terme « certification » peut tromper. Comprendre l’Agilité reste un exercice qui nécessite plusieurs mois. Cependant, c’est un bon début pour apprendre car les formateurs Scrum connaissent vraiment leur sujet, ce qui n’est pas le cas dans beaucoup d’autres technologies, par exemple RUP ou CMM.

En conclusion, Martin acquiesce que ce qui importe n’est pas de savoir « si un projet est agile » mais plutôt « comment s’améliorer ».

RIA

ActionScript 3 vu par les programmeurs Java

Avouons-le, les interfaces graphiques n’ont jamais été la tasse de thé des équipes de développement Java. Les succès relativement limités de Swing, Awt le prouvent.

Aujourd’hui, c’est Flex qui tient la tête des RIA émergents.

Alors qu’en est-il de son appropriation par les équipes Java ? Pour InfoQ, Jack Herrington donne des pistes de comparaison.
Nous ne nous attarderons pas dans cette revue presse sur les différences syntaxiques, mais plutôt sur les similitudes (ou les divergences) structurelles.

• Les classes : les deux langages sont des langages objets. Ils utilisent tous deux des espaces de nommage et la notion de package. Les imports, les variables de classe, les notions de public / private, les constructeurs vides ou valués, et les méthodes de classe sont aussi au rendez-vous.
  Une différence cependant : les getters / setters des variables de classe sont des méthodes particulières et réservées. Elles ont leur déclaration propre et leur appel se fait de manière transparente (on appelle myClass.myProperty même si en fait c’est le getter de myProperty qui est appelé).
  Autre différence notable, à la manière de Swing, on peut déclarer un objet comme EventDispatcher : celui-ci lance alors des évènements (sur le changement d’une variable par exemple) qui peuvent être intercepté à plus haut niveau, par un mécanisme d’abonnement.
• Interface : nouvelle « facilité » offerte par l’AS, les interfaces peuvent comporter des « variables ». En effet, en déclarant des getters / setters dans les interfaces, on donne l’illusion d’accéder à des « variables » déclarées par l’interface.
  On a donc une syntaxe du type myInterface.myProperty (au lieu d’utiliser en java le _getMyProperty()_).
• Constantes : le mot clé final est remplacé par le mot clé _const_
• Variables statiques, Exceptions. Rien de notable
• Héritage : le mot clé abstract est remplacé par le mot clé virtual. Le principe est identique.
• Itérateurs : AS ne propose pas de conteneurs fortement typés, comme les Tree, les Map. Cependant, on peut utiliser le type Objet{} et itérer sur ses attributs, comme on le ferait sur les clés d’une Map.
• Expressions régulières : les expressions régulières sont interprétées dans le code AS. On peut les utiliser pour manipuler par exemple des chaînes de caractères (rechercher dans une chaînes , scinder une chaînes…)
• E4X : l’une des différences les plus notables à ce jour est l’intégration du Xml dans ActionScript. Le parcours ou l’écriture d’un fichier est vraiment intuitif, grâce à l’utilisation des fonctions d’itération ou conditionnelles « standard ».

En conclusion, passer de Java à ActionScript ne devrait pas représenter un traumatisme trop grand. Mais entre posséder les bases et posséder l’ensemble des subtilités du langage, il faut rester méfiant, et une nouvelle race de développeurs de haut niveau pur ‘Flex’ fera probablement bientôt son apparition.

Pour retrouver l’intégralité de cet article et ses nombreux exemples, rendez-vous sur InfoQ

Le coin de la technique

Comparaison avec le code de Wicket à GWT

Dans l’article Wicket and GWT compared with code, Peter Thomas compare deux technologies qui font parler d’elles depuis quelques temps : GWT (Google) et Wicket (Apache)

Il est vrai que ces deux technlogies ont des points techniques en commun :

• GWT et Wicket privilégient la programmation événementielle en Java (à la Swing) plutôt que la programmation déclarative (à la JSP ou JSF)
• Ils ont un modèle de composants (ensemble de Panels et de _Widgets_)
• Ils ont un modèle de composants extensibles

Cependant, ils se différencient sur plusieurs points :

• Lors de la phase de compilation, GWT analyse le code pour générer une interface Web en DHTML
• Wicket exécute le code Java pour construire les composants, lorsque l’application Web est déployée
• Wicket utilise le templating HTML et les Widgets pour faciliter la réalisation des pages. GWT utilise de manière intensive la technologie CSS.

Peter Thomas nous présente ses conclusions à travers 13 points :

1. Wicket nous permet un contrôle complet sur le rendu HTML. De manière générale, en GWT, pour avoir une maîtrise complète du rendu HTML il faut être un virtuose de la technologie CSS.
2. Il est vrai qu’en GWT, il existe une impedance mismatch entre le langage Java et Javscript (Reflexion, synchronized, …). Dans certains cas, on doit effectuer des contournements de programmation en Java pour pouvoir effectuer le traitement en Javascript.
3. En GWT différentes pratiques doivent être réfléchies, conçues et mises en place pour effectuer de manière élégante certaines implémentations, à l’image du binding dynamique dans une table
4. Il faut maitriser la technolologie CSS pour maitriser le rendu GWT , ce qui n’est pas toujours évident
5. Un point de différence important entre GWT et Wicket et la gestion des Layouts. Wicket gère en priorité les Layouts par le templating HTML tandis que GWT passe par des objets de son modèle de composants : Layout. Cependant, il reste possible dans GWT, de définir un Layout dans la page HTML est d’injecter N composants GWT dans les balises HTML de cette page (code GWT : RootPanel.get("slot1").add(button))
6. Le débogage en GWT n’est pas toujours évident car il est difficilement possible de voir les sources (view source dans le navigateur). Cependant, l’outil de développement GWTHost fonctionne bien et s’intègre très facilement à l’IDE Eclipse pour le débogage.
7. Une démonstration de la réutilisation du code est faite dans Wicket, qui est un de ses points forts. Des bonnes pratiques de conception sur des applications classiques peuvent être réutilisées pour l’interface graphique.
8. Une difficulté avec GWT est son fonctionnement au premier abord un peu déroutant : la génération de code DHTML à partir du code source Java. Il faut en être conscient et connaître toutes les conséquences (maîtrise des instances d’objets dans le code Java GWT).
9. Avec Wicket, la gestion des URLS bookmarkable demande un effort supplémentaire.
10. Il est évident qu’une compilation de source GWT est plus lente qu’une compilation de source Wicket. Cependant, ce critère n’est pas important mais révèle un aspect important actuellement négligé dans GWT : le packaging et l’organisation des sources, surtout lorsque GWT s’intègre dans un existant conséquent (avec par exemple des objets métiers éparpillés dans les différents projets de sources).
11. Grâce à GWT 1.5 et au support du langage 1.5, l’observation précédente peut être plus facilement gérée
12. Un avantage certain de GWT est le fait d’être déconnecté du serveur ce qui permet un gain important de performance à l’exécution. Cependant, le développement et debogage des appels distants n’est pas toujours intuitifs. Il faut aussi faire attention à l’intégration dans un existant avec une forte responsabilité graphique du serveur (JSP/Servlet). Par exemple, même si des efforts ont été entrepris par la communauté GWT (hibernate4gwt), pour intégrer des acquis dans cette nouvelle technologie GWT, il reste comme même des régressions dans l’intégration du client au serveur.
13. Il reste cependant difficile d’effectuer des tests unitaires sur les interfaces graphiques … on est trop proche du fonctionnel

Wicket et GWT ont fait le choix audacieux de choisir un langage familier pour le développement d’application Web en Java. C’est un énorme avantage. Il faut reconnaître que si GWT introduit de nouveaux problèmes du fait de ces choix techniques, il permet de produire des applications Web de manière très productive. Il permet à un développeur Java de produire des applications Web qu’il aurait eu énormément de mal à réaliser avec des technologies plus classiques (JSP, HTML, Javascript, …). GWT et Wicket permettent de populariser le développement pour les purs et durs du développement Java.

Liens connexes :
– Blog de Bruno Marchesson qui analyse de manière très critique et argurmentée GWT

Liste de question à se poser lors du choix d’un framework d’application de bureau

Geertjan Wielenga nous propose une liste de questions à se poser lors du choix d’un framework RCP.

Les questions sont regroupées par catégorie :

• Architecture : Niveau de scalabilité, de flexibilité ? Comment le framework s’intègre avec d’autres frameworks existant ?
• Liste de fonctionnalité : Est-ce que le framework prend en charge un maximum de plomberie pour lier les différentes couches de l’application ? Est-il facile d’étendre la liste des fonctionnalités ?
• Open Source : Est-ce que l’open source s’inscrit dans votre stratégie d’entreprise ? Est-ce que l’Open Source vous fait peur ?
• Communauté : La communauté de développeurs est-elle active ? Le framework a t-il été utilisé et epprouvé dans le cadre d’une application « réelle » ? Quels sont leurs retours d’expérience sur son utilisation ?
• Période d’apprentissage : Est-elle conséquente ? Si oui, est-elle contrebalancée par les gains qu’apporte le framework ? Existe t-il une formation ?
• Outillage : Intégration avec un IDE (niveau ? Quel(s) IDE ?) Y a t-il de la génération automatique ou aide à la complétion de code ?
• Documentation : Existe t-elle ? Est-elle à jour, complète ? Y a t-il des livres (combien) traitant du sujet ?
• Support : Évaluer la rapidité (en fonction de la communauté et de la documentation) de traitement d’une question ? Existe t-il une mailing-list, un forum, un help desk ? Des patchs sont-ils livrés ou la correction d’un bug doit-elle attendre une RC ?
• Future : Quel est l’avenir du framework ? Quelle est la stratégie long terme de la société investissant dans le framework ?

La catégorie Productivité (rapidité de développement ? Nombre d’écrans développés par sprint ?) pourrait compléter cette liste pour qualifier un framework.
Les questions étant assez génériques, cette liste d’interrogations ne se limite pas seulement au choix d’un framework d’applications de bureau, ce questions reviennent lors de la sélection d’autres types de framework (MVC, RIA…).

Evènements de notre communauté en France et à l’étranger

Forum SOA 2008

Pour la troisième année consécutive, le monde informatique organise le Forum SOA.
L’édition 2008 se tiendra le 9 octobre 2008 à Paris (à l’Eurosite George V) et a pour thème « Des processus et des hommes ».
Le programme est disponible sur le site de l’événement.

Soirée Groovy au Paris JUG ce Mardi 09 Septembre

Groovy est à l’honneur pour la rentrée du Paris JUG, avec les venues de :

• Guillaume Laforge, VP Technology chez G2One, qui va nous présenter Groovy, le langage dynamique pour la machine virtuelle Java qui permet d’accroître la productivité des développements
• Fabrice Robini architecte chez OCTO, qui va nous présenter le framework web Grails, basé sur Groovy, qui permet là aussi de bénéficier de l’apport de productivité de Groovy, et d’un maximum de « Convention over configuration »

Pour la description de la soirée et les inscriptions, c’est par ici.