Revue de Presse Xebia

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

Agilité

RIA

Le coin de la technique

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 :

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

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.

Billets sur le même thème :

11 commentaires

  • « on peut [...] s’étonner de l’absence de Spring Source 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 ? »

    Plusieurs points peuvent etre leves:

    SpringSource:
    SpringSource n’a jamais demande a faire partie du groupe d’expertise malheureusement. Ils etaient au courant de Web Beans relativement tot dans le cycle de vie de la specification. Je ne sais pas pourquoi ils ne l’ont pas fait. Demande leur. D’experience, je peux dire que prendre le lead d’une JSR (specialement importante) demande de l’experience ; je souhaiterai voir SpringSource contribuer activement a quelques JSRs avant de se lancer dans un lead. C’est un travail dantesque. C’est un avis personnel. J’aurai aussi aimer les voir contribuer a 299 (et d’autres).

    Legitimite:
    Le seul critere qui te permets d’etre le leader legitime d’une JSR est de t’assoir, de prendre le temps d’ecrire la spec et de faire contribuer les personnes interessees a construire la spec.
    JBoss (Gavin, Bill et moi) avons passe un temps enorme sur EJB 3.0 (qui a donne JPA 1.0). A noter, JBoss n’est pas le spec lead de JPA 1.0 ou 2.0. Ca n’empeche pas de contribuer et d’influencer fortement une spec.
    De meme JBoss a passe un temps enorme a construire JSR 299, a faire travailler ensemble JBoss, Sun, Google, Oracle individuels et meme IBM :)
    J’ai du mal a voir pourquoi il faudrait refuser a la communaute Java cette spec, recommencer a zero et perdre deux ans ou plus.

    Risques de ratage:
    La spec a inclus l’expertise conjointe de beaucoup de monde (JBoss, Google – Bob Lee, Apache, Oracle, Sun et beaucoup d’autres) et de produits (bien sur EJB 3, Seam, Guice, etc) sur un chantier qui a dure deux ans et demi.
    Ma conviction personnelle est que cette spec est meilleure que chaque produit individuel (Spring, Seam, Guice).

    Emmanuel Bernard
    JBoss

  • Spring fait du REST, mais sans JAX-RS :(
    Jusqu’à présent les justifications entendues sont décevantes.

    Pour (ex-)WebBeans, je suis pas l’expert, mais on notera que les EJB 3.0 se sont faits sans Rod…

  • Sur Ivy, on peut lire par ex:
    http://fanf42.blogspot.com/2009/01/ivy-20-released.html

    Ivy seems to be loved by new « build system » make. Gradle, the Groovy buildr, is based on Ivy.
    I will also signal the on-going work around an « maven-style build system with a stack of convention » build on top of Ivy and Ant, easy-ant (and there is an irc chan on freenode: #easyant). The project is work-in-progress, but a lot has already been done, and I believe it will be a great solution for all of us that are pissed-off by Maven, or just can’t move from Ant but want to normalized (or « base on conventions ») their build scripts, and integrate Ivy.

    Note 2: I’m neither implied in easy-ant dev ;)

    So, it seems that Maven is not the final winner in Java build system land, and that’s good (no monopole, concurrency for the best…) !

    ***

    Deuxio, il faut lire aussi le blog de Henin, en général. Il écrit peu mais il a la tête sur les épaules.

  • Bonjour Emmanuel,

    J’ai l’impression que le l’absence de contribution de SpringSource à JSR 299 est intimement liée au fait que, de Mai 2006 à début 2009, cette spécification se nommait « Web Beans » et était présentée comme un liant entre JSF et EJB3. On ne refait pas l’histoire mais j’imagine que des projets comme Spring Framework ou Picocontainer auraient rejoint la JSR 299 dès sa création en 2006 si elle s’était d’emblée appelée « Contexts and Dependency Injection for Java ».

    Concernant la légitimité et la représentativité des membres de l’Expert Group, la notoriété de JBoss et Google respectivement pour de Seam/EJB3 et Guice sont des facteurs de succès. Cependant, l’absence de SpringSource me semble être très dommage. Comme vous le remarquez, JBoss/Hibernate a fortement contribué à JPA et sa participation peut être vue comme un élément clef de succès. Je doute que JPA aurait été un tel succès si cette spécification n’avait été menée que par Oracle (Toplink) et BEA (Kodo) en oubliant les idées de JBoss/Hibernate. J’ai un doute du même ordre quand à « Dependency Injection » sans SpringSource même si JBoss et Google participent.

    Enfin, pour le risque de ratage, une JSR qui se transforme radicalement, au point de changer de nom, pendant la phase de Public Review, après deux années et demies de travail intensif, cela me parait exceptionnel et peu rassurant.

    J’espère que, comme vous le pensez, JSR 299 est supérieur à Spring, Seam, Guice et Pico. J’espère aussi que chacune de ces communautés se retrouvera dans JSR 299 – Dependency Injection. Sans quoi, au lieu de fédérer, nous risquons de fragmenter un peu plus et de nuire à l’émergence du standard EJB.

    Cyrille (Xebia)

  • Bonjour Alexis,

    Je fais le même constat que vous.

    JPA s’est fait avec JBoss Hibernate et ce standard a succédé naturellement aux frameworks propriétaires (Hibernate, topLink, Kodo, etc).

    EJB 3 s’est fait sans SpringSource et aujourd’hui la fragmentation sur le sujet persiste. Spring Framework reste extrêmement présent voire majoritaire sur le domaine et l’épisode JSR 299 montre qu’il y a encore beaucoup à faire pour proposer un standard en alternative à Spring, Seam, Guice et autres Pico container ;-) .

    Cyrille (Xebia)

  • Cyrille, la JSR 299 ne se transforme pas radicalement, je dirais plutôt qu’elle réduit sa voilure et se concentre sur bon but initial : un contexte unifié entre les EJBs et JSF.

    Mais il est vrai que ce remaniement va apporter un peu de retard à Java EE 6. Les experts vont devoir relire la JSR 299 de long en large et en travers, discuter, et voter son entrée dans Java EE 6 ou non. Idem pour la JSR 303 (Bean Validation).

    Même si Java EE 6 sera l’attraction numéro 1 à JavaOne, il y a très peu de chance pour que toutes les spec soient publiques et les implémentations de références prêtes à l’emploi début juin. Il y a de fortes chances que la sortie de Java EE 6 prenne qques mois de retard.

  • Cyrille,
    Je pense qu’Emmanuel a été clair – difficile de reprocher à Sun, JBoss ou au JCP l’absence de SpringSource dans ce JSR.
    -Alexis, résolument optimiste sur JSR 299 et Java EE 6

    PS: toujours pas de notification pour les réponses au blogs? Dommage.

  • Bonjour Alexis,

    je viens d’installer le plugin « Subscribe to Comments » qui permet d’être notifié lorsqu’une réponse à un article a été envoyée.

  • Bonjour Alexis,

    Loin de moi l’idée de reprocher quoi que ce soit aux Expert Group des JSR et encore moins au JCP. Au contraire, je salue le travail de clarification de la JSR 299 qu’ont apportés les membres du Java EE 6 Expert Group (cf Gavin King Revised Public Draft of JSR-299: Java Contexts and Dependency Injection).

    Mes points sur JSR 299 restent :
    – Un revirement si tardif allant jusqu’au titre d’une JSR est inhabituel et n’est pas un signe de sérénité.
    – On ne refait pas l’histoire mais, si JSR 299 s’était initialement appelée « Dependency Injection », des acteurs clefs du sujet tels que Spring Source et Pico container auraient probablement rejoint l’Expert Group.

    A titre de comparaison, le succès de la standardisation JPA est souvent associée à la participation de JBoss/Hibernate à l’Expert Group … même si le rôle d’Oracle (Toplink) et BEA (Kodo) a sûrement été important.

    Cyrille (Xebia)

  • Salut Cyrille,
    Franchement, ton impression est fausse. Mettons que le titre Web Beans ait trompe certains mai 2006. L’early draft d’octobre 2007 contenait a peu pres toutes les grandes fonctionalites de Web Beans et specialement son coeur context et DI. Ce draft a fait assez de bruit a l’epoque (dans et au dehors du JCP), pour tout le petit monde du middleware soit au courant. SpringSource etait au courant.

    Web Bean n’a pas oublie les bonnes idees de Spring, Pico et les autres DI containers. Mais je suis d’accord avec toi, l’expertise de quelqu’un comme Juergen Hoeller aurait ete apreciee.

    Le renommage et les changements dans la JSR ces quelques derniers mois sont plus du a une meilleure integration dans EE (notamment bouger certaines fonctionalites definies dans 299 vers d’autres specs comme EJB 3.1), pas specialement changer le coeur de la spec.

    Emmanuel Bernard
    JBoss

  • JPA est né dans la douleur (c’est peu dire) et dans un JSR qui n’était même pas le sien propre!
    C’était *beaucoup* moins serein que ce qui se passe sur le jsr299.
    (merci pour le plugin de notification, ca sera bientôt TheServerSide ici :-)

Laisser un commentaire