Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Kenaï, fermera, fermera pas ?

Le coin de la technique

• Groovy++: bientôt dans votre JVM ?
• InfoQ sort un ebook gratuit sur Grails
• Maven vers une injection de dépendances via Guice

Actualité éditeurs / SSII

Kenaï, fermera, fermera pas ?

Comme il fallait le prévoir au vu de l’engouement d’Oracle pour les projets communautaires, la ferme de projets Kenaï vit ses derniers jours en tant que service public. La plateforme lancée en 2008 et construite autour de JRuby, Glassfish et MySQL fournissait un environnement de suivi de projet complet avec la gestion de version, des wikis, des mailing lists et que sais-je encore. Avec NetBeans 6.7, il est même possible de maintenir entièrement son projet depuis son IDE. Le site héberge encore aujourd’hui quelques 40 000 projets communautaires parmi lesquels on retiendra JRuby et Hudson. Oracle a d’abord annoncé la fermeture du site sous 60 jours afin de permettre aux projets de migrer vers d’autres solutions. L’idée de départ devait être de ré-utiliser la plateforme en interne mais plus du tout ouverte au public.
Faut il y voir les effets de la réaction d’une communauté importante ou un gros problème de communication : Oracle change son fusil d’épaule à travers la voix de Ted Farrell qui a clarifié l’avenir de la plateforme en annonçant que ce serait finalement une migration vers java.net. Dans son annonce, Farrell laisse entendre que tous les efforts seront poussés sur java.net et que la communauté Kenaï pourrait continuer à travailler sans perte sur la nouvelle version de cette ancienne plateforme de développement hosté.
Comme le dit la chanson, trois pas en avant, trois pas en arrière, …

• Kenaï to close sur InfoQ
• Le post de Ted Farrell

Le coin de la technique

Groovy++: bientôt dans votre JVM ?

Nous avons éhontément passé sous silence nombre de news du monde Groovy récemment:

• Groovy 1.7
• Grails 1.2
• La sortie du plugin Groovy Eclipse en version 2.0
• La sortie de nouvelles versions de Griffon, le framework pour clients lourds qui reprend les idées de Grails

Alors pour nous rattraper, nous ne passerons pas à coté de la nouvelle suivante : le développement de Groovy++ ! Alex Tkachman, l’initiateur du projet nous explique dans une interview de quoi il retourne et Roshan Dawrani nous explique ce qu’il retient du projet. En fait, malgré tous ses avantages, Groovy est encore assez lent. En tout cas beaucoup plus que Java, à cause de son coté dynamique. L’idée de Groovy++ est de continuer à utiliser Groovy normalement, mais en pluggant un compilateur spécial pour certaines parties du code annotées avec @Typed. Le code ainsi annoté devra respecter de légères contraintes (contraintes par rapport au laxisme de Groovy, mais légères par rapport au typage fort de Java). Le compilateur pourra donc effectuer des optimisations, notamment grâce à l’inférence de type, et nettement améliorer les performances. Les premiers résultats semblent encourageant en tout cas : 197 fois plus rapide d’après ce micro-bench et 33% plus rapide d’après cet article lu sur le Touilleur Express.

Alors ce Groovy++, une révolution ? Difficile à dire ! En effet, d’un coté Groovy est de plus en plus utilisé (notamment à travers Grails) et un coup de boost ne peut pas lui faire de mal. Mais d’un autre coté, l’interaction de Groovy et Java étant très avancée, on peut se contenter d’écrire en Java les parties du programme nécessitant des performances optimales. On peut aussi voir en Groovy++ l’ajout d’une énième librairie dans le développement, avec ses contraintes, ses bugs… D’autant que, pour des problèmes de licence sur certaines parties de code, le compilateur n’est pas encore OpenSource (ce qui est prévu pour la suite). Donc, si vous sous sentez l’âme d’un aventurier ou que vous avez désespérément besoin de gains de performances tout en gardant la « Groovy attitude », n’hésitez pas à nous faire vos retours sur l’utilisation de Grovvy++ !

InfoQ sort un ebook gratuit sur Grails

InfoQ vient de sortir, dans sa série « Minibooks » la seconde version de son « Getting started with Grails ». La première version, datant d’il y a déjà 3 ans, était basée sur Grails 0.3.1 alors que celle-ci s’appuie sur le tout récent 1.2. Le principe reste identique : les auteurs s’appuient sur une application de gestion de course de chevaux pour nous faire découvrir au fur et à mesure nombre des possibilités offertes par le framework. A la vue du sommaire, largement remanié, on peut penser que les changements ont été profonds. Sans avoir encore lu cette seconde édition, nous pouvons d’ores et déjà la recommander chaudement à toute personne qui s’intéresse à Grails et voudrait rapidement avoir un éventail clair des possibilités qu’il offre (si elle est dans la même veine que la précédente). D’autant qu’au format électronique, le livre est gratuit (juste besoin de s’inscrire à InfoQ)!

Maven vers une injection de dépendances via Guice

Sonatype (via InfoQ) a annoncé la migration progressive de Maven vers une injection de dépendances gérée par Google Guice. Ce qui signifie l’abandon à moyen terme de Plexus, le framework quelque peu obsolète (et abscons, faute de documentation) utilisé depuis les débuts du framework de build. Dans un premier temps, la migration sera gérée via un bridge créé sous Guice.
De plus, l’introduction de Guice devrait se faire via les annotations de la JSR 330, ce qui rendra Maven moins adhérent à Guice dans le cas d’une nouvelle migration vers un autre framework d’IoC.
Cette nouvelle devrait réjouir les développeurs de plugins, qui n’auront plus à maitriser les arcanes de Plexus. Autre conséquence, plus directe, les développeurs Maven n’auront plus à jouer les comitters Plexus pour débugger et ou faire avancer cet outil (qui devrait rapidement se diriger vers une fin de vie en l’absence de ce soutien de poids).
On peut noter que Jason van Zyl, le créateur de Maven, et Bob Lee, l’un des principaux artisans de Guice, avaient œuvré ensemble à imposer la JSR 330 face à la JSR 299 (la fameuse bataille @Inject contre WebBeans).