« Devoxx – Jour 3 – La keynote
Flex : Custom style DataGrid »
25 novembre 2009
Imprimer ce billet

Devoxx – Jour 3 – JEE6

Comme énoncé dans notre résumé de la keynote du mercredi, la star de ce Devoxx 2009 est clairement JEE6. Et, au premier rang avec mon superbe t-shirt "I Love Spring", j'ai pu profiter d'une présentation générale de cette nouvelle version de JEE par Antonio Goncalves et la petite caricature de Rod Johnson :) .

 

Introduction

Tout d'abord quelques chiffres autour de JEE6 :

  • une sortie prévue le 10 décembre 2009
  • 11 ans de JEE (JPE / J2EE / JEE)
  • le plus grand intervalle entre 2 versions (3 ans et demi avec JEE5)
  • 28 spécifications

Un récapitulatif nous montre les différentes spécifications utilisées (ainsi que quelques technos Java SE 6) avec en jaune les nouvelles spécifications et en noir les montées de version majeures :

Il y en a pour tous les goûts : de l'injection, du back-end et du web et cela a de quoi séduire.

Certaines spécifications sont marquées comme pruned par JEE6 et pourraient éventuellement disparaître dans JEE7. Nous parlons ici des Entity CMP 2.x, de JAX-RPC, JAX-R et de JSR-88 (Java EE Application Deployment).

Antonio nous fait ensuite un rapide tour d'horizon des spécifications marquantes de ce JEE6.

Web Profile

Web Profile est un sous-ensemble de la plateforme JEE orienté Web. On compte parmi les spécifications retenues JSF, Servlet, JSP, JPA, JTA, JCDI, @Inject ou bien encore EJB Lite. La liste complète en image :

EJB Lite

De même que pour Web Profile, EJB Lite est un sous-ensemble d'EJB 3.1, le tout packagé dans un fichier War. Retenues dans EJB Lite :

  • Local Session Bean
  • Injection
  • CMT / BMT
  • Interceptors
  • Security

Out donc les Messages Driven Beans, les Remote Interfaces ou bien encore les Timer Services.

Managed Beans

Les Managed Beans sont de simples POJOs gérés par le container (lightweight model). Ces beans supportent un ensemble de services basiques (par annotations) dont :

  • Injection (@Resource ...)
  • Life-Cycle (@PostConstruct, @PreDestroy)
  • Interceptor (@Interceptor, @AroundInvoke)
@javax.annotation.ManagedBean
public class MyPojo {
   @Resource
   private DataSource dataSource ;

   @PostConstruct
   private void init() {
      // ...
   }

   @Interceptor(LoggingInterceptor.class)
   public void perform() {
       // ...
   }
}

Bean Validation

Antonio nous parle ensuite de Bean Validation, spécification qui va nous permettre de définir des contraintes directement sur nos POJOs par annotations. L'accroche : constrain once, validate anywhere ! Nous pouvons donc ajouter des validations de type @NotNull, @Size ou autres sur nos propriétés de bean. Il est aussi possible de définir nos propres validateurs.

Cette spécification définit ainsi un standard de validation pour Java, Bean Validation étant déjà supportée par JPA 2.0 et JSF 2.0. On a ainsi une validation qui part de la base de données et va jusqu'à la couche cliente.

JAX-RS

Un peu de RESTful dans JEE avec JAX-RS qui passe au passage en version 1.1 pour supporter les EJBs. L'API reste bien sûr orientée POJO et annotations. Voici un exemple d'intégration de JAX-RS avec un EJB :

@Path("/users/{userId}")
@Stateless
public class UserResource {
   @GET @Produces("image/jpeg")
   public byte[] getPhoto() {
      // ...
   }

   @GET @Produces("text/xml")
   public String getUser(@PathParam("userId") String id) {
      // ...
   }
}

@Inject et CDI (Context and Dependency Injection)

Nous vous avons déjà beaucoup parlé de ces JSRs (ici, ici, ici mais aussi là et encore là).
@Inject, @Named, @Qualifier, @Scope ou bien encore @Singleton, voici les annotations de JSR-330 que nous allons pouvoir utiliser.
Quant à CDI (JSR-299), qui utilise @Inject, elle nous propose un set de services utilisables par nos composants EE (servlets, beans...). Elle nous permet aussi d'utiliser nos EJBs directement dans JSF en tant que backing beans.
Évidemment, le contenu de ces spécifications est beaucoup plus large et nous n'avons ici qu'un rapide résumé.

Mais aussi...

Parmi les autres nouveautés, on peut citer en vrac :

  • Appels asynchrones avec @Asynchronous avec un retour void ou Future<T> ;
  • Annotation @Singleton ;
  • Annotation @Cacheable avec toute l'API de cache (contain, evict ou evictAll) qui permet le support d'un cache de second niveau ;
  • Embeddable Container, API qui permet d'initialiser le container, de récupérer les contextes... faisant qu'il est possible de le faire tourner dans un environnement Java SE (par exemple une application Swing), ce ne sera qu'un JAR dans votre classpath ;
  • Timer Service pour gérer la planification de tâche avec l'annotation @Schedule ;
  • Fichier web.xml optionnel grâce entre autres aux annotations @WebServlet, @WebFilter,@WebListener ou bien encore @WebInitParam ;

Conclusion

L'opération séduction fonctionne plutôt bien pour JEE6 si l'on écoute les différents commentaires des conférenciers en sortie de session. La simplicité et facilité d'utilisation des EJBs, le profile web ou encore les injections ont vraiment convaincus et nombreux sont ceux qui attendent désormais avec impatience ce 10 décembre 2009. En effet, il n'y a plus qu'à tester et à voir si JEE6 tient vraiment toutes ses promesses...

Mots-clefs :, , , ,

Billets sur le même thème :

Vous pouvez suivre les réponses reçues par cet article grâce au fil des commentaires.

15 réponses à “Devoxx – Jour 3 – JEE6”

  • Le 25 novembre 2009 à 9:44 (), Antonio Goncalves a dit :

    Très bon post ;o)

    Une information que je trouve très intéressante, est l'arrivée de nouveaux acteurs dans le cercle (trop) fermé des serveurs d'applications. Grâce au profile web, les éditeurs peuvent n'implémenter qu'un sous ensemble des APIs. Entre WebSpehere et Tomcat, il y avait un gouffre à combler. Le premier à tirer son épingle du jeu est Resin (de Caucho). Resin 4.x implémentera le profil web... à suivre.

    http://www.caucho.com/

  • Le 26 novembre 2009 à 9:17 (), Salah LAARIDH a dit :

    Des nouveautés Intéressantes, Nouvelle version JEE6 qui inspire pleinement des Frameworks Open Source tel que Spring, seam, google guice, hibernate,…

  • Le 27 novembre 2009 à 14:43 (), Cyrille Le Clerc a dit :

    @Antonio,

    Le moniteur de transactions distribuées nécessaire à JTA laisse un gouffre entre le Web Profile et Tomcat ou Jetty :-) .

    Ensuite, l'intégration dans le Web Profile de "JSF 2", "JSR 299 - Web Beans" et "JSR 330 - Dependency Injection for Java" plutôt, par exemple, que de JAX-RS me laisse un arrière goût politique qui nuira à la diffusion du JavaEE Web Profile.

    Cyrille (Xebia)

  • Le 27 novembre 2009 à 15:33 (), Antonio Goncalves a dit :

    Faisant parti de l'expert groupe Java EE 6, je fais parti de ceux qui ont voté contre l'inclusion de JAX-RS dans le profile web. Non pour des raisons "politiques", mais plutôt pour vendre cette nouvelle idée de profile et pour en minimiser la taille. Ensuite, il faut savoir que le cycle de vie de Java EE et du Profile Web sont décorélés. Il y aura donc un Web Profile 1.1 (certainement avec JAX-RS) bien avant Java EE 7

  • Le 27 novembre 2009 à 15:53 (), Alexis MP a dit :

    IL est simple de rajouter une implémentation JAX-RS 1.1 dans un web profile avec l'extensibilité de Java EE 6/Servlet 3.0.
    Avec GlassFish v3, "pkg install jersey" et hop!
    Je ne justifie pas le choix (pas mon rôle), je le minimise...

  • Le 30 novembre 2009 à 1:20 (), Cyrille Le Clerc a dit :

    @Antonio,

    J'ai manqué de clarté dans mes propos, j'espérais aussi un profil léger et consensuel qui satisferait les besoins de 95 % des applications java-web que nous développons et qui serait raisonnablement facile à satisfaire par atteindre de nouveaux entrants.

    JTA est quasiment à l'opposé : c'est utilisé par très peu de projets mais très difficile à maîtriser pour un éditeur.
    Pour mémoire, JBoss a du attendre le rachat d'Arjnua et JBoss AS 4.2 (mi 2007) pour proposer un moniteur JTA "production ready" pour reprendre les mots de Bill Burke.
    Concernant les nouveaux entrants potentiels sur le marché des moteurs de servlet certifiés, j'en vois peu qui soient en mesure de proposer un moteur JTA "production ready" :
    * SpringSource (Tomcat) n'a pas pour le moment de moniteur transactionnel,
    * Webtide/Intalio (Jetty) embarque la version OpenSource de l'assez discret moniteur JTA Atomikos sans expliquer comment ils savent supporter cette technologie (le support Atomikos commercial coûte 3200 eruo /CPU/an),
    * Caucho (Resin) annonce le support de XA mais je n'ai pas trouvé de documentation sur leur site.

    Dans la même rubrique "loin d'être utilisé par 95% des application java-web mais compliqué à maîtriser", il y a JSF 2.
    Les implémentation JSF 2 sont très rares. Même JBoss qui pourtant investit beaucoup dans JSF utilise l'implémentation de Glassfish/Sun. Quel nouvel entrant voudra/pourra supporter ses clients sur JSF 2 et apporter une solution plutôt que de répondre "c'est un problème dans l'implémentation de Glassfish/Sun, veuillez attendre qu'ils corrigent" ?
    Sans oublier le manque de consensus à prendre JSF alors que les débats restent passionnels autour de JSF vs. Wicket vs. Tapestry vs. Spring MVC vs. Struts vs. Stripes vs. ...
    Comme l'a rappelé Alexis, il est trivial d'intégrer dans une web app ou un middleware un framework comme JSF ou JAX-RS.

    Enfin, JCDI et @Inject, c'état probablement inévitable de les intégrer. Leur présence me rappelle juste que le vent de la division souffle sur Java EE 6.

    Cyrille (Xebia)

  • Le 30 novembre 2009 à 8:53 (), Alexis MP a dit :

    @Cyrille

    Le ticket d'entrée du profil web est quand même bien plus bas qu'auparavant ou EJB CMP, JAX-R, et autres JAX-RPC étaient requis. Je pense que des trois cités, c'est largement à la portée de SpringSource et Caucho (jetty pas sûr qu'ils soient intéressés, mais Intalio va peut-être changer la donne).

    Coté JSF, le débat entre MVC orienté composant ou action n'est pas clos effectivement et c'est là que l'extensibilité joue son rôle. JSF est un choix par défaut dont on sait qu'il est aligné avec le reste de la plate-forme. Pour ce qui est de l'implémentation, il en existe 2 et elles sont open source. Il existe plusieurs façons de se donner les moyens de supporter une brique qu'on n'a pas développer soi-même from scratch. Pas de pb pour GlassFish qui embarque Toplink depuis des années ou Weblogic qui fait du Metro.

    CDI, @Inject: il faut que tu en dises plus sur la division! ;)

  • Le 30 novembre 2009 à 11:17 (), Antonio Goncalves a dit :

    @Cyrille

    Je pense justement le contraire. Hormis le cas CDI et @Inject qui a fait, il est vrai, beaucoup (trop) de bruit, Java EE n'a jamais été aussi soudé. Tu donnes l'exemple de Mojarra (de Sun) qui est utilisé par JBoss. Il y a aussi EclipseLink (Eclipse) qui est utilisé par GlassFish (Sun). CDI et Bean Validation de JBoss utilisé par Sun...

    Java EE 6, c'est la spécification de "Bugs bunny et tous ses amis" (j'ai pas trouvé un slogan aussi marquant chez les Bisounours)

  • Le 30 novembre 2009 à 15:53 (), Cyrille Le Clerc a dit :

    @Alexis,

    Pour la division qu'apportent CDI et @Inject, Antonio dit lui même qu'ils ont fait "beaucoup (trop) de bruit". Web Beans a du au dernier moment être complètement revu car c'était, aux yeux de certains comme IBM, un modèle de composants concurrent des EJB. @Inject n'a-t-elle pas été souvent perçue comme "sortie à la dernière minute pour mettre des bâtons dans les roues de Web Beans / CDI" ?

    Que dois-je utiliser aujourd'hui sur un nouveau projet ? CDI ou @Inject ? Que se passe-t-il si je choisis pour mon projet @Inject alors que j'intègre un composant qui a choisi CDI ? La coexistence @Inject < -> CDI a-t-elle été spécifiée ?

    Comme les spécifications de CDI intègrent l'ensemble des API d'@Inject (annotations et interfaces), j'imagine que l'on peut intégrer des composants @Inject dans un projet qui repose sur CDI. En revanche, qu'en est-il de l'inverse ? Je ne trouve rien dans les spécifications, pour le moins laconiques, d'@Inject.

    @Antonio et @Alexis

    Je ne remets pas en cause les collaborations entre "grands éditeurs" sur des briques de base comme JPA, Validation ou encore JAX-WS.
    Mon point est sur la difficulté de monter en puissance sur des technologies complexes comme JSF et d'être pertinent à offrir du support sur un framework sur lequel on n'est pas committer.
    Qui n'a pas entendu un jour "il leur manque une JVM pour être crédible sur le middleware" ou "nous on est pertinent sur ce framework, on a été committer très actif dessus" ;-)

    @Alexis,

    "JSF ... est aligné avec le reste de la plate-forme".
    Devrais-je me sentir en marge de la plateforme si je suis plus à l'aise avec un framework web orienté action ?
    Pour ceux qui nourrissaient un espoir d'évolution de JSP, Rémi Maucherat nous l'avait déjà dit au Paris JUG, il n'y a qu'a passer à JSF 2 qui s'éloigne de JSP pour proposer son propre templating hérité de Facelets. Et si je n'utilise pas JSF 2 ...

    Cyrille (Xebia)

  • Le 30 novembre 2009 à 16:11 (), Antonio Goncalves a dit :

    Promis juré, j'écrirai une série de post sur @Inject/CDI (voir même une prez au Paris JUG ;o) car, il est vrai, le message d'injection de dépendances à été un peu perdu dans la cohue. Pour faire simple, CDI ne fonctionne pas sans @Inject.

  • Le 30 novembre 2009 à 16:13 (), Antonio Goncalves a dit :

    Ha, j'oubliai, si tu fais partie de ceux qui "nourrissent un espoir d'évolution de JSP", là je crois que c'est mort ;o)

  • Le 30 novembre 2009 à 16:20 (), Alexis MP a dit :

    "Web Beans a du au dernier moment être complètement revu".
    => Non, les modifs sont à la marge. Vraiment.

    Dans un app server, la question "CDI ou @Inject?" n'a pas de sens étant donné l'absence de sémantique de @Inject. C'est CDI qui "qualifie" @Inject.

    "Committer pour être crédible": je pense que la majorité des WebSphere dans la nature sont encore déployés sur un JVM Sun... SpringSource a toujours prôné l'intégration vis-à-vis de plein d'implémentations tierces à commencer par JTA. Se sont-ils trompés en se positionnant sur le créneau des serveurs d'applications?

    JSF: je comprends que tout le monde ne veuille pas en faire (même avec la v2), mais le rôle de la plate-forme Java EE (complète ou profil Web) est de fournir des solutions dans tous les domaines, framework MVC y compris. Pour les autres (au risque de faire une redite) il y l'extensibilité de la plate-forme. Au passage, la présentation de Roberto à Devoxx (session, pas keynote) parle de manière avancée des différentes solution d'extensibilité, pas seulement des fragments servlet 3.0.

  • Le 1 décembre 2009 à 1:15 (), Cyrille Le Clerc a dit :

    @Antonio

    > "nourrissent un espoir d'évolution de JSP", là je crois que c'est mort ;o)

    Merci pour la mauvaise nouvelle :-) . Tant pis pour moi, je jouerai Freemarker en espérant qu'ils s'améliorent un peu plus encore en s'inspirant de Google Sitebricks.

    @Alexis,

    > la majorité des WebSphere dans la nature sont encore déployés sur un JVM Sun

    WebSphere ou Weblogic ? IBM impose la JVM lors de l'installation de WebSphere (en particulier pour l'ORB) et j'ai même découvert un IBM SDK for Solaris, il n'y a que pour HP-UX qu'IBM annonce utiliser un JDK non-IBM : HP JDK for J2SE HP-UX 11i platform, adapted by IBM for IBM Software, Version 6.0.

    En revanche, je serais curieux de connaître la proportion de serveurs Weblogic déployés en production avec Sun HotSpot :-) .

    > SpringSource a toujours prôné l'intégration vis-à-vis de plein d'implémentations tierces à commencer par JTA. Se sont-ils trompés en se positionnant sur le créneau des serveurs d'applications?

    Il faudrait demander à VMWare étant donné le prix qu'ils ont payé SpringSource :-) .

    C'est vrai que SpringFramework a toujours revendiqué de reposer sur les implémentations des serveurs java sur lesquels il s'exécutait. C'était une autre époque, SpringFramework revendiquait de ne pas être intrusif dans le code, un grand éditeur de serveur J2EE ne pouvait s'empêcher de traiter Spring de "boite vide", ... :-)

    Il y avait quand même quelques ombres à l'intégration transparente de SpringFramework dans les serveurs J2EE. L'intégration au Transaction Manager de WebSphere a été problématique jusqu'en Juin 2007 (Rod Johnson : Spring Framework Certified on WebSphere) !

    Pour revenir sur le positionnement de SpringSource sur les serveurs Java léger, je suis plein d'espoirs :
    * La plupart de nos applications java-web se contentent très bien d'un moteur de servlet
    * Les utilisateurs recherchent aujourd'hui des serveurs Java légers, c'est notamment le positionnement de Glassfish v3 ;-)
    * J'ai envie que "Java Platform as a Service" devienne une réalité, j'en avais parlé dans Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud et un certain "Axel R" avait alors dit "il manque vraiment un OS et une JVM" ;-)

    En ce qui concerne Spring DM Server et le Blue Print OSGi, malgré les prophéties que j'entends depuis des années à propos de la déferlante d'OSGi dans les applications JavaEE, je suis encore dubitatif. Peut-être en 2012 si ce n'est pas la fin du monde :-) .

    Désolé d'avoir été bavard.

    Cyrille (Xebia)

  • Le 1 décembre 2009 à 1:42 (), Cyrille Le Clerc a dit :

    @Antonio,

    > Promis juré, j'écrirai une série de post sur @Inject/CDI

    Une démo @Inject implemented by Google Guice qui intègre un composant CDIsé ? :-)

  • Le 1 décembre 2009 à 1:47 (), julien gaucher a dit :

    C'est vrai que d'un point de vue de developpeur web (c'est bien de ca que parle le web profile ? de web non ?), ce profil light est totalement loupé. Inclusion de choses inutiles, quasi abandon des jsp (dommage, google ouvre des pistes avec sitebriks, closure templates) sur comment faire un systeme de templating efficace et elegant, et inclusion de l'usine a gaz jsf.

    il va encore falloir attendre pour avoir droit a jax-rs (qui est pourtant je pense une des plus brillantes api sortie coté web dans le monde java), et abandonner JEE pour faire par exemple du pur site web.

    dommage, il aura fallu la pression de spring pour faire evoluer toute la partie EJB, qui saura faire avancer correctement la zone web ?

    Et le mot pour rire : en 2010, vu que java mail n'est pas integré au profil web : il ne sera toujours pas possible de faire un mail sans ajouter des libs au serveur. (et je parle meme pas de la tete de l'api javamail). Je pense que si la communauté java voulait pousser les developpeurs web vers rails/django/grails elle ne pourrait pas faire beaucoup mieux.

Laisser un commentaire

« Devoxx – Jour 3 – La keynote
Flex : Custom style DataGrid »