Devoxx 2010 JEE6 Reloaded

C’est terminé

Je m’arrête là, il faudra relire/corriger, mais vous avez l’idée de ces 3 heures qui furent intéressantes.

Après une première saison l’an dernier, Antonio et Alexis sont ce matin devant moi dans une salle de 600 places pleine à craquer. Au programme ce matin, un aperçu de Java EE 6, une mise à jour par rapport à l’an passé. Les démonstrations se dérouleront sur Glassfish et JBoss AS 6. Avec 15 démonstrations, l’agenda va être chargé.

Antonio Goncalves est freelance, expert membre du JCP, auteur de plusieurs livres sur Java EE 5 et 6. Il fait aussi parti du podcast @castcodeurs. Alexis Moussine-Pouchkine est Glassfish Ambassador, speaker à de nombreuses conférences, il anime aussi le podcast « The Aquarium ».

L’application qu’ils vont démontrer est une application type CRUD pour créer des livres et des CDs. C’est un domaine simple qui permet de se concentrer sur la partie technique. Glassfish v3 est l’implémentation de référence de Java EE 6. Il y a un an Java EE 6 n’était pas encore final. Avec un noyau très riche, des stacks comme Grizzly, Metro, Jersey, Mojarra, c’est un serveur de nouvelle génération. Avec un support de la part d’Oracle, c’est un serveur d’application en production sur de grands sites aujourd’hui. Un noyau OSGI depuis le dépuis, extensible avec HK2, le support du clustering arrive dans la version 3.1 prévue pour début 2011.

Antonio va nous monter RedHat JBoss 6. Contrairement à l’an dernier, il y aura donc 2 serveurs d’application. J’en profite pour vous dire qu’IBM propose Websphere 8 en béta avec un support partiel de Java EE 6.

Un peu d’histoire

En mai 1998, le projet JPE débute. En septembre 2001, c’est la sortie de J2EE 1.3 avec ces fameux EJB 2.1 En novembre 2003 avec 20 spécifications, c’est la sortie de J2EE 1.4. On ajoute les WebServices, le managment et le déploiement. Ensuite Java EE 5 arrive en mai 2006 avec 23 specs, dont les EJB 3, JPA 1 et JSF. Et pour terminer fin 2009 Java EE 6.

Il y a quoi dedans

Java EE 6 c’est JSF 2, Servlet 3,0, JSP 2.2, EL 2.2 JSTL 1.2 et d’autres acronymes numérotés…
Séparé en différents domaines : Web, Enterprise, Web Services, Managment et Security.

Java EE 6 c’est aussi la mise au placard de vieilles spécifications qui n’ont plus forcément d’intérêt comme les Entity CMP 2.x par exemple. Java EE 6 c’est 28 specifications. Afin que l’on puisse créer des serveurs plus ou moins complet, Java EE 6 ajoute la notion de profile. Avec par exemple le Web profile, il est possible de faire fonctionner une application avec un noyau plus limité. En même temps, vu le nombre de spécifications, c’est normal. Local Session Beans, Injection, CMT/BMT, Interceptors, Security… c’est plus léger et suffisant. Le tout dans un War qui ne fait pas 41 mo (ça c’est de moi).

JNDI

Les noms JNDI sont très simples. Ce principe d’annuaire permet de retrouver et d’injecter des beans dans votre application. On commence à voir que Java EE 6 c’est aussi un framework, et pas simplement des spécifications. Antonio explique comment injecter un bean avec différent scope.

Managed Beans 1.0

Un bean managé c’est un pojo géré par le conteneur. Vous pouvez avoir de l’injection, le conteneur peut gérer le cycle de vie du pojo, et vous pouvez utiliser des intercepteurs. Un modèle léger qui permet ensuite de faire ce que l’on veut.

@ManagedBean
public class MyPojo {

 @Resource
 private Datasource ds;
 
 @PostConstruct
 private void init() {
  ...
 }

 @Interceptors(LoggingInterceptor.class)
 public void myMethod() {
..
}
}

Les interceptors 1.0 viennent de la spécification des EJB 3.0. Permettent d’ajouter des comportements sur des beans. Par exemple @AroundInvoke ou @AroundTimeout. C’est de l’AOP comme explique Antonio.

Demo 1

La première démonstration montre une petite classe simple, sur la partie Managed Bean et Interceptor. En partant d’un pojo, Antonio avec IDEA IntelliJ montre comment transformer une simple classe du métier en Bean. Il ajoute un @ManagedBean sur son Bean, un @PostConstruct sur une méthode de log. Alexis et les 1200 yeux dans la salle regardent religieusement l’apparition d’un premier Bean… Et le tout sans XML. Le Bean est injecté dans une classe simple avec l’annotation @Resource, et c’est tout. Antonio construit un JAR, il execute ensuite « appclient demo1.jar » ce qui fait que le conteneur peut injecter le bean dans la classe principale.
L’outil « appclient » est fournit par n’importe quel serveur d’application compliant Java EE 6.

JPA 2.0

La spécification JSR 317 évolue en dehors de la spécification des EJB. Avec un mapping plus riche, c’est une évolution de JPA 1.0, le JPQL est plus complet, je reviendrai dessus car je compte assister à la présentation d’Emmanuel Bernard.

Vous pouvez faire du mapping de collection sur des types simples, des entités et des types embeddables. Antonio montre un exemple avec un objet BookReference, marqué @Embeddable. Puis il montre une Entity avec un @ElementCollection protected Set<BookReferenc> references. Ce tag @Embeddable est aussi capable de faire du multi-niveau.
L’API Criteria permet d’avoir un typage fort et d’avoir une configuration orientée objet. Vous pouvez par exemple faire :

EntityManager em=...;
CriteriaBuilder cb=em.getCriteriaBuilder();
CriteriaQuery>Book< query=cb.createQuery(Book.class);

Root>Book< book=query.from(Book.class);

query.select(book).where(cb.isNull(book.get("description")));

// ou sinon
query.select(book)
     .where(cb.isNull(boo.get(Book_.description)))
     .join(...)
     .orderBy(...)
     .distinct(true)
     .having(...)
     .groupBy(...)

Alexis explique que cela renforce la vérification à la compilation et donc une meilleure qualité.

Demo 2 JPA

Une entité JPA Book avec 2 NamedQuery, une findAllBooks et une findAllSciFiBooks. Antonio montre une classe qui créé plusieurs types de livre. Il lance le tout, c’est du Java SE standard tout ce qui a de plus normal.

Il y a beaucoup d’autres nouveautés sur JPA 2.

Servlet 3.0

Alexis bascule maintenant du côté Web avec les Servlets. Plus facile à développer, la spec Servlet 3.0 permet aussi de faire des choses sympas comme de l’asynchronous mode, avec Comet. C’est similaire à du reverse ajax. C’est un moyen d’aller du serveur vers le client finalement.
Les servlets 3.0 sont très légères. Des annotations comme @WebServlet sur une classe qui étend HttpServlet permet de binder une url sans configuration XML. Des annotations comme @WebFilter et @WebListener permettent de faire aussi ce qu’il fallait auparavant déclarer dans un web.xml. Ce fichier est d’ailleurs optionnel.
La Pluggability vise à répondre au problème récurrent d’intégration des frameworks. Il est possible de fractionner un web,xml. Chaque framework peut maintenant fournir son web.xml fragment, le serveur Java EE 6 assemble le tout. Concernant la règle de qui passe avant l’autre, Alexis explique que c’est configurable.
Un Jar de type resource peut contenir des CSS, JS et images, et permet au conteneur Web d’optimiser finalement le chargement de ces données.

Il est possible de surcharger des Web Fragments avec un fichier web.xml si vous souhaitez controler cette partie. Les Jars de votre application doivent être placés dans /WEB-INF/lib.

Alexis montre ensuite l’exemple d’une Servlet simple, qui créé 2 livres et les persiste. Pas de web.xml. La page est un peu moche, ça manque d’un peu de Web design. Bon, les gars du back ne sont pas des brutes en Web, l’intérêt étant ici de voir la légèreté et la simplicité de l’application. Si vous voulez un coup de main pour mettre de la couleur, faites-moi signe 🙂

EJB 3.1

Avec des annotations comme @Local ou @Remote, certains points comme les interfaces ne sont pas toujours nécessaires. Les Remote interfaces sont optionnelles. Il est possible de packager des EJB3 3,1 dans un WAR avec par exemple une Servlet, un bean EJB3.1 et une simple entité. C’est bien plus simple. Et pas de XML… Hem… Bon on parlait de quoi déjà ?

Sur la partie appel asynchrone, l’équivalent des Messaging Beans est un peu plus différent. Il y a d’une part l’annotation @Asynchronous, qui permet de faire des appels asynchrones, et d’autre part le système basé sur JMS. Si vos besoins sont transactionnels, avec le support de reprise sur incident, JMS qui est un middleware est la solution. Si vous devez par exemple faire une execution non bloquante, l’annotation @Asynchronous est parfaite.

Il y a aussi le Timer Service qui pemet d’exécuter régulièrement un bout de code pour se réveiller et exécuter votre code. Avec par exemple

@Schedule(dayOfWeek="Mon-Frid", hour="9") void wakeup()

Demo 4 ajout d’un EJB Stateless

Un EJB est transactionnel. Ceci permet à Antonio d’alléger du code. Il retire de la Servlet une partie transactionnelle, et il déplace le code dans l’EJB. Plus besoin de récupérer l’EntityManager car il sera injecté sous la forme d’une ressource.

Antonio ajoute une annotation @Inject, retire pas mal de code technique et compile le tout. Il lance le test sur JBoss AS 6. Celui-ci devrait sortir en RC1 cette semaine.

Singleton

Vous pouvez aussi créer un bean @Singleton. Pratique par exemple pour faire un cache comme le montre Antonio. Alexis montre un simple Singleton. Une classe est annotée @Startup et @Singleton, elle permet de créer la liste des langues supportées par leur application d’achat de livre. Ce Bean sera une référence avec une Map des codes ISO et des noms des pays.
Un Bean peut recevoir ce singleton avec l’annotation @EJB. Le mot « simple » est répété plusieurs fois, je crois que l’assemblée a compris.

Embeddable Container

Il existe une API qui permet de faire tourner un conteneur léger dans une application Java classique. Oui vous pouvez faire du Java EE 6 dans votre application Java classique, sans avoir un conteneur complet. C’est standardisé et donc portable. Il suffit de déclarer dans une classe Java une entité EJBContainer, le contexte est alors disponible et votre code tourne.

Alexis montre une classe ItemEJBTest toute simple avec un EJBContainer et un Context. Avec une annotation @BeforeClass il initialise son environnement. Dans une méthode @Test il montre comment retrouver un Bean en faisant un lookup portable, il créé un livre et il le persiste via le service du Bean qu’il a récupéré. Bon vous ne comprenez pas tout…
Il devient facile de faire des tests d’intégrations avec EJB 3.1.

JSF 2

Alexis parle maintenant de JSF 2. Il ne demande pas Servlet 3.0 et vous pouvez vous en servir dès maintenant. C’est le framework standard orienté composant, et la version 2.0 porte bien son nom. Avec de nombreuses améliorations, c’est important. La composition des pages se fait avec Facelets (xhtml). Assez mature et bien intégré dans les outils, c’est une alternative à JSP, bien plus pratique. Il y a bien l’expression language, mais il faut bien entendu éviter d’écrire trop de logique dans la vue. Le fichier faces-config.xml est maintenant optionnel. Vous pouvez injecter vos beans avec @ManagedBean sans devoir les déclarer dans faces-config.xml. Au passage je pense très fort que Spring Faces devient du coup inutile… Personnellement je ne vais pas le regretter.

Demo 7 JSF

Antonio montre comment ajouter un ManagedBean qui sera le front-controller de son application. Il délègue la partie métier à un EJB Stateless. Son bean JSF est @RequestScope. On retrouve le Singleton aussi qui est injecté dans le Managed Bean.
Côté vue il montre une page XHTML, le support du code completion dans IDEA IntelliJ, en terme de productivité c’est MIEUX que Spring Faces, car les noms des ManagedBeans sont bien détectés, ainsi que des propriétés. Autant de temps de gagné.

JSF Components

Il y a beaucoup de composants et il était difficile de construire ses propres composants. Or JSF propose une approche orienté composant qui s’adapte bien pour créer des applications clientes riches (RIA pour les intimes). Aujourd’hui avec un seul fichier XHTML, sans code Java, vous pouvez créer votre composant. On retrouve d’ailleurs cette approche dans Play! avec les tags, mais ici le format des fichiers est du HTML avec du Groovy.

La démo sur les composant est la première fois où l’on voit un gros paquet de XML. Le composant déclare les attributs qu’il accepte, et une section composite:implementation permet d’écrire la partie affichage. Il est possible d’utiliser un peu d’expression language. Bon cette partie dans JSF 2 est un peu verbeuse, et dans la présentation d’Alexis et d’Antonio, c’est ce que j’ai le moins aimé.

Alexis fait ensuite la démonstration de son composant…

Bean validation

Antonio présente ensuite Bean Validation. Ceci vous permet de valider le métier de votre bean, comme par exemple le fait que des arguments sont obligatoires, un code postal ou le format d’un code isbn.

  
@Size(min=2, max=5,message="le code est invalide")
private String bookCode;

Côté JSF2, Antonio ajoute simplement <h:mesages> dans sa page JSF, le formulaire est alors capable d’afficher les messages d’erreur lorsque le code n’est pas correct. C’est super simple.
Demo 10 terminée, et aucun plantage. Toutes leurs démonstrations ont marché.

JAX-RS 1.0

API haut niveau pour faire des services RESTful. Pojo et annotations based, JAX-RS permet de mapper des verbes HTTP vers des composants. Un EJB peut donc devenir un service Web REST facilement. Concretement :

@Path("/hello")
public class HelloWorld {
  @GET
  @Produces("text/plain")
  public String sayHello() {
     return "Hello";
  }
}

Pour appeler cette ressource : GET http://localhost/hello

JAX-RS supporte aussi différents mime-types. Vous pouvez avoir une méthode qui retourne un flux de byte[] qui sera une image par exemple. Ou un fichier PDF par exemple. De la même manière vous pouvez déclarer une méthode qui consomme un certain type de mime-type.

Avec les EJBs il est possible aussi de récupérer des paramètres et de les passer directement à une méthode de votre EJB. Vous pouvez donc annoter un EJB pour qu’il soit disponible sous la forme d’une ressource, puis par exemple ajouter de quoi récupérer un parametre :

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

Alexis fait maintenant la 11e démonstration, avec un EJB sur lequel il ajout des annotations JAX-RS. On voit ce code

 @Get
 @Path("/{bookisin}")
 @Produces(MediaType.APPLICATION_XML)
public Book getBookByIsin(...) {
 ...
}

Alexis fait une démonstration avec Curl, le livre récupéré est « God doesn’t think he is Larry E. » ce qui passe discrètement dans la salle… Il présente ensuite les fonctionnalités avancées de JAX-RS. Il est facile de retourner du JSON ou du XML.

Demo 12 multiple UI

Alexis montre ensuite un client Java FX qui se connecte sur la partie cliente, avec une interface très sympa. C’est Sébastien Stormacq qui a réalisé cette partie je crois.

Alexis passe ensuite à un client Swing réalisé avec Matisse, le moteur de Netbeans. Ce client se connecte à l’API RESTful et la liste des livres s’affiche en quelques secondes.

Antonio montre ensuite une version GWT qui tourne dans un JBoss, et qui se connecte au service RESTFul.

Enfin il termine par une démonstration Android réalisé par Gabriel Kastenbaum. Le livre créé avec la partie GWT se retrouve dans l’émulateur Android, et la salle applaudit.

CDI

L’injection dans l’approche JEE 6 est d’injecter avec un typage fort, n’importe où dans votre application. Il y a d’une part CDI (JSR-299) et d’autre part DI (JSR-330). Il y a une histoire. WebBeans vient de JBoss Seam, et JSR-299 en pratique a mis en place ce qu’Alexis appelle « loose typing, strong typing ». Aujourd’hui CDI est implémenté par plusieurs frameworks. Weld est la référence implémentation mais il existe aussi Apache Open WebBeans ou Caucho CanDI par exemple.

JSR-330 a été inité par SpringSource et Google, avec pas grand chose finalement. Cependant cette spécification a posé les bases d’une CI simple.

CDI a besoin d’un fichier WEB-INF/beans.xml qui peut être vide, mais qui permet de découvrir les beans au démarrage. @Named permet de rendre disponible les beans à l’EL. Il vaut mieux d’ailleurs pour JSF basculer de @ManagedBean vers @Named.
@Inject permet d’injecter des ressources, mais @Resources est toujours là.

Alexis parle de stéréotype. C’est un moyen de regrouper des comportements récurrents déclarés avec des annotations comme @Named et @RequestScoped dans une nouvelle annotation que vous appelerez comme vous voulez.

Alexis passe maintenant en mode démo. Il remplace ce qui était purement JEE6 par des annotations JSR-330. Il rempace par exemple @Resource par @Inject dans un EJB. Cependant pour que cela fonctionne, il faut un fichier (même vide) dans le répertoire WEB-INF/beans.xml afin que le moteur d’injection démarre et se charge du cablage de vos dépendances.

Alexis descend ensuite un peu plus loin et là c’est un peu compliqué à retranscrire en live. Les Qualifiers permettent de spécialiser à l’exécution l’implémentation d’une classe. Alexis montre une interface Customer et 2 spécialisations. Un SpecialCustomer et un DefaultCustomer pour sa démonstration. Il montre ensuite un EJB où l’interface Customer est utilisée avec @Inject. A l’execution le conteneur s’arrête et ne peut pas déterminer l’implémentation à utiliser.
Alexis annote alors son SpecialCustomer avec @Premium et il précise ce type dans son EJB, et cette fois-ci CDI peut injecter l’utilisateur. L’annotation @Premium permet de préciser l’implémentation.

Ensuite, si vous annotez les 2 implémentations avec @Alternative, cette fois-ci il est possible de définir le type d’implémentation dans le fichier XML.

Context

Context est lié au scope, vous avez @RequestScoped, @SessionScoped, @ApplicationScoped et @ConversationalScoped. Le contexte conversation a été proposé dans JBoss Seam il y a quelques années, et je suis fan de cette approche, plus proche du métier et des cas d’usages.
Une conversation peut être injectée dans une Facade, et sera proprement associé par exemple avec différents onglets dans votre navigateur.

Alexis et Antonio arrivent à la 15eme démonstration. Cette démonstration montre comment ajouter une Conversation à son application. Cette conversation, vous l’avez deviné, va permettre de terminer la démonstration en achetant des livres et des CDs. La méthode checkout terminera la conversation. Par rapport à la démonstration et en donnant un avis forcément un peu léger, Spring Webflow s’en sort mieux que l’approche CDI. Dans Web flow la définition de la conversation s’effectue en XML, avec le rechargement à chaud d’un flow. Dans CDI, nous nous appuyons sur du code si j’ai bien compris, pour définir le scope de la conversation. Il faudra que je creuse cette partie,

CDI est peu intruisif et léger finalement. J’ai eu le sentiment que la déclaration était légère.

Java EE 6 adoption

Antonio fait le bilan de l’adoption de Java EE 6. Glassfish et JBoss sont les 2 serveurs qui tournent avec Java EE 6 à ce jour (novembre 2010). Antonio cite aussi Websphere 8 qui est dispo en béta et Oracle Weblogic qui ne restera pas à côté. Caucho a décidé d’implémenter le web profile uniquement. Apache Geronimo est aussi cité.

Du côté des IDEs, Eclipse, NetBeans et IDEA IntelliJ supportent bien Java EE 6. Ludovic Champenois présentera d’ailleurs le tooling. Enfin il y a beaucoup de livres sur la plateforme Java EE.

Une phrase sur TheServerSide résume bien aujourd’hui la position de la plateforme Java EE 6:
Frameworks like Spring are just a bridge between the failure of J2EE past and the success of the Java EE 6 future. Frameworks are out and extensions to the Java EE 6 platform are ins.

Conclusion

La présentation se termine par un résumé de ces 3 heures qui furent très complètes. Mon côté architecte et métier a vu ce matin une architecture mature et réfléchie. Oui c’est une stack à apprendre, qui est plus simple que Spring. Faire simple est un concept que nous oublions parfois. Est-ce que finalement ces dernières années construites sur les cendres de Java J2EE 1.x ne nous ont pas fait perdre un peu de temps ? Je ne crois pas. Je crois que Spring a réussi au contraire à sauver l’approche entreprise proposée par Sun il y a quelques années. Alors merci à Spring, mais il est peut-être temps de laisser la place à Java EE 6.

Articles similaires:

Devoxx 2010 dans quelques jours Devoxx 2010 keynote Devoxx 2010 Keynote Mark Reinhold Devoxx 2010 : mardi