Revue de Presse Xebia

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

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 :

• Comet » >Comet, qui permet à un serveur de pousser des informations au client.
• Bayeux Protocol, qui permet une communication continue et bilatérale entre un serveur et un client
• Servlet (support partiel)

Il est aussi possible de développer un client serveur sur HTTP plus classique (sans push de donnée serveur). Cependant, ce n’est plus la vocation première du framework Grizzly.

À titre d’exemple, le serveur d’applications 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