RIA

• Inquiétude de la communauté Flex suite aux annonces d’Adobe

Le coin de la technique

• Sortie de JQuery 1.7

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

• CITCON London 2011

RIA

Inquiétude de la communauté Flex suite aux annonces d’Adobe

La semaine dernière, il y a eu beaucoup de confusions, et de rumeurs suite aux diverses annonces d’Adobe concernant Flash, Flex et HTML5. Tout a commencé lorsqu’Adobe a annoncé la semaine dernière l’abandon de Flash Player pour mobile. Une vague de rumeurs et de confusions s’est alors abattue un peu partout, certaines personnes confondant le Flash Player avec la solution AIR pour mobile qu’Adobe ne compte pas abandonner. Tout aurait pu s’arrêter là mais c’était sans compter sur les autres communiqués plutôt maladroits d’Adobe pour annoncer leur intention de miser sur HTML5 dans le futur et de leur intention de fournir Flex à la communauté. Ce qui a provoqué de vives réactions au sein de la communauté Flex, le plus parlant est bien entendu le billet de Fabien Nicollet auteur du blog Flex Tutorial qui montre bien l’inquiétude et l’incompréhension face à ces annonces. Finalement, suite à la panique engendrée, Michael Chaize, évangéliste de la plateforme Flash chez Adobe France a pris l’initiative de réaliser un communiqué non officiel à la communauté francophone pour la rassurer. Dans ce qui peut être dit :

• Adobe n’abandonnera pas Flex, une équipe Adobe – diminuée certes – travaillera en collaboration avec la communauté et d’autres sociétés utilisatrices de Flex,
• La totalité du projet Flex sera donnée à la communauté mais on ne sait pas encore à quelle fondation open source elle appartiendra,
• Adobe devrait donner plus d’informations sur Flex au moment de la sortie de la release de la version 4.6 qui est prévue pour le 29 Novembre 2011.

Au delà de la communauté francophone, on peut voir aussi beaucoup de réactions au travers des commentaires et réactions sur Twitter. Ce qui commence à faire réagir Adobe qui s’active pour réaliser une communication plus claire. Cette maladresse semble avoir ébranlé la communauté Flex. Espérons que les annonces à venir permettront de rassurer tout le monde et que l’ouverture de Flex à la communauté soit le début de belles initiatives.

Le coin de la technique

Sortie de JQuery 1.7

La nouvelle version de la très populaire librairie Javascript est sortie en début de mois avec son lot de nouveautés.

Au rang des changements, on notera l’apparition d’une nouvelle API de gestion des évènements. Celle-ci remplace et unifie les méthodes existantes de binding d’évènements (bind(), click(), delegate() et live()) par la méthode on(), et d’unbinding (unbind(), undelegate() et die()) par la méthode off().
Cette nouvelle méthode on est définie par la signature suivante : on(events [,selector] [,data], handler) (les éléments entre crochets sont optionnels). Elle permet donc d’associer une fonction de callback (handler) à un ou plusieurs évènement(s) déclenché(s) dans l’objet sur lequel la méthode on est appelé. Il est aussi possible de filtrer les éléments sur lesquels cette méthode s’applique à l’aide d’un css selector et de passer des données à la fonction de callback.
La fonction off de son côté possède la signature off([events], [,selector] [,handler]) permettant de supprimer des bindings. Les méthodes de binding habituelles sont encore présentes pour des raisons de rétro-compatibilité mais sont désormais dépréciées.

Cette nouvelle API vient avec une nouveau moteur de gestion des évènements qui amène une amélioration sensible des performances dans la majorité des cas.

Pour ce qui est des autres nouveautés :

• amélioration du support de HTML5,
• un fonctionnement plus intuitif des méthodes slideToggle() et fadeToggle(),
• le support de l’API Asynchronous Module Definition permettant la définition de modules qui pourront être chargées de manière asynchrone,
• de nombreuses autres améliorations et corrections de bug à voir dans le billet d’annonce.

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

CITCON London 2011

La CITCON (Continuous Integration and Testing Conference) s’est déroulé du 11 au 12 novembre à Londres dans les locaux de Skills Matter. Comme son nom l’indique, cette conférence est dédiée à tout ce qui touche à l’intégration continue et aux tests mais c’est avant tout un événement de type « Open Space ».

Le principe de la CITCON

Le premier jour de la conférence débute à 18h. Tous les participants (environ une centaine) sont invités à proposer un sujet (débats, présentation technique, démonstration d’un outil, …). Un court résumé est rédigé sur un post-it qui sera ensuite collé sur un immense tableau représentant le planning de la conférence :

Le planning s’est très vite rempli, il y avait 5 salles à notre disposition pour les 5 slots horaires prévus (1 heure par slot). Vous l’aurez compris, le contenu de la conférence est entièrement créé par la communauté. Elle est libre de proposer les sujets mais également l’heure à laquelle ils seront abordés (on parle de planning refactoring, tout le monde avait la possibilité de changer les post-it de place). Comme 5 sujets sont animés en parallèle, les participants avaient la possibilité de quitter une salle pour se rendre dans une autre si finalement la discussion ne les satisfaisait pas, c’est ce qu’on appelle la règle des deux pieds.

Les sujets abordés
Voici une liste non exhaustive des discussions animées par les participants.

• Root Cause Analysis by Squirrel
• Aramis: Why do projects fail by Eric Lefevre-Ardent.
• Dev and Ops and System Ops oh my by Squirrel
• Configuration Changes
• What can we learn from CI by Benjamin Mitchel
• Do you use your tests in prod
• Radiators by Tom Denley
• How to move an agile team from Continuous Integration to Continuous Deployment
• To feature branch or not to feature branch
• Are you satisfied of your build tools
• TDD : Hands On
• …

N’ayant pu assister à toutes les présentations, je vous livre quelques informations (il est difficile de retranscrire l’intégralité des discussions).

TDD : Hands On
La session TDD animée par Steve Freeman (l’auteur du livre Growing Object-Oriented Software, Guided by Tests) était très intéressante. Un des participants voulait comprendre comment mettre en place le Test Driven Development dans son projet. Pour ce faire, il a projeté sur le video-projecteur une méthode écrite en Java non testée. Steve Freeman a guidé l’assistance de bout en bout. De la création de la classe de tests jusqu’à l’injection de dépendances en passant par l’écriture de tests unitaires mettant en exergue les règles de gestion de la classe à refactorer.

Are you satisfied of your build tools ?
Un premier tour de table était destiné à lister tous les outils de builds utilisés au quotidien par les participants. Les noms de Ant, Gradle, Maven sont évidemment sortis assez vite, mais il existe toujours des projets qui utilisent Make. Nous avons abordés les outils connexes que sont Jenkins, Teamcity et des plugins comme m2eclipse.

La conférence s’achève
En fin d’après midi, nous voilà tous réunis pour exprimer en quelques mots les moments forts et les souvenirs que nous garderons de CITCON 2011. Un tirage au sort a permis à quelques chanceux de gagner des livres tels que Agile Testing et Domain Specific Language.

C’était un réel plaisir d’assister à la CITCON, énormément de passionnés venant parfois de très loin. Il y a forcément une certaine déception de ne pouvoir assister à toutes les présentations, par exemple à celle où un participant a construit un robot pour tester Angry Birds automatiquement !

Lors du dernier XKE, nous avons eu la visite de Michaël Chaize qui est venu nous présenter les nouvelles solutions Adobe. Fort d’une matinée plutôt réussie, j’arrive à ce slot un peu blasé et fatigué en me demandant un peu l’intérêt d’une telle présentation. Allez c’est reparti, je vais encore avoir le droit au discours technico-commercial que j’ai eu chez mon cher client quelques semaines auparavant.
Et bien que nenni ! Bien au contraire ! Je suis sorti de celui-ci avec une folle envie d’essayer de suite les technologies qu’il nous a présenté, en particulier celles qui touchaient à la mobilité.
Avant ce slot, j’avais bien entendu parler ici et là de l’émergence d’une telle solution, mais rien ne m’avait donné l’envie de m’y essayer. C’est maintenant chose faite !

La plateforme Air propose donc :

• une machine virtuelle multi-plateforme
• un langage adapté à la mobilité
• une solution pas tout à fait sèche
• un ticket d’entrée relativement faible

Write once, run everywhere ?

Les applications Air s’exécutant sur une machine virtuelle, toute plateforme disposant de celle-ci est à même d’exécuter vos applications. Adobe vous propose ici, d’adopter un framework – Flex – et une base de code unique pour toutes les plateformes que vous ciblez. L’API Air vous permet d’interagir avec le hardware de votre téléphone. Vous pouvez contrôler programmatiquement la présence de tel ou tel composant.

Sur Android, seuls quelques téléphones disposent de la machine virtuelle pré-installée. Pour les autres elle est disponible sur l’Android Market pour peu que vous disposiez d’un firmware récent (>= 2.2). Lorsque vous installez une application Air, si vous ne disposez pas du moteur d’exécution, un message vous propose son téléchargement et vous renvoie sur le market, contrairement à la version iPhone où le moteur est embarqué dans les applications (il est donc forcément téléchargé).

Si Air peut s’exécuter sur toutes ces plateformes, l’outil Flash Builder 4.5 preview, connu aussi sous le nom de Burrito, ne permet pour le moment que le développement Android. Bien que certaines vidéos montrent une compatibilité Blackberry, l’option n’est pas encore disponible dans la version de Flash Builder que j’ai téléchargé.

La taille du runtime n’est pas négligeable, sur mon Nexus One il prend 16 Mo après installation. L’option d’installation sur la carte SD n’est pas activée, inutile de bidouiller votre téléphone pour déplacer le runtime, les performances de celui-ci n’en seraient que dégradées.

Sur le papier, cette technologie permet de ne plus avoir à faire le choix d’un développement iPhone, Android ou Blackberry. En pratique, du nous sommes en pleine guerre de chapelle pour savoir où et comment seront installés les runtimes. Par exemple, à ce jour, il manque un d’incontournable dans la liste des partenaires de l’Open Screen Alliance. Air sans Apple, c’est un peu comme une forêt sans écureuil comme disait Asterix dans l’un de ses albums.

Quoi qu’il en soit, la perspective du write once, run everywhere est alléchante Wait & See…

Flex, un framework adapté à la mobilité !

Flex a été conçu dans l’optique de créer des composants riches. Il mêle description XML des composants graphiques (boutons, checkbox, listes …) – le MXML – à un langage de scripting – l’Actionscript 3 – permettant de donner vie à vos composants. Faisant moi même du Flex depuis 6 mois, je suis persuadé que ce langage est parfaitement adapté au développement d’applications mobiles.

À titre de comparaison, dans une application Android développée en Java l’écriture des écrans est relativement pénible :

• en full java, la syntaxe est lourde à manier (setters complexes, listener volumineux …),
• en XML, vous devez récupérer vos éléments graphiques par leur ID à partir du Java pour leur rajouter du comportement.

En résumé, le développent Android c’est faire du client lourd avec un langage peu flexible.

Flex est un langage pensé et conçu pour effectuer des actions asynchrones. Le langage permet l’ajout de comportements à des composants très simplement grâce à différents mécanismes dont :

• le passage de fonctions en paramètre, pratique pour passer des handlers sur des événements.
• le databinding, qui permet de notifier la mise à jour d’un model aux composants qui le désirent.

De plus, dernière bonne surprise, les composants graphiques utilisables dans une application mobile sont exactement les mêmes que ceux que vous utilisez dans une application Flex classique. L’apparence et le comportement ont simplement été adaptés pour les applications mobiles grâce à un nouveau Skin pour mobile dans la librairie Spark.

Pas encore production ready…

C’est bien joli tout cela, mais la peinture n’est pas complètement sèche.

Les outils ne sont disponibles qu’en version preview. Pourtant, l’intégration du développement mobile à Flash Builder est vraiment bien avancée :

• une vue design permet l’élaboration rapide d’écrans,
• un éditeur de composants bien pratique,
• un gestionnaire d’appareils vous permet de lancer des simulateurs, il contient d’ailleurs bon nombre de périphériques pré-configurés,
• l’installation sur un téléphone physique fonctionne tout aussi bien.

Mais il reste des progrès à faire au niveau des performances. Si l’exécution d’applications mobiles Air est bluffante sur l’émulateur, j’avoue rester un peu sur ma faim lors de l’exécution d’une même application sur mon Nexus One. (il en était de même lors de la démonstration sur tablette Android lors du XKE). Le scrolling des listes, par exemple, n’est pas aussi performant que sur une application native, la solution Flex rame encore un peu. Et plus généralement, une application Air Mobile consomme plus de CPU et de mémoire qu’une application native classique.

Mais surtout, les accords de distribution des moteurs d’exécution Air n’étant pas encore terminés, rien ne vous garantit que vous puissiez réellement profiter de votre application mobile Air sur toutes les grandes plateformes mobiles du moment.

Ne soyez pas timide, lancez-vous !

Que vous soyez développeur mobile ou non, que vous soyez flexeur ou non, n’hésitez pas à vous lancer pour vous faire un avis. Pour cela rien de plus simple, tout est disponible gratuitement sur les Labs Adobe : Adobe Flash Builder en version 4.5 preview (Burrito) (pendant 60 jours) et Adobe AIR Launchpad.

Si vous désirez essayer votre projet sur votre mobile Android (disposant d’Android 2.2 a minima), installez sur celui-ci le Runtime Air. Une fois cela fait, vous devriez mettre moins de 15 minutes pour exécuter votre première application Air sur votre mobile.

En guise de conclusion, je vous ai préparé une petite vidéo qui présente :

• la génération d’un projet Air mobile avec AIR Launchpad.
• l’utilisation de Flash Builder pour lancer votre application Air sur une plateforme Android.

Cliquer ici pour voir la vidéo.

L’avantage du Flash

L’avantage du Flash est la possibilité de développer des applications plus intuitives, efficaces et faciles à utiliser. Michael nous présente une application pour la finance réalisée pour une grande banque française. Le backend est resté le même, seul le client a été modifié pour être remplacé par du Flex. Une amélioration de la productivité des utilisateurs a pu être constatée. En effet, les données étaient plus facilement lisibles et exploitables par les utilisateurs qui prenaient donc des décisions plus rapidement.
Michael met en avant la productivité par le design. L’avantage de Flex est la facilité avec laquelle on peut réaliser des applications. Elle est productive pour le développeur et pour l’utilisateur.

Les nouveautés de la plateforme Flash

Tout d’abord Adobe a intégré dans sa plateforme le support d’HTML5 pour que ses outils, tels que Dreamweaver et Illustrator par exemple, le supportent .
La plateforme Flash est un panel complet de solutions permettant de réaliser des applications riches sur tous les supports qui vont du mobile à l’ordinateur, en passant par la télé. Cette plateforme fournit tous les outils indispensables au développement d’applications, vidéos et autres. Les applications sont natives pour tous les supports. Adobe et d’autres partenaires ont d’ailleurs créé le projet open-screen qui a pour but de travailler ensemble à l’élaboration d’un environnement consistant pour la navigation web et le lancement d’application sur n’importe quel écran. Ce projet exploite les avantages de Flash Player et d’Adobe Air.

Flash Player 10.1

Le taux de pénétration de Flash Player 10.1 est actuellement supérieur à 70%.
Les nouvelles fonctionnalités permettent maintenant d’exploiter les avantages des mobiles :

• le multi-touch et les gestures,
• l’acceléromètre,
• la gestion de l’orientation de l’écran,
• les champs textes pour mobile …

La performance a également été améliorée sur l’audio, la vidéo, la gestion des ressources en général pour économiser de la batterie (surtout pour les mobiles). Une nouvelle API vidéo a été développée pour réduire la charge sur le processeur comme certains ont pu le constater sur Mac OS. Elle utilise plutôt les ressources de la carte graphique pour fonctionner. L’utilisation de la mémoire a été optimisée. Pour tester ces nouvelles fonctionnalités, vous pouvez télécharger l’application de démonstration TourDeFlex et tester la partie Flash Player APIs. Le multi-touch est assez bluffant si vous avez un trackpad adapté .

Applications pour Mobile

Pour développer des applications pour mobile, vous pouvez utiliser Device Central CS5. Il fait partie de la Creative Suite et fournit toutes les configurations des smartphones, telles que la mémoire, le processeur … Ces dernières sont mises à jour dynamiquement. Vous trouverez une démonstration de ce que l’on peut réaliser en terme d’application mobile sur le blog de Michael Chaize où il présente un Doodle Jump développé avec Air et qu’il a pu déployer sur son Android en version 2.2 (Froyo).

AIR 2

Air est une application desktop, ce qui signifie qu’il exploite les ressources de l’ordinateur. Maintenant le déploiement est possible sur Android, et pour plus d’informations je vous renvoie vers cet article. Autre nouvelles fonctionnalités avec AIR :

• ouverture des fichiers avec l’application par défaut définie par l’OS,
• détection de l’OS avec l’objet Capabilities.os,
• exécution possible de commandes grâce à NativeProcess.

Quoi de neuf sur Flex Hero ?

Flex Hero est le petit nom de la release majeure 4.1 de Flex. Dans cette nouvelle version, de nouveaux composants spark sont disponibles :

• une datagrid spark avec :
  • gestion des déplacements avec les touches,
  • une skin class (apparence) plus simple à personnaliser que celui de Halo
  • et un chargement des données dynamique au moment du scroll. Ce qui rend le chargement plus rapide grâce à la pagination.
• un formulaire spark,
• des formatters spark avec gestion de l’internationalisation,
• un MobileApplication pour gérer les applications mobiles,
• une API pour la navigation dans les vues,
• ActionBar,
• MobileItemRenderer pour les rendus de liste spécifique aux applications mobiles,
• gestion de la géolocalisation,
• gestion de l’orientation,
• génération de l’application sous forme de package Android (APK).

Flash Catalyst

La sortie en release preview de Flash Builder « Burrito » s’accompagne aussi de celle de Flash Catalyst « Panini ». Celui-ci a été revu pour faciliter la collaboration entre le développeur et le designer. Précédemment, le problème était que le designer ne pouvait pas retravailler sur ce qu’avait réalisé le développeur. Avec cette nouvelle version de Flash Catalyst, c’est maintenant possible.

LiveCycle Collaboration Service

Le LiveCycle Collaboration est une solution hébergée par Adobe pour proposer aux développeurs de réaliser des applications Flex collaboratives. Ils ont à leur disposition des composants : tableau blanc pour les dessins, gestion de la webcam … pour réaliser des applications où il est possible aux utilisateurs d’échanger des informations. Michaël nous a d’ailleurs invité à accéder à une des applications qu’il a réalisé. C’était très intéressant de voir sur le grand écran de la salle une dizaine de webcams afficher le visage de quelques participants curieux.

Crédit photo : les images proviennent du site d’Adobe et de l’album Picasa de Stephan Jaansen pour Devoxx 2010

Adobe Air pour iOS

Pour le développement d’applications iPhone, Apple avait émis une restriction pour interdire l’utilisation d’outil de développement en dehors de ceux autorisés par Apple. Suite à la levée de cette restriction, Adobe peut donc enfin réaliser des applications pour iPhone à partir de ses outils. Parmi les fonctionnalités d’Adobe Air, vous trouverez un packager pour iOS qui permet de transformer une application Air en IPK (format des package pour l’iPhone). Ce packager est aussi disponible dans la Creative Suite 5. Le packager permet de générer une application native pouvant être exécutée pour iOS. Attention, certaines APIs n’ont pas été implémentées dans le packager.

Les nouveautés dans Air 2.5

La grande nouveauté de Air 2.5 est la possibilité de développer des applications mobiles. Pour ce faire, deux nouvelles classes héritant d’Application sont disponibles : MobileApplication et TabbedMobileApplication. Un nouveau skin a été créé pour les applications mobiles et certains composants en bénéficient comme Button, CheckBox, DataGroup, Label, List, Scroller … Parmi les nouveaux composants dédiés, vous trouverez le MobileItemRenderer et le MobileIconItemRenderer pour les rendus de listes .

Flash Builder « Burrito »

Burrito est le petit nom du dernier Flash Builder. Il prend en charge toutes les nouveautés disponibles dans Flex 4. La fonctionnalité mise en avant est la possibilité de développer des applications mobiles à partir de votre Flash Builder !

Flash Builder « Burrito » est disponible en version d’évaluation (pour une durée de 60 jours) ; vous pouvez le récupérer ici. Pour ma part, très curieuse de voir ces nouvelles fonctionnalités je l’ai téléchargé et effectivement, on peut créer des applications flex mobiles.

Une fois votre projet créé, vous pouvez visualiser dans la partie Design de nouvelles options associées à votre vue.

Vous pourrez sélectionner une configuration de téléphone, vous aurez le choix entre plusieurs téléphones android.

Vous pourrez également modifier l’orientation du téléphone pour vérifier le bon positionnement de vos composants.

   

Une fois votre application réalisée, vous pouvez l’exécuter. Celle-ci sera affichée dans une fenêtre au format du téléphone que vous avez sélectionné. Elle propose aussi un menu contenant les actions disponibles pour le téléphone que vous avez sélectionné (changement de l’orientation, menu, retour arrière …).
Il est également possible d’exécuter votre application directement sur votre Android si bien évidemment vous en avez un . Une simple connexion USB suffit pour cela. Malheureusement, je n’ai pas pu tester cette partie mais espérons que le père Noël m’apporte un Android 2.2 le mois prochain.

Ce n’est pas tout. Vous avez développé votre application et l’avez testée. Vous voulez maintenant la partager ? Il suffit simplement de préparer le package pour le déposer sur Android Market. Et avec Flash Builder « Burrito » rien de plus simple, exportez votre projet et sélectionnez Release Build. La seule plateforme disponible pour le moment est Google Android. Après avoir donné votre certificat et mot de passe, Flash Builder vous génère un APK contenant une application native Android que vous pouvez déposer sur Android Market.

Le déploiement semble simple et pourrait motiver de nouveaux développeurs à réaliser des applications pour mobile.

Actualité éditeurs / SSII

• Apple et Adobe : petits coups bas entre amis

Le coin de la technique

• Google App Engine SDK 1.3.1: Améliorations au niveau du Datastore
• Refcardz Vaadin
• Sortie de EasyAnt 0.7.

Actualité éditeurs / SSII

Apple et Adobe : petits coups bas entre amis

L’échange de coups a commencé à l’initiative d’Apple lors de la présentation de l’iPad, avec une subtile allusion au fait que le nouveau magic device ne supporterait pas Flash (voir la photo ici).
Il a continué avec les rumeurs (non démenties à ce jour) de propos issus de la bouche de Steeve Jobs, traitant les ingénieurs d’Adobe de faignants (si on remet ces mots de le contexte, ils seraient tire-au-flanc car disposant d’un outil fabuleux (Flash) mais ne l’exploitant pas).
Ce remue-ménage doit aussi être associé aux rumeurs grandissantes de la mort annoncée de Flash remplacé par HTML 5 dès l’année prochaine
Il n’en fallait pas plus (quoi que ce soit déjà beaucoup) pour qu’Adobe contre attaque. Et après quelques employés qui se sont exprimés (pas toujours élégamment), c’est Kevin Lynch, le CTO en personne, qui monte au créneau. En répondant pied à pied aux critiques émises par Apple :

• Flash est né à l’origine pour les tablet-pc. Mais il a su évoluer, et c’est pour cela qu’il est aujourd’hui la ressource de référence de diffusion de contenu sur HTML.
• Le flash player 10.1 devrait être présent sur les devices de nouvelle génération et leur permettre d’accéder à la totalité du contenu du web. Ce flash player est prêt pour l’iPhone dès qu’Apple laissera le choix à ses utilisateurs de l’installer (on peut toujours rêver).
• HTML 5 ne remplacera pas dans un avenir proche l’ensemble des fonctionnalités de Flash : on voit déjà que le choix d’un support vidéo nous renvoie quelques années en arrière avec des codecs qui divergent dans les principaux navigateurs. De plus, la richesse et la productivité de Flash, les innovations qu’Adobe ne manquera pas d’y apporter, et la rapidité de diffusion de la technologie face à un HTML difficile à standardiser promettent des beaux jours au plugin préféré des utilisateurs du web.
• Le mixage de Flash et HTML procure une expérience utilisateur irremplaçable.

Cette déclaration n’a pas manqué de susciter de nombreux commentaires auxquels Kevin Lynch a pris la peine de répondre (des pro aussi bien que des anti).
Et il y a fort à parier que cette polémique risque de perdurer toute l’année. C’est pourquoi nous vous proposerons bientôt un article sur HTML 5, pour que vous aussi vous puissiez vous faire une idée sur ce Flash Killer (mais nous nous abstiendrons bien sûr de rentrer dans les polémiques marketing et nous contenterons d’être sereinement techniques et terre à terre

Le coin de la technique

Google App Engine SDK 1.3.1: Améliorations au niveau du Datastore

La version 1.3.1 du SDK de Google App Engine vient de sortir. Pour rappel, GAE est une solution de cloud computing orientée PaaS (Platform as a Service). Cette release est axée principalement sur le DataStore. Elle apporte également un nouveau framework de tests unitaires.

Au niveau du DataStore, on peut noter les améliorations suivantes:

• La limitation à 1000 du nombre de résultats d’une requête a été enlevée : grâce à l’apparition des Query Cursors, et d’améliorations internes à BigTable, les développeurs de Google sont assez confiants au niveau des performances pour enlever cette limite.
• Apparition des Query Cursors: GAE offre la possibilité de sauvegarder dans un objet Cursor la progression du résultat d’une requête, dont on a limité le nombre de résultats. Par exemple, en fixant à 20 le nombre de résultats de votre requête, si vous lancez une première fois la requête et sauvegardez le curseur. En relançant la même requête, vous obtiendrez directement les 20 résultats suivants.

Le curseur peut être persisté ou encodé en String pour l’inclure dans des pages web. Vous pourrez ainsi relancer une requête avec le curseur à tout moment. Outre le fait d’avoir permis de supprimer la limite du nombre de résultats d’une requête, une des applications possibles des curseurs est la récupération des dernières entités mises à jour.

• Automatic retry des appels vers le DataStore : lors d’erreurs d’accès au datastore, les exceptions devaient être gérées par l’application. Cela entrainait de nombreuses erreurs d’application. Maintenant, App Engine retente automatiquement les appels au DataStore.

Le framework de tests unitaires a été revu pour être plus flexible et s’intégrer facilement avec les API de tests comme Junit, Unitils, etc. Avant, il fallait utiliser un objet ApiProxyLocal pour simuler un environnement GAE. Maintenant, GAE fournit un objet LocalServiceTestHelper, qui permet d’effectuer des tests utilisant le DataStore, le MemCache, ou encore les TaskQueues.

Un certain nombre de bugs, principalement liés au DataStore ont aussi été corrigés. Au final, cette nouvelle version apporte de réelles nouveautés et donne le sentiment que le projet GAE avance bien.

Refcardz Vaadin

Le framework Vaadin, que nous avons couvert dans de précédentes revues de presse (ici et là) arrive sur DZone avec une Refcardz qui lui est dédié (information relayée sur ce blog).
Au menu, plusieurs sections avec tout d’abord un petit overview du framework, suivi par un paragraphe de création d’application. Viennent ensuite les sections liées aux composants et aux layouts de composants ainsi qu’une partie sur les thèmes et une partie sur le data binding. Une dernière partie nous montre comment créer nos propres composants. Une refcardz très complète donc, qui nous donne en quelques pages un très bon aperçu du framework.
Et pour approfondir le sujet, vous pouvez vous rendre sur cette page et récupérer le book of Vaadin.

Sortie de EasyAnt 0.7.

EasyAnt, un système de build alternatif au très populaire Maven vient de sortir en version 0.7.

EasyAnt apporte un certain nombre de fonctionnalités au non moins populaire projet Ant sur lequel il repose. Il propose entre autre des conventions pour la structuration des projets, un système de gestion de dépendances (utilisant Ivy) ainsi qu’un cycle de vie du build (à l’aide de la notion de phases sur lesquelles viennent se brancher des targets).

Ce projet ressemble donc dans l’esprit fortement à Maven sur lequel EasyAnt à repris un certain nombre de bonnes idées. Néanmoins, là où Maven est particulièrement restrictif, EasyAnt est suffisamment souple pour permettre une migration relativement aisée de vos anciens projets même s’ils ne respectent pas les conventions préconisées. Il permet aussi de conserver les tâches Ant qui ont été précédemment développées et de les attacher aux différentes phases du build.
EasyAnt est encore relativement jeune par rapport aux mastodontes du build que sont Ant et Maven mais il apporte un réel intérêt pour des projets historiques construits avec Ant et pour lesquels on souhaite profiter de fonctionnalités proposées par Maven.

Les principales évolutions de la version 0.7 sont la possibilité de surcharger les targets et phases définies par défaut (pour une plus grande souplesse) et un meilleur support des projets multi-modules.

Le développement de ce projet est relativement actif. Nous suivrons avec intérêt l’évolution des prochaines versions.

• 2500 participants,
• 737 compagnies représentées comme Xebia par exemple ,
• 132 sessions,
• 120 speakers,
• 56 JUGs (dont 10 en France),
• 36 pays,
• et 19 partenaires ce qui est moins que d’habitude.

La nouvelle version de Parleys.com

Stephen Janseen débute en nous expliquant ce que fournira la nouvelle version de Parleys.com. Gratuites et disponibles, le nombre de vidéos augmente sur les serveurs, ce qui est très coûteux. Pour pallier ce problème, il a décidé de publier le plus tôt possible les conférences de Devoxx (ce week end même d’ailleurs ). Et avec un abonnement de 49€ pour 6 mois, un utilisateur pourra soit télécharger toutes les vidéos qu’il souhaite sur le site soit les regarder directement en streaming. Pour les plus patients, la video sera rendue publique en streaming pour tous au bout d’un an.
Dans cette nouvelle version, il sera possible :

• De définir des channels privés ou publiques selon les besoins du publieur,
• De choisir son look’n'feel,
• D’ajouter des commentaires sur la piste video.

Ces nouveautés sont actuellement disponibles sur http://beta.parleys.com.

La keynote de Java EE 6

Cette année à Devoxx, la star est clairement JEE6 avec pas moins de 7 sessions autour de ce sujet :

• Une keynote.
• Une université et un BOF JEE6.
• Une université et un BOF JSF 2.0.
• Une conférence JEE6.
• Une conférence JEE6 et Glassfish V3.

La keynote met en avant les spécifications les plus hypes de JEE6 avec entre autres :

• EJB 3.1,
• DI 1.0 (@Inject),
• CDI 1.0 (Context and Dependency Injection),
• JSF 2.0 (événement que nous avons couvert),
• Bean Validation 1.0,
• Servlet 3.0,
• et JAX-RS 1.1.

Un article plus complet décrivant JEE6 arrivera très prochainement, l’information principale de cette keynote étant la date de sortie de JEE6 qui est prévue pour le 10 décembre 2009 (Cf. notre précédente revue de presse).

La keynote d’Adobe avec en guest-star Flash Catalyst

Adobe fut à l’honneur cette année à l’instar de JavaFX. La keynote fut l’occasion pour l’éditeur de tenter une opération séduction de la communauté Java avec des annonces autour de Flex, Air, Flash Player Lite et Flash Catalyst.

Pour commencer, Flash Player 10.1 fut présenté. Cette version a surtout été travaillée pour fonctionner sur téléphone mobile :

• Réduction de la mémoire utilisée.
• Limitation de la consommation de batterie.
• Gestion du multi-touch et de l’accéléromètre.

Serge Jespers a présenté un Flash Player déployé sur mobile : oui, il est enfin possible d’accéder à Parleys depuis son mobile !

La liste des partenariats entre Adobe et les fabricants de smartphone et d’OS a considérablement augmenté depuis l’année dernière. Avec, entre autres, le petit dernier : RIM, l’OS de BlackBerry. Actuellement, Apple ne fait toujours pas partie de cette liste. Aucun accord n’a été trouvé pour le moment. Il n’est donc pas possible de lire une application Flex par exemple depuis le navigateur de son iPhone. En revanche, il est possible de déployer une application Flex sur l’AppStore et de l’utiliser. En effet, Adobe a mis en place un moyen permettant de convertir un swf en code natif pour l’iPhone. Des jeux Flash sont d’ailleurs déjà disponibles sur l’AppStore.

Autre annonce, la sortie depuis quelques jours de la béta de Adobe Air 2.0. Cette version fournit les nouveautés suivantes :

• Le support de l’usb.
• Le support du multi-touch.
• De nouvelles APIs permettant de récupérer la sortie du microphone.
• Une sécurité améliorée pour mieux répondre aux standards des entreprises et gouvernements.

Nos deux speakers ont ensuite impressionné la salle en réalisant rapidement à partir d’un dessin issu d’Illustrator une application Flex comportant des effets, gérant un évènement click sur un bouton, et le plus impressionnant de tous, la gestion d’une scrollbar provenant d’un dessin. Cette génération fut ensuite exportée dans Flash Builder 4 en tant que projet Flex. La salle semblait séduite par la démo. Attendons maintenant 2010, pour voir si cette plateforme tiendra ses promesses et si la communauté continuera à suivre.

Actualité éditeurs / SSII

• La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0
• Sonar 1.11

RIA

• Air ‘Athena’
• DHTMLX 2.5
• Tips and Tricks Maven 2

Le coin de la technique

• Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas
• Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Actualité éditeurs / SSII

La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0

La fondation Eclipse nous livre une nouvelle version de Jetty estampillée 7.0. Côté nouveauté, pas grand chose à vrai dire. Il y a évidemment l’habituelle série de corrections de bugs et d’améliorations de performance. Cette nouvelle version marque surtout le début de la route vers l’implémentation des servlets 3.0 prévue pour Jetty 8.0. C’est aussi l’occasion pour Eclipse d’assimiler un peu plus le projet en changeant principalement le package ancêtre de org.mortbay vers org.eclipse, gare au refactoring donc. A noter tout de même, Jetty est maintenant livré sous une forme modulaire pleinement compatible OSGI. Webtide en profite pour livrer la même version de Jetty, en y intégrant des modules additionnels:

• JSP de glassfish
• JTA d’atomikos
• plugin maven
• integration d’ant
• configuration Spring

Jetty 6 sera encore maintenu pendant quelques temps (aucune précision de la part d’Eclipse), tous les nouveaux développements seront faits sur Jetty 7, et la branche 8 sera en pré-release dans les prochains mois et supportera l’API Servlet 3.0.

• L’annonce sur la ML
• La news d’InfoQ
• La page Jetty chez Eclipse
• La page Jetty chez Codehaus

Sonar 1.11

SonarSource nous gratifie d’une version 1.11 du désormais célèbre outil de suivi de qualité Sonar. Comme souvent, de nombreux de bugs ont été corrigés. Parmi les améliorations, on peut noter les passages à Hibernate 3.3 et GWT 1.7. Au chapitre des nouvelles fonctionnalités, la possibilité de réutiliser les fichiers de configuration PMD et CheckStyle définis dans le pom permettra de plus aisément éviter les doublons.

SonarSource tente de faciliter la vie des développeurs de plugins avec l’apparition d’un archétype Maven pour créer des plugins Sonar. D’autres nouveautés d’API, comme le filtrage de widgets suivant différents critères (comme le rôle utilisateur ou la langue choisie), ajoutent de la flexibilité.

• L’annonce sur le blog Sonar avec plein de jolies images.
• La release note.

RIA

Air ‘Athena’

Non, ce n’est pas une nouvelle marque de baskets, mais, comme les flexeurs le savent depuis le Flash Camp de mai, le nom de code de la future version de Adobe Air, la version 2.0. Comme on s’y attendait, celle-ci fonctionnera avec Flash 10 et Flex 4. Même si aucune date officielle n’a été avancée, Adobe dévoile peu à peu les principales évolutions de sa plate-forme, nouveautés répertoriées par Elad Elrom sur InsideRIA.
Commençons par celle qui nous semble vitale dans l’adoption de AIR / Flex à grande échelle, à savoir une amélioration drastique des performances. Les équipes d’Adobe ont mis l’accent sur la réduction des ressources (CPU et mémoire) consommées par le runtime AIR. Les tests effectués sur une mini application montrent en effet une diminution des ressources utilisées (en regard de la version 1.5). Reste à tester ces optimisations sur une application gourmande… Toujours au chapitre performance, Adobe promet une optimisation de Webkit (le browser open source embarqué par AIR) et une installation Linux native.
Au menu des nouveautés, nous avons :

• Une meilleure connaissance de la plate-forme matérielle, avec la gestion des devices multi-touch et la gestion des périphériques de stockage USB ou réseau ‘à chaud’.
• Un enrichissement des fonctionnalités des APIs existantes : points de sauvegarde dans les transactions, support IPv6, augmentation de la taille maximale de la fenêtre AIR, manipulation des données de l’API Microphone, time-out d’inactivité…
• De nouvelles fonctionnalités via de nouvelles API, dont la plus étonnante est l’API File promises. Celle-ci permet de télécharger en local, depuis une application AIR, un ensemble de fichiers par simple Drag & Drop. D’autres API font également leur apparition, en particulier au niveau du support réseau et de l’adhérence de AIR à l’OS (les fichiers peuvent maintenant être ouverts par des processus natifs de l’OS, par exemple Notepad pour un .txt sous Windows).

Une évolution assez naturelle donc (correction des gros points de blocage des versions précédentes), mais quelques promesses de fonctionnalités intéressantes, en particulier via l’adhérence à l’OS.

DHTMLX 2.5

Des nouvelles de DTHMLX (la 11ème librairie de notre revue de presse de fin janvier dernier) qui est sorti il y a quelques semaines en version 2.5.

Cette release apporte plusieurs corrections et améliorations sur tous les composants de la suite. On retiendra plus particulièrement :

• Une API orientée objet (l’API fonctionnelle est toujours disponible) ,
• Nouvelle skin par défaut avec d’ici peu (mais non présent dans cette release) un Skin Customizer qui permettra de modifier facilement les couleurs principales du thème standard,
• Nouveau moteur de rendu qui améliore la performance d’affichage des composants Layout, Windows, Accordion et Tabbar,
• Une API de conteneurs unifiée (toujours pour les Layout, Windows, Accordion et Tabbar),
• Améliorations générales pour les composants Grid, Tree et TreeGrid,
• Révision complète du DocsExplorer.

Puisque nous sommes sur DHTMLX, notons aussi le composant Scheduler v.2.0, sorti en juillet dernier, qui n’est pas inclus dans la suite mais qui vaut tout de même le détour si vous avez besoin d’un composant calendrier haut niveau.

Les téléchargements se passent par ici et comme d’habitude vous aurez le choix entre le téléchargement composant par composant ou le téléchargement de la suite complète.
Chaque composant existe en édition standard ou professionnelle. Pour résumer la version standard contient moins de fonctionnalités et est sous licence GPL alors que la professionnelle contient toutes les fonctionnalités, un support prioritaire en cas de bugs/questions sur le forum et plusieurs centaines d’exemples de fonctionnalités avancées.
Pour le détail des licences et des différents prix proposés pour les composants et pour la suite complète, cela se passe sur cette page.

Tips and Tricks Maven 2

Sonatype nous présente ici quelques nouveautés intéressantes de maven disponibles depuis la version 2.1 concernant les projets multi-modules. Cela se traduit par de nouvelles commandes disponibles telles que:

• -rf, -resume-from: permet de spécifier au maven reactor le projet à partir duquel on veut reprendre le build
• -pl, -projects: permet de sélectionner une liste de modules d’un projet multi-modules
• -am, -also-make: combinée avec l’option -pl, elle permet de construire tous les modules dépendants du module passé à l’option pl
• -amd, -also-make-dependents: combinée avec l’option -pl, elle permet de construire tous les modules qui ont une dépendance vers le module passé à l’option pl

Très bonne nouvelle donc pour les développeurs dont le build prenait beaucoup de temps à cause de la reconstruction de modules non modifiés (et non impactés) par leurs nouveaux développements.

Le coin de la technique

Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas

Le Denim Group continue sa série 13 Things a Web Applications Attacker Won’t Tell You que nous avions traitée la semaine dernière avec 5 nouvelles failles de sécurité de nos applications web :

• Ce n’est pas parce que vous utilisez un framework de sécurité que votre application est sécurisée.
• Je n’utilise pas un browser pour attaquer votre application web.
• J’adore quand votre site me permet d’uploader des fichiers dans l’arborescence des répertoires servis par l’application web.
• Je peux intercepter et voler toutes les informations qui passent sur HTTP si elles ne sont pas protégées par SSL ou un mécanisme équivalent.
• Une sécurité obscurantiste n’en est pas une (ne pas savoir faire ou se dire que ca n’arrivera pas ne protège pas).

Si le dernier point est un débat éternel chez les experts de la sécurité les premiers sont en revanche communément admis.

Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Rémi Forax, un contributeur sur OpenJDK et sur la JSR-292, a fait part de son étonnement en constatant un gain significatif de performance entre deux builds successifs de l’OpenJDK 7 actuellement en cours de développement. C’est ainsi qu’il a pu se rendre compte que deux optimisations majeures du compilateur JIT de la JVM étaient activées par défaut depuis le build 72 du projet : l’escape analysis et la compression de pointeurs. Celles-ci étaient apparues dans le JDK 6u14 mais n’y étaient pas activées par défaut.

Pour rappel l’escape analysis consiste en l’analyse du bytecode d’une méthode pour découvrir les références vers les objets qui ne « s’échappent » pas du contexte de la méthode. Grâce à cette analyse, la JVM peut alors décider d’allouer ces objets directement sur la stack plutôt qu’en heap comme c’est normalement le cas. Il en résulte un gain de performance évident puisque le coût d’allocation et de libération de mémoire est alors supprimé pour ces objets.

La compression de pointeurs, quant à elle, concerne uniquement les JVM 64 bits. En effet le passage d’un adressage de 32 à 64 bits entraîne une consommation plus élevée de la mémoire du fait de l’augmentation de la taille des pointeurs, induisant elle-même des temps de chargement plus longs et une surconsommation du cache du processeur. Pour palier ce problème, la compression de pointeurs se base sur le fait que la JVM aligne l’adresse des objets sur 64 bits (ceci afin de simplifier et donc d’accélérer leur accès en mémoire), pour procéder à un scaling des pointeurs. Ainsi, en limitant l’espace mémoire adressable à 32 Go, il est possible de contenir un pointeur dans 32 bits et donc de revenir à une consommation mémoire proche de celle d’une JVM 32 bits.

L’activation par défaut de ces deux optimisations sur le JDK 7 montre que l’équipe du projet estime désormais qu’elles ne sont plus expérimentales et qu’elles conviennent dans la majorité des cas. Ismael Juma précise par ailleurs qu’il est possible que ces activations par défaut soient reportées également au JDK 6 courant 2010.

RIA

• Vaadin 6
• Adaptateur Gilead pour GAE
• Une série d’annonces chez Adobe

Le coin de la technique

• Scalabilité avec Hibernate et Shards
• Jigsaw vs OSGi
• Pourquoi utiliser un portail ?
• Embarquer le Web dans Java avec JWebPane

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

• Xebia @ Jazoon 09

RIA

Vaadin 6

Au revoir IT Mill Toolkit et bienvenue à Vaadin (vu sur leur blog) !

Pour ceux qui ne le connaissent pas encore, Vaadin (anciennement IT Mill Toolkit) est un framework de développement d’applications RIA qui s’appuie sur GWT. Sa particularité est d’être runtime donc aucune compilation spécifique n’est demandée avant de packager la webapp (à l’inverse de GWT).

Simple changement de nom ? En tout cas très peu de changement côté API selon les auteurs du framework. Il faut plutôt se tourner vers l’outillage pour voir quelques nouveautés : un plugin eclipse (création de projets, de composants UI, de thèmes…) et, inclus dans le plugin, un éditeur WYSIWYG.

Côté liens utiles, l’habituel showcase, le livre et la comparaison maison avec les autres frameworks du marché (et la concurrence est rude dans le monde du RIA).

A noter que Vaadin sera présent à Jazoon pour une conférence sur RIA Security le mardi 23 juin à 15h (slides, projet et autres sur cette page).

Adaptateur Gilead pour GAE

Vous connaissez GWT, Gilead, et Google App Engine ? Et bien il ne reste plus qu’à mélanger tout ça et on obtient le Gilead GWT adapter for Google AppEngine (vu sur le GWT Blog).

Tout démarre d’un thread google groups avec comme point de départ la serialization exception lancée par les entités persistantes transférées vers GWT. Évidemment, la solution qui ressort très rapidement, outre l’utilisation de DTOs, est de passer par Gilead pour transformer nos entités persistantes en POJOs. Il suffit d’ajouter le jar adapter4appengine et de remplacer la classe PersistentRemoteService par EngineRemoteService dans vos remotes services. Dès lors, il sera possible d’envoyer ses entités persistantes vers le client GWT sans exceptions de sérialisation sur GAE.

1.0 M2 téléchargeable à cette url, documentation par ici. Attention toutefois, cette version n’est pas production ready.

Une série d’annonces chez Adobe

Après l’annonce de la sortie de la plateforme Flash il y a quelques semaines, voici une nouvelle série d’annonce de la part d’Adobe.

Pour commencer, deux news relayées par Andrew Twice dans InsideRIA.
La première concerne la sortie d’Adobe Table en version bêta. Cet outil permet de créer des feuilles de calcul, des plannings ou encore des listes de tâches en ligne:

• Les utilisateurs peuvent ajouter des données en même temps: les données sont mises à jour en temps réel pour tout le monde.
• Possibilité de savoir qui travaille sur Adobe Table.
• Création d’écrans communs et privés : les utilisateurs peuvent travailler de manière coopérative, et/ou créer des espaces privés pour ne garder que les informations importantes.
• Filtrage : les utilisateurs peuvent filtrer leurs données en temps réel.
• Tri.

Similaire à Google Document, cet outil a été développé sur la plateforme Flash et va continuer à évoluer. La démo se passe ici, la seule contrainte : avoir un compte Adobe.

La deuxième annonce concerne l’ouverture de la spécification de Real-Time Messaging Protocol (RTMP). Comme nous en avions parlé ici, la spécification a été publiée lundi dernier.

Enfin, Michael Chaize parle de la sortie de LiveCycle Data Services 3 en bêta. Disponible sur le labs d’Abobe, cette nouvelle version propose une meilleure qualité de service pour des applications dont la fiabilité est primordiale telles que les applications bancaires par exemple. Venant compléter la plateforme Flash (avec Flex 4 et Flash Builder 4), Adobe incite la communauté à faire ses retours sur le forum.

Le coin de la technique

Scalabilité avec Hibernate et Shards

Une session de QCon 2008, traitant de la scalabilité d’Hibernate, vient d’être mise en ligne. Présentée par Emmanuel Bernard, project lead d’Hibernate Search, et Max Ross, project lead d’Hibernate Shards, cette présentation offre une approche peu courante sur un problème pourtant récurrent.

Outre les classiques solutions permettant d’éviter certaines pertes de performance avec l’augmentation du volume traité, telles que la bonne gestion du cache, et les optimisations SQL, il a été question d’utiliser Hibernate Search et Hibernate Shards.

Hibernate Search est connu pour sa capacité à simplifier les recherches dans un ensemble d’entités grâce à l’utilisation de Lucene conjointement à la base de données. Emmanuel Bernard proposait ici de déléguer à Search certaines recherches qui s’avèrent très coûteuses à effectuer en base. Lucene étant placé sur une machine séparée, et pouvant même fonctionner en maître / esclave, il est ainsi possible d’obtenir une intéressante répartition de la charge.

Hibernate Shards, bien que plus ancien, est moins répandu du fait qu’aucune version finale n’a encore été produite. Il s’agit d’un module additionnel pour Hibernate permettant à une application de manipuler des données partitionnées sur plusieurs BDD. Le but étant d’encapsuler la conscience du partitionnement des données au sein de la couche Hibernate afin que l’application n’ait pas à gérer cette problématique. Les possibilités du framework sont intéressantes :

• La gestion correcte des Criterias sur des données partitionnées grâce à ShardedCriteria.
• Virtual Shards permettant de faire la distinction entre shard logique et shard physique et ainsi d’augmenter le nombre d’instances de base de données au fur et à mesure de l’augmentation des besoins.
• Generation d’IDs compatibles avec l’utilisation sous-jacente de plusieurs BDDs grâce à l’utilisation d’UUIDs.
• Gestion correcte de BDDs hétérogènes.

Ce sont finalement les fonctionnalités manquantes qui permettent de comprendre pourquoi Shards est toujours en version bêta. Max Ross s’est expliqué il y a plusieurs mois sur les problématiques rencontrées, de manière succincte sur un forum et plus longuement dans une interview. De nombreux défis restent ainsi à relever concernant la gestion correcte des agrégations dans les ShardedQuery et la fourniture d’outils d’aide au partitionnement et repartitionnement des données.
Max Ross est employé par Google et non par JBoss, tout comme les deux autres committers du projet (le code ayant été donné à JBoss par Google), et affirme ne disposer que de 20 % de son temps pour Shards. Ceci n’explique que partiellement le peu de commits sur le projet et ne nous rassure guère quant à sa finalisation prochaine.

Jigsaw vs OSGi

Sept mois après le démarrage du projet Jigsaw, sa légitimité n’est toujours pas reconnue face à OSGi qu’il est venu défier sur son propre terrain.

La semaine dernière JavaPosse diffusait une interview de Mark Reinhold et Alex Buckley, où ils ont pu présenter plus en détail leur vision de Jigsaw :

• Il a été conçu pour modulariser le JDK et est intégré au langage.
• Il ne repose pas sur une spécification car cela n’était pas possible compte tenu du calendrier de JDK 7. Il est donc à considérer comme un « détail d’implémentation » tout comme la gestion du classpath l’était dans les JVMs précédentes.
• Il n’est pas supposé entrer en concurrence avec OSGi, des outils permettant l’intégration entre modules Jigsaw et bundles OSGi étant prévus, mais non prioritaires.

Dans le même temps, Eric Newcomer (Co-Chair, Enterprise Expert Group de l’OSGi Alliance), postait une série de billets très virulents à l’égard du projet Jigsaw, reprochant principalement que Sun n’ait pas voulu se tourner vers OSGi, ne cherchant pas à combler les manques qu’il y trouvait, se tournant immédiatement vers une nouvelle technologie et ignorant donc les 10 années d’expérience acquises par OSGi.

En fait, il semble n’y avoir aucune justification technique permettant d’expliquer l’orientation de Sun vers Jigsaw plutôt que vers OSGi ou vers une évolution d’OSGi intégrée au langage. La véritable raison serait alors à chercher sur le plan politique : la modularisation est un concept important qui manque à Java actuellement et Sun ne pouvait probablement pas se permettre, pour l’ajout d’un tel concept, de s’appuyer sur une spécification émise en dehors du JCP sur lequel il a la gouvernance.

Pourquoi utiliser un portail ?

Le dernier podcast des Cast Codeurs était l’occasion d’une interview de Thomas Heute et Julien Viet sur les portails d’entreprise et sur le partenariat entre eXo et JBoss dont nous vous parlions la semaine dernière.

Les détails liés au partenariat ont déjà été largement couverts par la blogosphère, et c’est surtout le tour d’horizon du concept même de portail que l’on retiendra. Celui-ci reste en effet souvent un élément ambigu au sein de l’écosystème JEE.

Le rôle du portail est d’agréger plusieurs applications au sein d’une unique application Web. Ce besoin technique peut être atteint à plusieurs niveaux de l’architecture de l’application :

• Au niveau back-end, par agrégation de Web Service, se conformant ainsi à l’un des préceptes des SOAs.
• Au niveau applicatif, par l’utilisation d’un portail, ou d’une solution spécifique.
• Au niveau du navigateur Web, par l’utilisation de gadgets, en suivant le principe des Mashups.

En outre, il a également été question des problématiques d’intégration des frameworks Web aux portlets, de complexité éventuelle, et d’adaptation des technologies Web aux portlets. Déterminer si un portail doit être utilisé dans une architecture dépend alors du niveau de tolérance à ces problématiques.

Embarquer le Web dans Java avec JWebPane

Depuis plusieurs années, lorsque l’on veut afficher une page Web au sein d’une application Swing, il faut se tourner vers le composant Browser de la librairie Jdic. Ce composant utilise Embeddable Mozilla, et se présente sous la forme de code natif décliné pour chaque OS et d’un wrapper Java. Outre la nécessité de fournir une version spécifique à chaque OS, ce composant présente également l’inconvénient de mal s’intégrer aux applications Swing du fait de sa nature heavyweight. Pour rappel, un composant est dit heavyweight lorsqu’il est dessiné par l’environnement graphique du système d’exploitation ; à l’opposé il devient lightweight s’il est dessiné par l’application, ce qui est le cas de l’ensemble des composants Swing. Or, faire cohabiter les deux types de composants est délicat car n’étant pas dessinés au même moment, leur superposition est confuse et des chevauchements non contrôlables apparaissent.

Lors de JavaOne, Alexey Ushakov a fait la démonstration du composant JWebPane sur lequel il travaille actuellement et vient de poster des captures d’écrans. Contrairement à Jdic Browser, JWebPane se base sur le moteur WebKit pour effectuer le rendu HTML. Or celui-ci se caractérise par sa nature lightweight s’intégrant agréablement à Swing. La présentation d’Alex Ushakov permet également de constater que son composant est particulièrement riche en possibilité d’interactions et apporte un support pour d’éventuels plugins tels que Flash.

On ne peut qu’apprécier le choix de Sun de créer un composant pour Swing, réutilisable dans JavaFX, plutôt que de privilégier uniquement JavaFX comme cela est souvent le cas depuis son arrivée. L’intégration de JWebPane au JDK 7 est maintenant indispensable pour rendre ce composant réellement exploitable : se basant sur WebKit, il repose donc sur des librairies natives qu’il sera nécessaire de livrer avec les applications Java et seul l’intégration au JDK permettrait de l’éviter. Or, malgré les appels de la communauté, JWebPane reste pour le moment absent de la liste des features du JDK 7 et il est uniquement question d’une mise à disposition sur Java.net.

RIA

• Sortie de SmartGWT 1.1
• FlashBuilder 4 supportera FlexUnit 4
• JavaFX 1.2 est arrivé

Le coin de la technique

• G1 Payant ! Oracle sonne-t-il le glas des machines virtuelles Java gratuites ?
• Jetty dévoile sa roadmap
• Sortie de Tellerium 0.6.0 RC1

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

• Conférence Google IO 2009
• Adobe présente Flash Catalyst à Paris

RIA

Sortie de SmartGWT 1.1

Il aura fallu attendre près de 6 mois pour pouvoir apprécier la nouvelle version de SmartGWT, le wrapper GWT de SmartClient par Sanjiv Jivan (sortie de la version 1.0 lors d’une précédente revue de presse), information relayée par l’auteur et par The Server Side.

Cette version 1.1 apporte de nombreuses nouveautés (liste exhaustive sur la release note) :

• Correction de plus de 50 bugs.
• Amélioration générale des performances des composants et des skins.
• Champs de formules et résumés (wizards, bindable avec des DataBoundComponent…).
• Support du GWT-RPC DataSource avec les DataBoundComponent (tableaux, arbres, menus…).
• Nombreuses documentations Javadoc (le gros défaut de GWT-Ext).
• API de récupération d’état de la vue depuis le serveur (pour de nombreux composants).
• Nouveaux exemples dans le Showcase au niveau de New Samples.
• Un projet Helloworld pour SmartGWT avec GWT 1.6 …

Une librairie open source gratuite dans son intégralité (licence LGPL), ça ne se refuse pas ou au moins ça se teste !

FlashBuilder 4 supportera FlexUnit 4

Bonne nouvelle pour les développeurs Flex, nous apprenons par InsideRIA que FlexUnit 4 pourra être utilisé sur -FlexBuilder 4- FlashBuilder 4.
Dans cet article, l’auteur nous présente les nouvelles fonctionnalités que propose FlexUnit 4 telles que :

• Création simplifiée de suites de tests.
• Création et intégration facile de test runner à d’autres frameworks.
• Utilisation de l’intégration continue grâce à une automatisation de l’intégration.
• Meilleure gestion des tests asynchrones.
• Meilleure gestion des exceptions.
• Comme les annotations en Junit 4, les tests peuvent être gérés par les Metadata.

La prochaine étape maintenant est d’intégrer le projet à FlashBuilder 4. Il est d’ailleurs possible de voter pour ce projet. Si cela vous intéresse n’hésitez pas à voter vous aussi.

JavaFX 1.2 est arrivé

En accord avec le planning annoncé dès décembre dernier lors de Devoxx, une nouvelle version de JavaFX vient d’être mise à disposition. Les apports sont nombreux et comblent certains manques de la version 1.1. Le site de JavaFX propose un tour d’horizon très complet des nouveautés et Stephen Chin en présente un résumé accompagné d’un guide de migration. On retiendra :

• Ajout de widgets propres à JavaFX, skinnables et disponibles sur toute les plate-formes. Il n’est donc plus nécessaire de faire appel à des composants Swing (qui étaient inaccessibles sur mobile). L’ensemble des composants simples sont disponibles (bouton, checkbox, …), par contre la ListView est le seul composant de haut niveau à être fourni, pas de table, ni de tree.
• Ajout de composants dédiés à la création de graphiques de type Area, Bar, Bubble, Line, Pie, Scatter et X/Y.
• Ajout de nouveaux layouts en supplément des VBox et HBox déjà disponibles.
• Support de Linux et Solaris.

La compatibilité des binaires générés par JavaFX n’est pas assurée entre cette nouvelle version 1.2 et ses prédécesseurs. Il sera donc nécessaire de recompiler les applications pour assurer la migration.

Le nouveau JavaFX sera donc sorti dans les temps pour être le sujet de nombreuses présentations et annonces lors de JavaOne qui débute aujourd’hui même à San Fransisco. Comme nous vous en parlions il y a quelques semaines, le support des TVs pourrait y faire l’objet d’une démonstration.

Le coin de la technique

G1 Payant ! Oracle sonne-t-il le glas des machines virtuelles Java gratuites ?

Oracle va-t-il rendre Java payant ? Cette question que tous posaient après l’annonce du rachat de Sun revient aujourd’hui au premier plan avec une phrase sibylline de l’annonce de la version 6 update 14 de la JVM de Sun :

« Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased… »

En théorie, la fonctionnalité concernée est encore expérimentale et le rachat de Sun par Oracle n’est pas clos : Oracle n’a pas à s’immiscer dans la gestion au quotidien de Sun ; il n’y aurait donc pas de raison que Sun change de stratégie sur la JVM.
Cependant, on n’a jamais vu de telles limitations contractuelles sur la JVM de Sun. Si les JVM mobile et temps réel ont toujours été payantes chez Sun comme IBM et BEA/Oracle, les JVMs serveur et poste de travail étaient traditionnellement gratuites … à un détails près : la JVM JRockit de BEA était devenue payante dès le rachat par Oracle ; on avait alors invoqué des considérations contractuelles qui empêchaient Oracle de distribuer gratuitement une JVM.

C’est aujourd’hui la très répandue JVM de Sun qui est menacée ; une fois de plus à la suite d’un rachat par Oracle. Faut-il craindre la fin des JVM gratuites ? Pour le poste de travail, cela parait très improbable faute de modèle économique crédible mais pour les serveurs, un revirement d’Oracle semble possible et dans la lignée de la nouvelle politique de JRockit. Il resterait alors disponibles gratuitement les JVM IBM J9 et Open JDK, le projet Open Source dont la gouvernance par Sun a été sujette à polémique ces derniers mois. Nous noterons au passage que G1 sera inclus dans la version 7 d’Open JDK.

Pour revenir sur les nouveautés de la JVM 6 update 14, nous retiendrons : la compression des pointeurs (-XX:+UseCompressedOops) pour les JVM 64 bits (cf. Java 64 bits, pas si souvent une bonne idée), l’optimisation des accès aux variables utilisées sur un seul thread ( -XX:+DoEscapeAnalysis ) et ce Garbage First (G1) Garbage Collector optimisé pour la gestion de grands volumes de mémoire mais réservé en production aux souscripteurs d’un contrat de support.

Jetty dévoile sa roadmap

Comme tous les conteneurs Servlet / JSP du marché, Jetty se prépare à l’arrivée de la JSR-315 (Servlet 3.0) prévue pour cet été. Par ailleurs, il opère également divers changements dûs à sa récente intégration à la fondation Eclipse.

Greg Wilkins a présenté une roadmap détaillée des fonctionnalités qui seront présentes dans les futures versions de Jetty.

Jetty 6 reste la version stable en attendant l’arrivée de son successeur.

Jetty 7 est la branche de développement que Greg Wilkins conseille d’adopter pour les projets débutant actuellement. Elle marquera la migration vers le package org.eclipse.jetty, et apportera une remodularisation accompagnée d’un packaging en bundle OSGi en supplément des artifacts Maven, et une préparation à Servlet 3.0 dont il proposera une preview.

Jetty 8 ne différera guère de son prédécesseur, il s’agira avant tout d’un rebuild en Java 1.6 exclusivement, accompagné d’une conformance stricte à Servlet 3.0 dont la spécification sera alors finalisée.

Aucune date précise n’est indiquée par l’auteur, mais il semble que la finalisation de la spécification Servlet 3.0 constituera le principal régulateur du calendrier de Jetty.

Sortie de Tellerium 0.6.0 RC1

Tellerium est un framework de tests unitaires d’interface utilisateur. Le projet s’appuie sur Selenium, est compatible avec JUnit et TestNG et permet d’écrire les tests en Java, Groovy ou par un DSL.

Les nouvelles fonctionnalités entre la version 0.5.0 et cette 0.6.0 sont plutôt nombreuses, on notera ainsi :

• Ajout du sélecteur jQuery (et du jQuery Cache).
• Support de Selenium 1.0 Beta 2 et Groovy 1.6.
• Core (Include, setCustomConfig, Dump method …).
• Selenium Grid (tests en parallèle).
• Archetype Maven (JUnit et TestNG) …

Plusieurs nouvelles fonctionnalités donc mais surtout de nombreuses optimisations de performances, des tests plus rapides et plus faciles à écrire, le tout utilisant les versions les plus récentes des projets dont il dépend. A noter aussi le plugin pour FireFox TrUMP (Tellerium UI Model Plugin) permettant d’écrire plus rapidement les tests (enregistrement des clicks, validation et customisation, export Groovy…).

Le téléchargement se passe par ici, et pour les pom ça se passe en bas de page par là.

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

Conférence Google IO 2009

Google I/O 2009 s’est tenu la semaine dernière à San Francisco. Il s’agit d’une des conférences destinées aux développeurs utilisateurs des applications et des API de Google. L’actualité autour de cette conférence étant relativement importante, nous avons décidé de traiter celle-ci dans un article séparé.

En voici les grandes lignes de ce qui s’est vu à Google I/O :

• Le futur du Web, avec les premières démonstrations émoustillantes Html 5.
• Google Wave, le prochain outil de communication et collaboration made in Google.
• La réconciliation de Google avec GWT, sortie de Gwt Query.
• Le futur d’Android, avec l’annonce de la branche Android 2.0 : Donut.
• Java et Google App Engine en GA.
• Google Web Elements, comment intégrer les services Google dans vos pages web.
• Les macros dans Google Document, avec Google Apps Script.
• Arrivée des extensions dans Chrome.

Pour en savoir plus, vous pouvez lire notre billet dédié au sujet.

Adobe présente Flash Catalyst à Paris

Mercredi 3 Juin 2009 à 16h, Adobe propose une présentation de Flash Catalyst. Cet outil destiné aux designers permet de concevoir des composants graphiques riches sans programmation. Ces créations peuvent ensuite être fournies à un développeur Flex pour que ce dernier se charge de la programmation intelligente.
Cette présentation va se diviser en deux sessions sous formes de conférences et d’ateliers :

• Une session développeur.
• Une session designer.

Elle se clôtura par un cocktail à 19h30.
Pour plus d’informations ou pour vous inscrire ça se passe ici.

Rod Johnson a placé SpringSource sous le signe des gains de productivité pour l’écosystème Java. Gains de productivité aussi bien sur la phase de build que dans celle du déploiement et de l’exploitation d’applications Java, un domaine dans lequel SpringSource est moins connu.

Pour la phase de build, SpringSource introduit une rupture dans le développement d’applications Java en proposant le duo Groovy&Grails qui concilie la puissance de la plateforme Java avec la productivité des très en vogue langages dynamiques. Si cette rupture est trop forte pour vous, Springsource propose un axe intermédiaire mais déjà très innovant avec Spring Roo, un façonnage du langage générique Java pour les spécificités de l’informatique de gestion.

Pour la phase de déploiement et d’exploitation, Adrian Coyler a présenté une vision inspirée des architectures Platform as a Service (e.g. Google App Engine) et Data Center as a Service (e.g. Amazon EC2, Cloud Foundry) pour aboutir à une proposition de Your Data Center as a Service. Cette vision est séduisante, dm Server, Application Management Suite et un partenariat avec VMWare en seront les piliers mais rien de concret n’est encore disponible.

Côté annonces, peu de nouvelles fracassantes pour cette édition. Pas de grands communiqués depuis notre revue de presse de lundi dernier, en résumé :

• Sortie de tcServer 1.0 en GA, probablement le meilleur moyen pour SpringSource de faire rentrer de l’argent.
• Un nouveau produit : Spring ROO, il s’agit d’un générateur de code Java offrant la possibilité d’effectuer des opérations CRUD facilement mais pas seulement…
• Diffusion gratuite de Spring Tool Suite, ensemble de plugins Eclipse dédiés aux technologies Spring.

Le catalogue de produits et services s’agrandit, et la communauté avec. La parade de SpringSource afin de séduire un éventuel racheteur continue de se mettre en place.

Nous vous avions soumis une liste de questions, c’est maintenant l’heure de relever les copies voici quelques débuts de réponses aux interrogations que nous nous posions :

Tomcat, tcServer et dmServer

SpringSource a beaucoup investi sur les technologies serveur autour de Tomcat depuis le rachat de Covalent l’année dernière. Tomcat 6 reste un projet Apache et n’est pas sous le contrôle direct de SpringSource. Cela dit, Mark Thomas devenant probablement Release Manager de Tomcat 7, SpringSource devrait avoir la possibilité de pousser d’avantage ses idées, même si le mécanisme de vote par les committers du projet Tomcat permet à n’importe lequel d’entre eux de bloquer une initiative de SpringSource. Par exemple, nous verrons si le nouveau pool de connexions JDBC développé par Filip Hanik deviendra le pool par défaut de Tomcat 7.

La plus belle carte à jouer reste probablement celle de tcServer. Avec ce nouveau serveur d’applications, SpringSource espère charmer aussi bien les utilisateurs de gros serveurs d’applications onéreux et compliqués n’utilisant que peu de fonctionnalités de leur bulldozer, que les utilisateurs de Tomcat en manque d’outils d’administration et de supervision.

A plus long terme, ce serveur doit également jouer le rôle de chant des sirènes en proposant aux utilisateurs de tcServer une migration simple vers dmServer. C’est là que la stratégie de SpringSource n’est pas complètement claire. Nous avons eu deux sons de cloches à la question : que deviendra tcServer lorsque dmServer disposera de la compatibilité Tomcat (comme cela est prévu dans la roadmap) ? Là où le directeur Marketing de SpringSource Europe nous affirme que, peu à peu, dmServer sera amené à remplacer complètement tcServer et que ce dernier devra disparaître probablement à moyen terme; Mark Thomas nous répond qu’au contraire les deux serveurs continueront leur existence avec des roadmaps bien différentes. Dans les faits, tcServer a été créé pour combler des fonctionnalités en avance de phase par rapport à la roadmap de dmServer. Peut-être cet appel d’air a-t-il donné plus d’idées aux développeurs de tcServer ?

Quant à dmServer, il n’est pas encore tout à fait sec. Non seulement la communauté n’est pas forcement prête à passer à un serveur d’applications full modulaires, mais aussi, de l’aveu même de Jurgen Holler, il manque un certain nombre de fonctionnalités core. C’est d’ailleurs l’une des raisons qu’il donne pour expliquer le descopage de la certification Java EE 6 Web Profile, qui n’apparait plus dans leur roadmap. Ils ne sont pas complètement opposés à la passer (et encore) mais ce ne sera pas pour demain. On aurait pourtant pensé qu’il s’agirait d’un moyen supplémentaire de rassurer les équipes d’exploitation et faciliter l’accès à leurs produits.

Et enfin, pour clôturer ce sujet, à titre informatif, dmServer est développé par une équipe anglaise constituée de 5 à 8 personnes. Cette petite taille d’équipe est voulue car propice aux méthodes agiles et à un fonctionnement itératif à cycle court.

Spring 3.0 et Java EE

Si la certification dmServer avec Java EE n’est plus d’actualité, cela ne veut pas forcement dire que SpringSource se ferme complètement à Java EE. La présentation de Jurgen Holler à ce sujet était d’ailleurs probablement l’une des plus intéressantes de ces 3 jours. Là où Rod Johnson, durant son Keynote, se contentait de casser Java EE sans trop apporter d’arguments, Jurgen a effectué un tour détaché et pragmatique des futures fonctionnalités de Java EE 6.

Java EE est source d’inspiration de Spring. De nombreux composants Java EE 5 et 6 se retrouvent ou se retrouveront directement dans Spring. L’inverse est également vrai, pour Jurgen, les EJB 3.1 sont par exemple très largement inspirés de la stack Spring. Au-delà de la petite guerre des chapelles, prendre les bonnes idées où elles se trouvent est une bonne chose. Il me semble que cette inspiration mutuelle fait avancer tout le monde dans la bonne direction et que cette petite concurrence est propice à l’innovation. Ces deux stacks proposent des approches différentes : là où Java EE reste bas niveau en offrant une plateforme de déploiement et des providers de services système, Spring s’attache à rester le plus proche possible de vos applications.

C’est donc un fait, Spring 3.x disposera de fonctionnalité Java EE 6, en voici un petit tour d’horizon :

• Servlet 3.0 est prévu pour être intégré à Spring 3.2. Le support d’endpoints HTTP asynchrones comet sera rendu compatible avec Spring MVC par l’intermédiaire d’une requête et réponse spéciale (pas plus d’information à ce sujet). La détection automatique des servlets destinée à réduire la taille du fichier web.xml permettra l’auto déploiement du Spring Web Context, cette fonctionnalité n’apportera évidemment que peu de choses dans une stack Spring.
• JSR-236 – Concurrency utility for Java EE, Spring 3.0 contiendra probablement un nouvel adaptateur de scheduling si cette JSR, passé en statut inactif n’est pas descopé de Java EE 6.
• Évolutions naturelles des supports JSF et JPA, leurs versions 2.0 respectives seront donc également intégrées à Spring 3.0. Il en est de même pour la JSR-303 bean validation.
• Le support REST est l’une des grandes nouveautés de Spring 3.0. Dans ce sens, les endpoints JAX-RS pourront être managés comme de simples beans Spring.
• La JSR-299 – Java Contexts and Dependency Injection (JCDI), anciennement appelée WebBeans, est probablement la JSR la plus problématique. D’après Jurgen, chaque question posée sur cette JSR remet en cause les bases même de cette spécification dont le scope d’utilisation reste relativement flou.

Spring ROO, le petit dernier

Bien que nous connaissions l’existence de ce projet, la conférence nous a permis d’en savoir plus à son sujet et surtout de le voir fonctionner en live. Ce générateur de code est le fruit du travail d’un homme sur plusieurs années. C’est Ben Alex, le papa de Spring Security qui s’y est collé. Il a été rejoint plus récemment par une seconde personne à mi-temps.

ROO permet la génération et la configuration d’applications Java sans avoir à taper la moindre ligne de code. De la persistance à la couche présentation, tout est généré à la demande par l’intermédiaire de lignes de commandes à exécuter dans une console spécifique. La console est disponible sous plusieurs formes : directement intégrée au shell ou par l’intermédiaire d’un plugin Eclipse SpringSource Tool Suite. ROO est téléchargeable dans sa version alpha depuis mercredi soir. Pour l’avoir testé un peu, en voici nos premiers retours. Un billet complémentaire dédié à ce sujet viendra probablement compléter celui-ci.

// initialisation d'un projet à partir d'un répertoire vierge
roo> create project -topLevelPackage fr.xebia.roosample.blog
// configuration du niveau de log
roo> configure logging -level DEBUG
// ajout du support JPA
roo> install jpa -database H2_IN_MEMORY -provider HIBERNATE
// création d'une entité JPA et de ses champs
roo> new persistent class jpa -name ~.model.Article
roo> add field string -fieldName title -notNull -sizeMax 100
roo> add field string -fieldName content
// génération de finders
roo> list finders for -class ~.model.Article
roo> install finder -class ~.model.Article -finderName findArticlesByTitleLike
// generation du controller associé
roo> new controller automatic -name ~.web.ArticleController -formBackingObject ~.model.Article

Si les lignes de commandes vous paraissent longues et compliquées, il n’en est rien. J’avoue avoir été séduit par la facilité avec laquelle vous écrivez vos commandes : la console vous guide à chaque étape en vous fournissant une aide à chaque instant et surtout une complétion très pratique d’utilisation. Autre facilité non négligeable, la saisie contextuelle. Les commandes que vous tapez s’exécutent toujours en fonction du dernier concept manipulé. Cela vous permet d’omettre de saisir certaines options, la console se charge que les retrouver en fonction du contexte. Une console dans un monde d’IDE et de wizzards ? Quelle drôle d’idée ! Et pourtant, le résultat plutôt efficace, le gain en productivité est notable.

Une fois que le projet est créé, vous pouvez à tout moment générer le squelette Eclipse via Maven pour consulter et étoffer vos sources. Et là encore, vous risquez d’être surpris ! ROO remet en cause le modèle en couche qui faisait autrefois l’unanimité dans le monde Java. En plus de l’utilisation des objets du domaine dans la vue, ROO supprime la couche DAO au profit du modèle Active Record avec l’ajout de méthodes d’instance merge / remove et statiques … cela risque de ne pas plaire à tout le monde. De plus, le code source est façonné aux besoins de l’informatique de gestion. Pour le développeur, le code est généré de manière transparente (getter, setter, toString merge, remove, finder, …) grâce au compilateur AOP d’AspectJ : la majorité de celui-ci est déléguée dans des aspects, les beans sont annotés par des Annotations spécifiques Roo : @RooEntity, @RooJavaBean, @RooToString pour les activer.

Pour plus d’information sur le sujet, Ben Alex vient de blogger sur ROO.

Groovy

Six mois après le rachat de G2One, Spring ne semble pas tirer pleinement profit des possibilités Groovy et Grails. Guillaume Laforge passe plus de temps sur les évolutions de Groovy et sa prochaine version 1.7 que sur des intégrations avec la stack Spring. Il m’a tout de même dit avoir effectué quelques prototypes : intégration Groovy avec Spring Batch, configuration tcServer et dmServer avec Groovy, mais aucun d’entre eux n’a pour le moment débouché sur un développement concret.

Concernant Grails, G2One a été racheté après le démarrage de Spring ROO, aucune coordination n’a donc été possible entre ses deux projets.

Les partenariats

De manière générale, nous avons été déçus des fruits récoltés des différents partenariats (représentés à la conférence).
Seul Spring Batch, porté par Accenture, propose un outil finalisé et abouti.

Concernant le partenariat Terracotta, rien de concret pour le moment. Là où nous espérions une collaboration forte avec Spring, il nous a semblé que la roadmap était plutôt vide. Par ailleurs, en discutant avec eux, on avait plus l’impression de leur donner des idées que de récolter des informations.

Le partenariat avec Adobe est légèrement plus abouti avec un début d’intégration entre Spring et Blase DS. Après en avoir descendu les sources, le contenu du projet ne nous a pas fait rêver. Nous n’avons pas pu récolter d’autres informations sur d’éventuels autres futurs projets en commun.

Le mot de la fin

La communication sur leur site officiel en témoigne, SpringSource ne se focalise plus seulement sur la phase de développement. Leur catalogue d’offres et de services leur permet de toucher un plus large public, autour d’un maître mot : ‘gain en productivité’.

• depuis la phase de développement : avec Spring ROO, Groovy…
• jusqu’à l’exploitation : avec AMS, tcServer…
• en passant par le déploiement : virtualisation, platform as a service…

Agilité

• Programmation en binôme vs Revue de Code
• Sensibilisation Scrum pour les Gamers
• Transmettez la vision produit à votre équipe.

RIA

• 11 belles librairies Web UI
• De nouveaux frameworks pour renforcer JavaFx
• Adobe continue l’ouverture de ses technologies RIA
• Session de formation gratuite pour JavaFx
• RIA en chiffres

Le coin de la technique

• Interview de Rod Johnson, Spring 3.0 et le reste
• Java EE 6 public review : Un Fat Web Profile et Web Beans en suspend
• JSR-299 (ex Web Beans) : Une JSR « Dependency Injection » sans SpringSource
• Sortie d’Apache Ivy 2.0
• Sortie de VisualVM 1.1

Agilité

Programmation en binôme vs Revue de Code

Chris Sims rebondit sur l’article de Theodore Nguyen-Cao, Pair Programming > Code Reviews, pour relancer le débat Pair Programming vs Code Review :

Étant donné que la revue de code se fait sur un code plus avancé qu’en programmation par binôme, la détection / correction de bugs est plus complexe au stade revue. Cependant, la mobilisation deux personnes sur la même tâche représente un coût qu’il ne faut pas non plus négliger.

La programmation en binôme (ou Pair Programming) a une grosse valeur ajoutée dans l’intégration de code. Voici le fonctionnement :

• Le pilote du binôme veut intégrer une API
• Le copilote du binôme a développé l’API
• Le copilote décrit comment fonctionne l’API
• Le pilote essaye d’intégrer l’API dans son environnement
• Le pilote émet des souhaits pour l’API
• Le copilote essaye d’intégrer ces souhaits (en tenant compte des autres utilisateurs de l’API)
• Le copilote indique au pilote la prochaine version de l’API

Les deux parties sont gagnantes :

• Le pilote intègre en douceur et en toute tranquillité
• L’API est améliorée, on a une API plus « utilisable »
• Les deux parties comprennent les besoins et contraintes de chacun

La revue de code permet à un tiers de jeter un regard neuf sur un code développé. Kent Beck, dans son livre Implementation Pattern, affirme que le code réalisé par un développeur doit expliciter ses intentions. La revue de code peut être une activité judicieuse pour vérifier cette règle.

Ainsi la revue de code permet d’améliorer la maintenabilité du code :

• Amélioration de l’organisation des classes (nom des classes et packages)
• Partage des expériences de conception ou de patterns
• Partage des connaissances
• Support d’un développeur novice par un développeur plus expérimenté

La revue de code peut être courte (30 minutes) et assez récurrente (une à deux fois par semaine).

Sensibilisation Scrum pour les Gamers

Une fois n’est pas coutume, voici un lien qui nous est proposé par un collègue de mission. Il s’agit d’une mini formation Scrum qui s’est glissée … dans une vidéo montrant les coulisses du jeu DC Universe Online. Cela se passe aux alentours de la 2e minute de la vidéo. Au programme, rapide description du fonctionnement des sprints et du Scrum board, développement en cycles courts et démonstrations possibles à chaque itération.
Clinton Keith avait déjà partagé son expérience de Scrum dans les jeux vidéos il y a un peu plus d’un an.
Un Gamer averti en vaut deux! Merci donc à Olivier pour ce lien peu commun.

Transmettez la vision produit à votre équipe.

Vous êtes vous déjà demandé si votre équipe de réalisation est guidée par une vision produit, insufflée par le Product Owner ? Selon Roman Pichler (voir l’article), il est important que chaque membre de l’équipe soit inspiré, motivé et concerné par le travail en cours de réalisation. Il nous fournit cinq questions fondamentales auxquelles tout membre de l’équipe devrait être capable de répondre :

• Qui va acheter le produit et quels seront les clients ?
• Quels besoins le produit va-t-il adresser ?
• Quels attributs du produit sont critiques pour la satisfaction du client et le succès de produit ?
• Quelle comparaison faites-vous avec des produits similaires?
• Quels sont les délais et le budget impartis pour réaliser et lancer le produit ?

Même si l’idée ici n’est pas de transformer chaque membre de votre équipe en Directeur du Marketing, il est important que vous mesuriez la connaissance de l’équipe dans ces domaines. C’est l’un des principes agiles: avoir confiance en son équipe (et donc ne pas l’infantiliser en croyant qu’elle ne peut pas ou ne doit pas comprendre ces aspects).

RIA

11 belles librairies Web UI

Quand on parle d’APIs JavaScript Web 2.0 (frameworks/graphiques), on pense tout de suite à jQuery, Prototype, ExtJS, Script.aculo.us, Dojo ou bien encore Rialto.

Mais il ne faut pas limiter la liste à celles-ci ! Il y a une multitude d’autres librairies, qui sont pour certaines bien plus belles/rapides/robustes qui celles citées ci-dessus. Et on pourra en découvrir (ou redécouvrir) de nouvelles du côté de chez Antonio Lupetti qui nous référence 10 Beautiful Web UI librairies. Parmi celles citées, on retiendra particulièrement :

• IT Mill Toolkit (démo) intégrant des composants entièrement Java avec GWT,
• LivePipe UI (démo), un framework graphique s’appuyant sur prototype,
• Jitsu (démo) avec définition des écrans par XML (qui sera ensuite compilé) et de nombreux outils intégrés dont la gestion du bouton retour et le data binding,
• MochaUI (démo) qui s’appuie sur le framework MooTools,
• Echo (démo) qui a été testé lors de notre RIA Contest,
• Yahoo! UI (démo => Yahoo! Mail ) qui a servi de base à ExtJS (qui n’était à l’origine qu’un add-on pour YUI).

On notera aussi dans la liste certaines librairies moins connues comme :

• iWebKit,
• Sigma Ajax UI Builder,
• WUI,
• Butterfly Web UI.

Mais l’article en donne 10 et c’est écrit 11 dans le titre ?!? En effet, à cette liste je rajouterai comme 11ème librairie DHTMLX, une API peu connue mais qui mérite de l’être. En plus d’être visuellement très abouti, chaque composant (téléchargeable à l’unité ou dans une suite) possède un grand nombre de fonctionnalités par rapport aux autres librairies du marché. Force est de constater qu’afficher un tableau qui peut contenir plus de 10000 enregistrements, avec des colonnes cachées/bloquées au runtime, le tout se voyant appliqué 3 filtres par défaut est très simple à mettre en place et surtout ne fait même pas sourciller l’API (affichage très rapide pour les navigateurs les plus récents et raisonnable pour d’anciennes versions) !

Plusieurs démos sont accessibles, on notera la bonne performance du RSS reader, de l’administration BDD ou bien encore de l’éditeur XML. Je vous la recommande fortement !

De nouveaux frameworks pour renforcer JavaFx

La communauté Java commence à se mobiliser autour de JavaFx.
Outre la sortie prochaine du premier livre consacré au sujet (Pro JavaFX™ Platform: Script, Desktop and Mobile RIA with Java™ Technology), cette semaine a vue la sortie de deux projets OpenSource autour du RIA de Sun : JFXtras (0.2) et WidgetFx (1.0.1)

Ces deux projets sont menés par Stephen Chin, qu’InfoQ a interviewé.

On notera tout d’abord qu’on a affaire à 2 projets communautaires, indépendants de Sun, et qui viennent compléter quelques vides du coté de JavaFx. Cependant, Stephen Chin insiste sur le fait que, bien que très occupées (probablement par la prochaine sortie de JavaFx Mobile), les équipes Sun avec lesquelles il est en contacte supporte et aide régulièrement cette initiative.

Entrons dans le détail de ces frameworks.
JFXtras apporte un ensemble d’ajouts à l’API Fx

• JFXtras Grid – un layout de type grille 100 % Java
• JFXStage / JFXDialog – Des classes pour remplacer celles de Fx, offrant un plus grand spectre fonctionnel.
• JFXtras Test – Un framework de tests unitaires
• JFXWorker – Une solution de traitement asynchrone

WidgetFx offre des outils de création aussi qu’un contenur de widgets performant et portable sur plusieurs plateformes (Windows XP/Vista, Linux et Mac OS X)

• Support de personnalisation graphique des widgets et du Dock.
• Support des composants Flash/Flex.
• Amélioration des performances du moteur des widgets.
• Un nouveau thème pour le Dock.

Stephen Chin revient aussi sur un grand nombre de sujets :

• les éléments moteurs différenciants de Fx, à savoir l’intégration Java et Fx Mobile
• le futur de Fx, fortement lié aux développements des plugins pour les différents IDE
• les facteurs clés pour réussir un projet Fx, à savoir la communication accrue avec les équipes de design, l’obtention de retours rapides de la part des utilisateurs (tiens tiens…) et la réutilisation maximale des composants open source.
• ses souhaits pour les futures version de Fx : support de l’asynchronicité, inclusion de Fx dans Java, intégration au Web 2.0

Pour voir widgetFx en action, suivez le lien

Adobe continue l’ouverture de ses technologies RIA

Dionysios G.Synodinos nous apprend dans Adobe to publish the Real-Time Messaging Protocol (RTMP) que Adobe a choisit de mettre à disposition son protocole de communication temps réel destiné à la transmission de données, de flux audio et vidéo sur de multiples supports (télévisions, ordinateurs, téléphones…).
Adobe riposte ainsi aux récentes ouvertures de technologies faites par Sun JavaFx et Microsoft Silverlight. Par ailleurs, Adobe annonce de futures ouvertures comme notamment:

• la suppression des restrictions sur les formats SWF, FLV/F4V (FLV est le format vidéo de Flash). Depuis la version 9 de flash player, celui-ci prend en compte le mp4 et a mis au point le format F4V afin de supporter ce dernier.
• la mise à disposition des protocoles Adobe Flash Cast et AMF. Le protocole Flash Cast, basé sur Adobe Mobile Platform permet d’utiliser des services multimédia en mode offline sur des appareils mobiles (téléphone portable, PDA…). En ce qui concerne AMF (Action Message Format), c’est le protocole binaire de transfert des données entre le serveur et le client.

Avec ces annonces, Adobe réaffirme sa volonté de rester leader dans le domaine des RIA. Reste à savoir si cela suffira pour contrer Silverlight et Java FX.

Session de formation gratuite pour JavaFx

Le site JavaPassion propose un ensemble de formations en ligne concernant JavaFx. Tout au long des quinze (!) sessions programmées d’ici Mai, Jim Weaver et Sang Shin balayeront toutes les facettes du RIA de Sun.
Toutes les explications, et tous les agendas, sur la page de JavaPassion.
A noter : cette page contient un grand nombre de liens vers des documents de référence. C’est donc une mine d’or pour qui s’intéresse un tant soit peu à cette technologie.

RIA en chiffres

Ted Patrick présente sur son blog un site permettant de visualiser la proportion de plugins Flash Player et de Silverlight installés sur le navigateur des visiteurs pour les 90 derniers jours. On savait déjà que Flash Player était installé sur la quasi totalité du parc informatique mondial, mais l’étude nous donne le pourcentage d’installation de Silverlight (entre 15 et 20%). Les résultats peuvent être visualisés par navigateur, par système d’exploitation, et par langue : http://www.riastats.com.

Le coin de la technique

Interview de Rod Johnson, Spring 3.0 et le reste

Dans une interview publiée cette semaine sur InfoQ sous forme d’une vidéo de 30 minutes, Rod Johnson répond à quelques questions indiscrètes sur l’état d’avancement et les orientations des différents projets de la Springosphère.

Nous retiendrons :

• Le support des fonctionnalités REST est certainement l’une des nouveautés les plus attendues pour le prochain Spring 3.0 dont le premier milestone est disponible depuis fin 2008. Si cette fonctionnalité présente quelques similitudes avec Spring WS, elles n’adressent pas les mêmes problématiques et restent complémentaires. À l’origine le support de REST devait d’ailleurs être implémenté sur la base de Spring WS. Si au final Spring MVC a été jugé plus adapté, certaines fonctionnalités ont tout de même été extraites de Spring WS pour être utilisées (OXM).
• Si comme nous, vous vous demandiez quelles étaient les intentions de SpringSource après le rachat de G2One en novembre dernier, voici un embryon de réponse. Rod nous dévoile les premiers fruits de ce rachat avec Spring Java Config. Disponible en test depuis 6 mois environ en pré-version dans le jpetclinic (projet exemple Spring), nous nous interrogions sur la valeur ajoutée apportée par cette fonctionnalité. Pour mémoire, elle permet de configurer vos applications Spring par l’intermédiaire de code Java comme vous le feriez en XML (voici un exemple de code). Cette possibilité prend tout son sens si on la croise avec les commodités offertes par Groovy. Vous pourrez probablement remplacer demain vos fichiers de configuration statique XML par des DSL dynamiques Spring-Groovy.
• Spring 3.0 sera l’occasion de mettre en pratique la nouvelle politique de maintenance adoptée par Spring l’année dernière. Celle-ci incite fortement ses utilisateurs à coller aux dernières versions du framework. Les corrections de bugs n’étant plus repackagées sur les anciennes versions majeures du framework. Ainsi, à la sortie de Spring 3.0, si vous trouvez un bug dans l’un des modules de votre Spring 2.5.6, il vous faudra : soit monter de version, soit repackager vous-même votre propre version corrigée. Cela ne devrait pas poser trop de problèmes au vue de la maturité de la version 2.5. De plus, la rétrocompatibilité exemplaire entre Spring 3.0 et Spring 2.5 devrait vous permettre une montée de version en douceur. Rappelons tout de même que Spring pratique le pruning : la plupart des éléments dépréciés dans Spring 2.5 disparaîtront donc de la version 3.0.
• Certains notent que Java EE se rapproche de Spring en offrant des fonctionnalités similaires, l’inverse est également vrai : Spring dmServer implémentera le profil Web de la spécification Java EE. Toutes les spécifications ne seront pas couvertes dans leur intégralité, c’est la nuance qui sépare un rapprochement d’une convergence.
• C’est sans surprise que Rod nous parle de la distance que Spring prend avec SCA. SpringSource a fait le choix de partir sur une technologie concurrente plus porteuse : OSGi. De plus, SCA ne dispose pas d’un nombre d’utilisateurs assez important pour intéresser SpringSource pour le moment.
• Cette interview nous a également permis de découvrir une fonctionnalité peu connue pourtant présente depuis Spring 2.0 : l’annotation @Configurable.

Pour conclure, si cette interview n’apporte véritablement aucune annonce fondamentale sur la stratégie de SpringSource, elle a le mérite de synthétiser les discussions en cours et de donner une idée plus précise de la roadmap de Spring pour les mois à venir.

Java EE 6 public review : Un Fat Web Profile et Web Beans en suspend

Roberto Chinnici, Java EE 6 specification leader annonce la sortie de la public review de cette spécification. Nous noterons :

• Le Web Profile est assez lourd avec notamment les transactions distribuées (JTA), des EJB Lite et du controversé JSF. Certains trouveront que ce poids sera une barrière à l’entrée des éditeurs intéressés par ce profil léger ; d’autres estimeront que des technologies comme les transactions distribuées sont aujourd’hui incontournables. Le débat est sans fin
• JSR 299 « Web Beans », récemment remis à plat et renommé « Java Contexts and Dependency Injection » a pour le moment été retiré de Java EE 6 (voir ci dessous).
• Servlet 3.0 nous a un peu déçu (cf Servlet 3.0 : une API innovante et convergente ?)
• Les fonctionnalités dépréciées qui pourront disparaître dans Java EE 7 (aka pruning) : EJB entity beans (remplacés par Java Persistence), JAX-RPC (remplacé par JAX-WS), JAX-R (usage limité qui ne nécessite pas un statut ‘required’).

JSR-299 (ex Web Beans) : Une JSR « Dependency Injection » sans SpringSource

Nous avions évoqué dans Web Beans, un énième modèle de composant pour Java EE ? le problème de positionnement de cette JSR. Antonio Goncalves nous avait confirmé au Paris JUG que l’intégration de cette JSR à Java EE 6 était compliquée.

Gavin King nous rapporte cette semaine dans Revised Public Draft of JSR-299: Java Contexts and Dependency Injection que, du fait des retours de plusieurs membres du Java EE 6 Expert Group, la JSR dont il est le leader a été profondément remaniée pour mieux s’intégrer à la plateforme Java EE.

Nous retiendrons les points suivants :

• La JSR est renommée « Java Contexts and Dependency Injection », un titre beaucoup plus clair que le vague « Web Beans ».
• La « Dependency Injection » sera assurée par les conteneurs ‘légaux’ de Java EE : le conteneur EJB et le conteneur embarquable EJB Lite (déploiment dans un .war, etc).
• Les mécanismes d’intercepteurs seront intégrés à ceux déjà existant dans la spécification EJB 3.1 .
• JSR 299 n’est pour le moment pas inclue dans Java EE 6.

Si le renommage de cette JSR a le mérite d’appeler les choses par leur nom, on peut s’inquiéter de ce revirement très tardif et s’étonner de l’absence de SpringSource d’une JSR sur laquelle Rod Jonhson aurait la légitimité d’être leader, eut égard aux parts de marché et à la vitalité du conteneur Spring. Les risques de ratage de l’API semblent importants. Ne vaudrait-il pas mieux recommencer ce chantier sur des bases claires ?

Une JSR « Dependency Injection » sans SpringSource, c’est comme une JSR Java Persistance API sans JBoss/Hibernate

Sortie d’Apache Ivy 2.0

Apache a annoncé la sortie de Ivy 2.0, première version d’Ivy sous licence Apache.

Pour rappel, Ivy est un outil de gestion de dépendance agile initialement créé par Xavier Hanin. Il peut être comparé à Maven2, même si Ivy a un spectre de fonctionnalités moins larges. Il est spécialisé dans la gestion de dépendances, qu’il apporte à Ant quand les deux outils sont associés.

Les améliorations majeures sont :

• Passage sous licence Apache, Ivy est maintenant un projet Apache (anciennement projet Jayasoft)
• Amélioration de la compatibilité avec Maven et ses dépôts d’artefacts
• Amélioration du fonctionnement interne (cache, resolvers, etc)

Sortie de VisualVM 1.1

VisualVM, l’outil de surveillance d’applications java vient de sortir en version 1.1. Nous vous avions annoncé, dans un précédent post que cet outil est maintenant intégré au JDK6 update 7. Cette nouvelle version intègre de nombreuses fonctionnalités et améliorations. L’API a été étendue pour le développement de plugins.

Des plugins permettent d’intégrer VisualVM à Eclipse et Intellij Idea.
Parmi les nouvelles fonctionnalités, on peut noter :

• Le monitoring de l’utilisation CPU et mémoire (Garbage Collector) pour chaque application.
• Une vue en mode Tableau sur l’onglet des Threads
• Monitoring des JVM IBM via une connexion JMX.
• VisualVM est basée sur la plateforme NetBeans 6.5

La suite des nouveautés ici : http://blogs.sun.com/nbprofiler/entry/visualvm_1_1_released

Par ailleurs, Danny Coward annonce l’intégration de VisualVM dans la plateforme de clustering TerraCotta.

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

Agilité

• Les bases de Scrum, en 10 minutes, avec le sourire.

RIA

• Native Client de Google et Alchemy d’Adobe
• Spring BlazeDS Integration 1.0.0.M1
• Choisir sa solution RIA

Le coin de la technique

• OpenXava 3.1 est disponible
• Java Persistence API 2.0 Public Draft

Agilité

Les bases de Scrum, en 10 minutes, avec le sourire.

En 2009, je vais tenter de comprendre ce que Xebia raconte dans la partie Agilité de sa revue de presse. Si vous faites cette bonne résolution, alors la vidéo suivante est pour vous ! Hamid Shojaee (Axosoft) résume en 8 minutes les principaux concepts de Scrum.

Cliquer ici pour voir la vidéo.

RIA

Native Client de Google et Alchemy d’Adobe

Google annonce la sortie de Native Client, une technologie permettant d’exécuter du code natif directement dans le navigateur. Le but de Native Client est d’exploiter le processeur et la carte graphique du poste client pour pouvoir mettre en place des applications web plus performantes. Google rassure en disant que cette exploitation ne remettra en cause ni la neutralité du navigateur, ni la sécurité, ni la portabilité des applications sur les différents systèmes d’exploitation.

Il est possible de tester une version expérimentale de Native Client. À noter pour le moment que cette version n’est compatible qu’avec les navigateurs suivants : Firefox, Safari, Opera et Google Chrome; et sur les systèmes d’exploitations suivants : Windows, Mac et Linux qui ont un processeur x86.

Coïncidence ou pas, Adobe a présenté, lors de ses journées Adobe MAX, Alchemy qui offre les mêmes fonctionnalités que Native Client.

Alchemy est un projet d’Adobe Labs permettant d’intégrer du code C ou C++ dans une machine virtuelle ActionScript. Le code C/C++ est d’abord compilé en ActionScript3 dans un swc ou swf. Il peut ensuite fonctionner sur Flash Player 10 ou AIR 1.5, sécurisé par les protections Flash Player.

Quoi qu’il en soit, le but de ces technologies reste le même : faire en sorte que les applications web deviennent plus puissantes. Cela ne devrait donc pas concerner l’informatique de gestion. Mais pour les applications qui demandent beaucoup de ressources, telles que les jeux en ligne par exemple, cela pourrait changer la donne.

Une question reste cependant en suspend. Pourquoi Google a t’il décidé de sortir cette technologie ? Java Applets, ActiveX, Flash, Flex, Air, Silverlight, JavaFX, ce ne sont pas les technologies concurrentes qui manquent. Native Client ressemble d’ailleurs plus à une nouvelle version d’ActiveX cross-browser qu’à une nouvelle technologie RIA au sens Flex ou SilverLight. Certains pensent que cette technologie est le fruit d’un travail indépendant ne répondant à aucune vision technique cohérente à long terme. D’autres, au contraire, pensent qu’il s’agit d’un pas de plus vers un système d’exploitation made in Google. Le débat est ouvert, difficile de s’avancer pour le moment … Une fois de plus, Google est arrivé à faire le buzz autour de ses technologies.

Pour ceux qui voudraient tester Quake made in Native Client, voici le lien

Spring BlazeDS Integration 1.0.0.M1

Nous en parlions la semaine dernière, c’est maintenant officiel, le premier milestone de Spring BlaseDS Integration est maintenant disponible.
Alors à quoi ressemble cette intégration ? Elle vous permettra de mixer les configurations BlaseDS et Spring à votre guise. L’idée est de laisser les configurations statiques d’infrastructure dans le fichier de configuration BlaseDS et d’externaliser le reste dans les fichiers de configuration Spring. Cette solution devrait donc plaire à tout le monde : les utilisateurs de BlaseDS ne devraient pas être perdus, le mécanisme général restant inchangé ; les utilisateurs Spring s’y retrouveront également avec une configuration standard Spring MVC et Spring Remoting.

Voici quelques détails de cette configuration :

• Seule la configuration de la DispatcherServlet de Spring MVC est nécessaire
• L’exposition du MessageBroker de BlazeDS passe par :
  • la déclaration d’un FactoryBean dans le fichier de configuration XML de Spring MVC : MessageBrokerFactoryBean
  • le routage des requêtes de la DispatcherServlet vers le MessageBroker via la configuration d’un HandlerMapping
• À la manière de Spring Remoting, il ne vous reste plus qu’à exposer vos services Spring au MessageBroker avec la configuration d’un nouveau type d’Exporter : le FlexRemotingServiceExporter

Même si nous n’avons pas encore testé cette solution, cette intégration aussi simple qu’élégante rapproche sans conteste les développeurs Java au développement d’applications Flex.

Choisir sa solution RIA

Les solutions RIA sont de plus en plus nombreuses et il devient difficile de trancher catégoriquement pour l’une ou l’autre lors du démarrage d’un projet. Très souvent, une librairie est choisie par sa côte de popularité alors qu’elle ne correspond pas forcément au besoin client.
Au final, l’énergie dépensée pour apprendre, utiliser et adapter ces widgets/actions/effets dans le projet se révèle très coûteuse en temps, en maintenance…

Robbie Cheng (développeur principal de ZK Mobile pour Android) éclaircit nos esprits avec l’article How to Choose an RIA Solution sur Sys-Con avec un Top 10 des critères architecte et manager à prendre en compte lors du choix de sa solution.

Sans surprise, côté architecte, on se retrouve avec :

• de nombreux widgets, simples, des fonctionnalités comme le lazy loading ou le drag & drop, des pop-up…,
• facilité de développement,
• parfaite intégration dans l’entreprise,
• sécurité et scalabilité,
• et bien évidemment multiplateforme.

Côté manager, les besoins ne sont pas les mêmes :

• solution standard ? utilisée par d’autres projets ? Open Source ?,
• bien évidemment le coût de formation, entre une solution JavaScript et Java il n’y a pas qu’un pas ,
• outils associés à la solution (plugins, éditeur, WYSIWYG…),
• dépendante d’autres librairies / d’autres plugins ?,
• un background solide i.e. qui est derrière la solution ! Adobe, Google, un développeur dans son garage ? Mais aussi un support de qualité, des corrections de bugs et des mises à jour régulières.

Selon tous ces aspects, l’auteur nous donne 4 catégories de solutions RIA / frameworks :

• Snippet : amélioration légère avec quelques effets, des pages plus rapides à l’affichage, des nouvelles petites fonctions de ci de là… avec peu de changement au niveau de l’architecture ou du design. Script.aculo.us et Prototype sont de bons exemples,
• Widget : vous avez dit Web 2.0 ? C’est clairement ce que tout le monde a vu avec l’arrivée de librairies comme YUI ou ExtJS : une nouvelle expérience utilisateur au niveau de l’interface graphique avec des composants travaillés, très beaux, du drag & drop, de l’animation… ces frameworks s’appuient donc sur une libraire de widgets solides,
• Client : réécriture de l’application côté client dans une nouvelle technologie, nouvelle interface utilisateur, amélioration de la productivité mais un gros travail de refonte côté client. Nous parlons bien sûr des GWT, Flex et Cie,
• Full : la solution complète, riche, MVC, patterns de développement, à la fois une nouvelle expérience utilisateur mais aussi une réelle valeur ajoutée pour l’entreprise… mais nécessite des plateformes/technologies spécifiques côté client et serveur. On citera les ZK ou Wicket.

La conclusion sans surprise à la question (alors, laquelle ???) est bien sûr : ça dépend…
En effet :

• tous les projets n’ont pas la même cible d’utilisateur,
• et les technologies passent du Java au XML en passant par du JavaScript, autrement dit les compétences ne sont clairement pas les mêmes d’un framework à un autre.

Alors entre jQuery, ExtJS, GWT et Flex, ce sera à vous et vous seul de choisir !

Le coin de la technique

OpenXava 3.1 est disponible

OpenXava est un ensemble d’outils et de composants destinés à simplifier le développement d’applications Web Java.

OpenXava permet de générer des formulaires CRUD à partir des POJOs et des annotations JPA. Il vous propose également d’intégrer des fonctionnalités avancées : la génération des rapports PDF, exports Excel, formulaire de recherche, tri, impression… Avec OX, vous pouvez aussi créer des applications sophistiquées avec une logique complexe et des IHM avancées.

La nouvelle version 3.1 apporte AJAX dans vos applications générées. Pour ceux qui utilisent déjà OX le passage à la version 3.1 permet « d’ajaxifier » vos applications sans toucher une seule ligne de code.

Le projet est fourni sous licence LGPL.

Plusieurs démos sont disponibles.

Java Persistence API 2.0 Public Draft

La spécification JSR 317: JavaTM Persistence 2.0 est un public draft, comme l’annonce sur son blog la specification lead, Linda Demichiel (Sun Microsystems) : Java Persistence 2.0 Public Draft.

Une entrée précédente de la revue de de presse de Xebia : JPA 2.0, la nouvelle version d’une API bien portante, annonçait l’ajout de l’API Criteria à la version 2 de JPA.

Linda Demichiel décrit sur son blog le fonctionnement possible de cette API Criteria : Java Persistence 2.0 Public Draft: Criteria API.

Celle ci permet de construire des requêtes SQL en Java de manière programmatique. Cette technique présente les intérêts suivant :

• Les requêtes dynamiques sont plus faciles à construire et leurs constructions peuvent dépendre de données évaluées à l’exécution
• Les fonctions des IDE permettent d’assister le développeur comme par exemple le refactoring, la complétion

Cependant les requêtes sont plus difficiles

• A optimiser
• A maintenir (plus difficile à lire)

Ces requêtes sont construites à partir d’un object QueryDefinition obtenu à partir d’un EntityManager :

EntityManager em = ... ;
QueryBuilder queryBuilder = em.getQueryBuilder();

Exemple de création de requête sur l’entité Customer :

DomainObject customer = queryBuilder.createQueryDefinition(Customer.class);

En manipulant l’objet JPA DomainObject, on peut charger, par jointure, la relation customer->orders->items:

DomainObject item = customer.join("orders").join("items");

Voici un exemple complet :

DomainObject customer = queryBuilder.createQueryDefinition(Customer.class);
DomainObject item = customer.join("orders").join("items");
customer.where(item.get("productType").equal("printer"))
.select(customer.get("name"));

Comme le fait remarquer Gavin King dans l’article A typesafe criteria query API for JPA, il est dommage de manipuler des chaînes de caractères afin d’obtenir un attribut d’une classe. On perd un des intérêts de l’API Criteria : le refactoring et la complétion fournis par les IDE.

Ainsi, en reprenant l’exemple complet, si l’on renomme l’attribut name de la classe customer en firstName (avec notre IDE préféré), notre IDE sera incapable de changer le requête précédente de customer.get(« name ») à customer.get(« firstName »).

Actualité éditeurs / SSII

• Coopération entre SpringSource et Adobe
• tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Le coin de la technique

• Les orientations de GWT : Roadmap GWT 1.6
• Java 7, ce n’est pas pour tout de suite…
• Sortie de Grizzly 1.9
• Présentation de Google Guice 2.0

Actualité éditeurs / SSII

Coopération entre SpringSource et Adobe

SpringSource renforce son positionnement sur les RIA en signant un accord de partenariat avec Adobe Systems. Un partenariat dont l’objectif est de simplifier le développement et le déploiement des applications RIA se basant sur Adobe Flex et Spring.

Adobe et SpringSource se sont alliés pour travailler sur Spring BlazeDS Integration, un projet open source qui vise à simplifier l’intégration de Spring avec Adobe’s BlazeDS. Une version bêta est prévue dans une ou deux semaines.

SpringSource a prévu pour l’année prochaine un nouvel adaptateur pour Adobe LiveCycle Data Services ES, qui permet d’instaurer un moteur d’échanges de données entre les applications RIA basées sur Flex et Spring.

Ce rapprochement permet à SpringSource de renforcer son positionnement sur les RIA.

tc Server : SpringSource signe la première offre open source professionnelle sur Tomcat

Philip Hanik présente dans « SpringSource tc Server – The Tomcat you know. The enterprise capabilities you need. » le périmètre du nouvellement annoncé tc Server.

On y retrouve tous les ingrédients de la version commerciale d’un produit open source professionnel :

• Support : de l’entrée de gamme « heures ouvrées » à la formule « mission critique 24×365″ avec une réponse dans l’heure
• Packaging : livraison packagée avec les patchs nécessaires au client et des configurations et scripts de démarrage optimisés pour les différentes plateformes (32 vs 64 bits, etc).
• Indemnisation : en cas de problème juridique concernant la nature Open Source de Tomcat.
• Administration centralisée : ajout de mécanismes de gestion centralisée de serveurs Tomcat (configuration des serveurs, déploiement d’applications clusterisées [1] )
• Audit : suivi des opérations réalisées sur les serveurs.
• Monitoring et alertes : reprise des fonctionnalités de SpringAMS ( Hyperic HQ + extensions de monitoring de Spring Framework).
• Diagnostique : détection de thread lock, corrélation des erreurs avec les urls et les threads, mécanisme de First Failure Data Capture (FFDC).

Si les premiers points étaient déjà couverts par des offres de support commercial (e.g. SpringSource Enterprise Ready Server), c’est la première offre de type Open Core Licensing pour Tomcat (noyau open source + extensions commerciales orientées administration).
Les éditeurs incitaient jusqu’à présent leurs clients intéressés par un support Tomcat à faire un upsale sur serveur plus sophistiqué (JBoss App. Server, Websphere App. Server Community Edition, Spring dm Server, etc).

Quel intérêt de payer 500$/an/cpu pour tc Server plutôt que d’utiliser Tomcat ? Outre le support qui sera important pour de nombreux exploitants, les fonctionnalités d’exploitations et de supervision présentent un intérêt à prendre en compte.

Nous noterons pour conclure que l’ensemble des fonctionnalités annoncées ne sera pas disponible dès la version 1.0 de tc Server.

[1] tc Server permet notamment des opérations install/update/start/stop/uninstall/rollback phasées sur des clusters pour mettre à jour les noeuds les uns après les autres sans arrêt du service.

Le coin de la technique

Les orientations de GWT : Roadmap GWT 1.6

La version actuelle de GWT est la 1.5.3. L’équipe GWT a présenté sur son blog officiel les orientations de GWT 1.6 et des prochaines versions : What’s ahead for Google Web Toolkit.

Ainsi, on observe que l’équipe GWT s’attaque à différents points :

• Performance
• De compilation pour améliorer la productivité du cycle de développement
• D’exécution : optimisation de l’utilisation de la classe StringBuilder par exemple, des composants (cf LazyPanel plus bas)
• S’approcher des bonnes pratiques éprouvées dans la communauté Java : voici la spécification : Design Doc for 1.6 WAR structure. Ainsi, il sera possible de livrer les fichiers statiques (images, css) dans un répertoire hors de la WebApps. Actuellement tout est chargé via le classpath. Ces ressources statiques pourront être « akamai-llisées » et aussi relivrées indépendamment de la WebApp.
• Richesse des composants : intégration de nouveaux composants qui étaient dans l’incubateur de composants GWT
• Un calendrier : DatePicker
• Un Panel qui permet l’affichage du contenu d’un Panel lorsqu’on le souhaite afin d’améliorer les performances d’affichage : LazyPanel
• Migration de Tomcat à Jetty pour le Hosted Mode Server.

Cette version 1.6 est prévue pour le premier trimestre 2009.

Ils parlent aussi de la Roadmap GWT :

• Marwan KHELIF avec GWT 1.6 : quoi de neuf ?
• Thomas Recloux avec Roadmap GWT 1.6
• A voir aussi sur le site officiel de GWT Making Gwt Better

Java 7, ce n’est pas pour tout de suite…

Initialement prévu pour début 2009, nous n’avons toujours pas (peu) eu de détails officiels concernant celui-ci. Vous vous en doutiez, Java 7 ne sortira pas demain. Suite à une des conférences de Devoxx, nous en savons désormais un peu plus sur ce sujet : sa sortie décalée à début 2010.

Est-ce si lointain ? Pas vraiment, à la vue de tous les différents qui tournent autour du Jdk 7 (modularité, closures …), il ne sera probablement pas trop d’une année pour résoudre tous ces sujets de discordes. Pour y arriver, des choix rapides et judicieux devront être pris, cette même conférence en a d’ailleurs laissé sous-entendre quelques-uns, en voici les grandes lignes.

• Modularité : point central de Java7, après la mort programmée de la JSR-277, la réconciliation avec OSGi devra sans doute passer par la JSR-294 (sous-jacente) – les superpackages. Si quelques changements récents offrent des perspectives de réconciliation, l’aventure ne fait que commencer pour le sujet le plus sensible du Jdk 7. Le nouveau projet Jigsaw qui doit permettre de partager à la communauté l’avancement des travaux est déjà fortement controversé.
• Les closures : la grande blague ; le jdk7 ne proposera finalement pas cette fonctionnalité. Aucun consensus n’ayant été trouvé à ce sujet par la communauté : celles-ci sont pour le moment déscopées.
• Les nouvelles API : aucun scoop à ce sujet. Nous en connaissions déjà les principales : nio2 (JSR-203) et JodaTime (JSR-310).
• Évolutions du langage : C’est Joseph D. Darcy qui sera chargé de définir et regrouper les petites évolutions du langage pour le Jdk 7. Pour cette future nouvelle JSR (sa 3e après JSR-13 et JSR-269), il a prévu d’impliquer d’avantage la communauté pour ce point facilement sujet à controverse. Son idée est de proposer et demander les retours de la communauté en amont du processus pour éviter toute controverse. Avant même que la JSR ne soit proposée en draft, les grandes lignes de celles-ci devraient en être définies, disponibles et discutées sur un projet spécifique de l’open JDK. Cette JSR est prévue pour sortir au cours du premier semestre 2009.

À ce propos, vous vous demandez peut-être comment va-t-il s’y prendre pour intégrer ces changements ? C’est peut-être également l’occasion de revenir sur un de ces anciens articles présentant les différentes étapes à suivre pour ajouter des fonctionnalités dans le jdk .

Sortie de Grizzly 1.9

Grizzly 1.9 est sorti, à noter que la version 2.0 est prévue pour la fin de l’année. Grizzly est un framework Sun pour aider les développeurs à construire des serveurs robustes et scalables en utilisant l’API Java NIO (et NIO 2). Il met aussi à disposition le support de différents protocoles :

• Glassfish utilise Grizzly comme HTTP Listener.

  Les nouveautés de cette version sont :

  • Support des I/O asynchrones (NIO2, Xebia en avait parlé), cela permet d’améliorer grandement les performances
  • Support des HTTP write asynchrones
  • GrizzlyAdapterChain supporte maintenant plusieurs adapteurs et peut transformer les requêtes d’entrées à la volée
  • Le framework Comet a amélioré ses performances. À voir aussi un exemple d’implémentation utilisant GrizzlyComet : Writing a Twitter like application using Grizzly Comet part 1: The Servlet.

  Présentation de Google Guice 2.0

  La sortie Guice 2.0 est attendue pour décembre 2008 donc très prochainement.

  À l’image de Spring, Guice est un framework d’injection de dépendances. Cependant, Guice se démarque de Spring dans la mesure où Guice fonctionne sans aucun XML. La configuration et le tissage des dépendances se font de manière programmatique. Il utilise les annotations du langage Java 5.

  Guice se veut être un framework léger et facile à intégrer. Il existe d’ailleurs un plugin Struts pour gérer l’injection de dépendances en Guice.

  L’article Dependency injection with Guice de Nicholas Lesoecki, employé à Google, présente le fonctionnement de Guice.

  Voici le fonctionnement du Guice d’un point de vue programmatique :

  @Inject
  public FrogMan(Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Le tissage s’effectue aussi de manière programmatique, ce qui le différencie radicalement de Spring :

  public class HeroModule implements Module {
    public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
    }
  }
  

  Le tissage est donc réalisé dans un Module.

  Ensuite le contexte Guice se démarre comme suit :

  public class Adventure {
    public static void main(String[] args){
      Injector injector = Guice.createInjector(new HeroModule());
      FrogMan hero = injector.getInstance(FrogMan.class);
      hero.fightCrime();
    }
  }
  

  Il est possible d’injecter une dépendance par :

  • Constructeur, c’est la méthode la plus simple, par forcément la plus élégante en Spring
  • Méthode
  • Attribut de classe

  Cependant, un problème peut se poser par rapport à l’exemple précédent : comment injecter plusieurs véhicules ? Solution : il faut nommer les cibles en créant ses propres annotations pour l’injection :

  @Inject
  public WeaselGirl(@Fast Vehicle vehicle) {
    this.vehicle = vehicle;
  }
  

  Code source du tissage :

  public class HeroModule implements Module {
   public void configure(Binder binder) {
      binder.bind(Vehicle.class).to(FrogMobile.class);
      binder.bind(Vehicle.class).annotatedWith(Fast.class).to(WeaselCopter.class);
    }
  }
  

  Code source de la déclaration de l’annotation :

  @Retention(RetentionPolicy.RUNTIME)
  @Target({ElementType.FIELD, ElementType.PARAMETER})
  @BindingAnnotation
  public @interface Fast {}
  

  Les nouveautés de cette version sont présentées sur le site officiel : Changes in Guice 2. On y trouve entre autre :

  • Implémentation de l’AOP
  • Surcharge du binding d’un module à un autre
  • Binding des éléments d’un tableau Set ({{Multibinding}}) ou Map ({{Mapbinding}})
  • Convertisseur de type branchable, par exemple, pour convertir une chaîne de caractères en date

  Même si Guice est loin d’avoir la maturité de Spring ou même autant de fonctionnalités que ce dernier, il propose une approche de l’injection de dépendances très pragmatique.

  Une étude sur la comparaison des versions Guice 1.0 et Spring 2.0.2 (Guice vs. Spring JavaConfig: A comparison of DI styles) arrive aux conclusions suivantes :

  • Performance : Guice est plus rapide, mais est-ce vraiment important car généralement les dépendances sont chargées au démarrage de l’application ?
  • Modèle de programmation Guice plus intrusif : il est dommage de devoir mettre un @inject dans les objets Guice qui peuvent être injectés
  • Spring AOP est plus puissante
  • Guice est plus facile à intégrer (il y a seulement 2 Jars à intégrer)

  À voir également : deux liens intéressants sur l’injection de dépendance issus de la documentation de PicoContainer, autre implémentation pour l’injection de dépendance :

  • Design patterns, règles a avoir en tête lorsque l’on fait de l’injection de dépendance
  • Inversion of Control history, tout sur l’injection de dépendance
  ]]> http://blog.xebia.fr/2008/12/15/revue-de-presse-xebia-87/feed/ 4 http://blog.xebia.fr/2008/11/17/revue-de-presse-xebia-83/ http://blog.xebia.fr/2008/11/17/revue-de-presse-xebia-83/#comments Mon, 17 Nov 2008 18:04:04 +0000 Xebia France http://blog.xebia.fr/?p=997
  La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

  Actualité éditeurs / SSII

  • Sun supprime 5.000 à 6.000 emplois dans la continuité de sa mutation en un acteur Open Source
  • SpringSource dévoile sa roadmap

  RIA

  • Le framework préféré des développeurs Flex
  • Adobe lance Cocomo

  Le coin de la technique

  • Essayez le nouvel algorithme Garbage First
  • Gestion des documents Office 2007
  • Hyperic v4.0 : le monitoring d’applications Java passe par JMX
  • Sortie de Grails 1.0.4

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

  • Open Source eXchange : comptes-rendus des participants
  • L’Aquarium à Paris le 12 décembre : inscriptions ouvertes

  Actualité éditeurs / SSII

  Sun supprime 5.000 à 6.000 emplois dans la continuité de sa mutation en un acteur Open Source

  Sun annonce un plan de restructuration assez conséquent puisqu’il touchera plus de 15% de ses effectifs.

  Triste nouvelle. La nécessaire mutation de ce fleuron de l’informatique des années 90, tiraillé entre son activité hardware en déclin (traditionnellement haut de gamme, mais malheureusement à contre-courant d’investissements en berne en période de crise) et son activité software (en recherche d’un second souffle – le patron de la branche logicielle, Steve Green est parti Vendredi dernier), est en marche depuis plusieurs années et n’est pas une surprise.

  L’annonce faite sur le site Corporate de Sun est claire : Software et Open Source !
  Espérons pour Sun que les récentes (pour certaines judicieuses) et coûteuses acquisitions porteront leurs fruits.

  Si nous osions, nous dirions que, toute activité hardware mise à part, Sun ressemble de plus en plus à des pures players de l’Open Source au même titre que Redhat par exemple.

  Il n’est en effet pas surprenant que Sun ait choisi cette voie. Lors de la conférence de Malaga des partenaires de Redhat, à laquelle Xebia était invitée, James Whitehust nous époustouflait en nous annonçant que sa marge et sa croissance étaient parmi les plus élevées de l’industrie logicielle (information vérifiée et qui s’avère exacte).

  Bonne continuation à Sun dans cette voie, elle est légitime. Et bonne chance avec la prometteuse gamme Sun Storage 7000, un condensé de hardware, d’open source et d’innovation dans le lignée du nouveau modèle Sun !

  SpringSource dévoile sa roadmap

  Vous avez probablement entendu parler des rencontres Spring qui se sont déroulées jeudi dernier. Nous ne résumerons pas ici le contenu de l’ensemble des conférences, d’autres blogs s’en sont déjà chargés avec brio (cf liens annexes). Si, dans l’ensemble, les conférences étaient plutôt réussies, nous avouons être un peu restés sur notre faim :

  • Les discussions ont beaucoup tourné autour du rachat par SpringSource de G2One sans pour autant révéler clairement la place de Groovy et Grails dans la stack Spring. Elles ont tout de même permis de servir de point de départ à des discussions off bien plus intéressantes lors de la pause.
  • Aucune explication sur les (petits) retards de la M1 de Spring 3.0, aucune référence à Spring JavaConfig ni à l’intégration des Servlet 3.0, pas de communication sur le contenu des M2 et M3, bref, rien de neuf depuis le billet que nous avons publié le mois dernier sur Spring 3.0.

  Heureusement donc que ce rachat, annoncé en début de semaine, et la présence de speakers d’exceptions ont permis de pimenter cette demi-journée.

  La partie la plus intéressante a été probablement celle de Peter Cooper Ellis nous présentant de la roadmap Spring dont voici les points à retenir :

  • Concernant Spring 3.0 : le premier milestone doit sortir d’ici fin novembre. Il sera probablement suivi d’un M2 et d’un M3 avant l’arrivée d’une Release Candidate prévue en mars 2009. La sortie officielle devrait arriver en avril si tout se passe bien.
  • Sortie de Spring Integration d’ici la fin de l’année.
  • La version 1.2 de Spring DM devrait sortir durant le premier trimestre 2009 offrant le support au Configuration Admin service. Elle sera suivie peu de temps après par la version 2.0 qui implémentera l’OSGi Blueprint Service (RFC 124) partie d’OSGi R4.2. Spring DM 2.0 sera d’ailleurs probablement la reference implementation de ces spécifications. Sa date de sortie est prévue pour le second trimestre 2009.
  • En parallèle à cela, deux nouvelles versions de Spring dmServer sont planifiées l’année prochaine. La première, dmServer Jersey, offrira, entre autres, une compatibilité Tomcat. Cette version devrait voir le jour au second trimestre 2009. L’autre version est prévue pour fin 2009 : dmServer Ockney. En voici quelques nouveautés : load balancer dynamique, enregistrement et exécution de scripts sur la console …
  • Notons également au premier trimestre 2009 : une mise à jour de Spring IDE (2.5) et les versions 1.6 de Groovy et 1.1 de Grails, dont Guillaume Laforge vente les mérites depuis la soirée Groovy du Paris JUG.
  • Mais c’est le second trimestre qui sera le plus chargé avec au programme : Spring Batch 2.0, Spring Security 2.5, Spring ROO et Spring Web. La version 2.0 de Spring Batch apportera une mise à jour importante de ce framework : passage à Java 5, configuration via annotations, on parle également d’une éventuelle intégration avec la stack apportée par G2One. Vous aurez également remarqué la présence d’un nouveau framework baptisé Spring ROO. Il s’agirait d’un framework RAD / DDD de génération de codes privilégiant les conventions à la configuration (tiens, tiens, ça nous rappelle quelque chose). Ici encore, aucune information n’est donnée quant à la place de ce framework vis-à-vis de Grails.
  

  Notez que ce planning ne se veut ni complet ni définitif, certaines de ces dates seront très probablement amenées à évoluer.

  Liens connexes :

  • Consultez l’agenda de la demi-journée.
  • Téléchargez-les slides des conférences.
  • Remerciements post-conférences par Julien Dubois.
  • Résumé de la demi-journée par Pierre Mage.
  • Résumé de la demi-journée par Olivier Mallassi.
  • Résumé de la demi-journée par Nicolas Martignole.
  • Autres billets : Spring dmServer, le pari fou ?, Tuning Tomcat par Thomas Queste.

  RIA

  Le framework préféré des développeurs Flex

  Rich Tetrola a lancé la semaine dernière un sondage sur le framework préféré des développeurs Flex. Et voici le résultat. PureMVC remporte le sondage à la surprise de l’auteur lui-même qui misait plutôt sur Cairngorm. Les candidats au titre de framework préféré des développeurs Flex étaient :

  • Cairngorm : une micro architecture fournissant plusieurs motifs de conception (notamment le Modèle-Vue-Contrôleur).
  • PureMVC : un framework permettant de concevoir des applications basées sur le motif de conception Modèle-Vue-Contrôleur.
  • Mate : un framework qui gère les évènements dont voici une démonstration Hello World.
  • Swiz : un framework facilitant le développement d’applications riches.
  • EasyMVC : il permet également de concevoir des applications sur le motif de conception Modèle-Vue-Contrôleur.
  • Ruboss : il facilite le développement d’application Flex/Rails.

  Cairngorm, bien qu’il soit un produit d’Adobe Labs, n’a pas remporté le succès attendu à cause de sa complexité, c’est ce qui ressort des commentaires. Peut être est ce à cause de son « ModelLocator fourre tout ». Les résultats sont intéressants mais il ne faut pas les prendre au pied de la lettre. Tous ces frameworks ont pour but de mettre en place de bonnes pratiques dans le développement d’applications riches. Chacun dispose d’avantages et d’inconvénients à bien évaluer lorsqu’on veut choisir d’utiliser l’un de ces frameworks.

  Adobe lance Cocomo

  Avec cette première version bêta dans les labs, Adobe étoffe encore son offre RIA.
  Cocomo est une plateforme Flex permettant au développeur d’ajouter des capacités « sociales » aux applications RIA. Cocomo mêle une partie cliente Flex et les infrastructures réseau mises à disposition par Adobe. En bref, il permet de facilement mettre en place des outils collaboratifs dans vos applications Flex. La version bêta propose déjà le support de :

  • Conférences audio (par VoIP).
  • Conférences vidéo (par Webcam).
  • Chat texte.
  • Echange de fichiers.
  • Gestion des utilisateurs.
  • Et d’autres choses à découvrir.

  Pour plus d’informations rendez vous sur le site d’Adobe : Présentation de Cocomo.

  Le coin de la technique

  Essayez le nouvel algorithme Garbage First

  Danny Coward, dont nous avons déjà parlé à plusieurs reprises, a publié cette semaine sur son blog un billet annonçant la disponibilité du nouvel algorithme pour le ramasse-miettes Java sur le dernier build du JDK 7 (bon courage pour l’installer …). Trois saisons ont passé depuis la publication sur notre blog d’un article présentant le fonctionnement de celui-ci. Son principe n’a pas changé, vous pouvez donc toujours vous y référer si le sujet vous intéresse : GC générationnels traditionnels (JDK 6) VS Garbage First (JDK 7).

  À retenir sur ce nouvel algorithme, Garbage First (G1) :

  • Il est destiné à remplacer le parrallel and concurrent mark and sweep.
  • Il devrait être activé par défaut dès le JDK 7.
  • Il propose un nouveau découpage du tas : la taille des zones mémoire se réduit, plus de zones sont créées en contrepartie.
  • Il permet également d’exploiter les forces des architectures multicœurs.
  • Il se veut plus prédictible et moins intrusif en offrant par exemple des garanties sur des temps de pauses.
  • Il permet en moyenne d’obtenir un meilleur débit de nettoyage, tout en offrant une implémentation simple à comprendre.

  Gestion des documents Office 2007

  La société Aspose annonce la sortie d’une nouvelle version de son produit Aspose.Word permettant de gérer nos fichiers Word 2007, les fameux .docx de Microsoft Office 2007 (annonce relayée par The Server Side).

  Cette 2.6.0 ajoute l’importante fonctionnalité de pouvoir charger un fichier Word existant, rendant possible l’édition de celui-ci. Un produit très complet donc, qui gère aussi les images, les zones de texte, les objets OLE et Active X et bien d’autres fonctionnalités de Microsoft Word.

  A noter que la gestion des fichiers Excel 2007 (.xlsx) et PowerPoint 2007 (.pptx) est en très bonne voie chez Apache POI, le support du format OOXML étant déjà disponible dans POI en version 3.5 beta 3. Ce support est désormais une priorité pour le projet. Rappelons que depuis quelques mois Microsoft est partenaire du projet Apache POI et contribue ainsi à l’intégration de son format dans POI.

  Hyperic v4.0 : le monitoring d’applications Java passe par JMX

  Hyperic HQ, l’outil de supervision choisi par Iona (Fuse HQ), Redhat (JBoss Operations Network) et SpringSource (Application Management Suite), dévoile cette semaine sa version 4.0 dont une des nouveautés clefs est le nouveau JMX MBean Browser.

  Nous retiendrons de cette annonce que JMX est la technologie incontournable pour superviser des applications Java. Le développement d’indicateurs en MBean JMX est aujourd’hui très facile pour les équipes applicatives avec des frameworks comme Spring JMX et la consultation de ces informations est banalisée avec l’incontournable Visual VM (cf Blog Xebia : Diagnostique d’une JVM à distance).

  Ne pas s’intégrer facilement à JMX est aujourd’hui un très sévère handicap pour une solution de supervision d’applications Java.

  Sortie de Grails 1.0.4

  La sortie officielle de Grails 1.0.4 vient d’être annoncée par SpringSource. Pour ceux qui ne le connaissent pas, Grails est un framework orienté web écrit en Java et Groovy et placé sous licence Apache. Il s’inspire fortement du framework Rails (Ruby on Rails). Mais contrairement à Rails, Grails est ancré complètement dans l’univers Java, et repose sur des frameworks très connus comme Spring ou Hibernate.

  Cette nouvelle version propose des nouvelles fonctionnalités pour une meilleure intégration avec Spring et Hibernate, un support des tags JSP dans GSP, de nouveaux plugins pour Java Content Repository (JCR API), Java Persistence API (JPA) et l’api Portlet.

  L’année prochaine s’annonce très prometteuse, avec la possibilité d’intégration de Groovy avec Grails et des produits du portefeuille Spring comme Spring Batch, Spring Integration, et Spring dm Server.

  Autres liens :

  • Le site officiel de Grails.
  • La documentation officielle : http://grails.org/doc/1.0.4.

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

  Open Source eXchange : comptes-rendus des participants

  Si vous n’avez pas pu assister à la journée OpenSource Exchange organisée conjointement par Skills Matter et Xebia de la semaine dernière, nous vous proposons ici en rattrapage quelques-uns des retours effectués par les participants à cette journée.

  • Éric Lefevre met à disposition sur son blog un compte rendu synthétisant l’ensemble de la journée.
  • Olivier Croisier a quant à lui effectué une série d’articles fort intéressante sur chacune des conférences :
  • Compte rendu SpringSource dmServer, dont la conférence était présentée par Michael Isvy.
  • Compte rendu eXo Platform, dont la conférence était présentée par Tugdal Grall.
  • Compte rendu Java EE 6, dont la conférence était présentée par Antonio Goncalves.
  • Compte rendu Groovy, dont la conférence était présentée par Guillaume Laforge.
  • Compte rendu Glassfish v3, dont la conférence était présentée par Alexis Moussine-Pouchkine.
  • Compte rendu Portlet 2.0, dont la conférence était présentée par Christophe Laprun.
  • Compte rendu Hadoop, dont la conférence était présentée par Hugues Le Bars.

  Nous profitons de cette revue de presse pour les remercier.

  Vous pouvez également nous proposer d’autres comptes-rendus si vous le désirez.

  L’Aquarium à Paris le 12 décembre : inscriptions ouvertes

  Nous en parlions la semaine dernière, Sun organise le vendredi 12 décembre une journée gratuite « GlassFish et Java » dans ses locaux au 42, avenue d’Iéna à Paris.
  Cette journée a été baptisée « L’Aquarium à Paris » et sera l’occasion de couvrir un large spectre de la gamme Sun :

  • GlassFish,
  • Java EE 6,
  • Grizzly Comet,
  • Jersey,
  • OpenMQ,
  • JavaFX,
  • MySQL,
  • OpenSSO,
  • OpenESB.

  Parmi les intervenants: Roberto Chinnici (spec lead), Richard Bair (tech lead), Paul Sandoz (spec lead), Linda Schneider (tech lead), Jean-François Arcand (tech lead), etc…

  Les inscriptions sont désormais ouvertes.

  ]]> http://blog.xebia.fr/2008/11/17/revue-de-presse-xebia-83/feed/ 1