Compte rendu de Javapolis 2007

Les ESB ou Entreprise Service Bus ne se croisent que lorsque l'on est confronté à de grands systèmes. Etant dans ce cas, j'ai voulu en savoir plus sur cette technologie.

Après une rapide explication sur la place de l'open source en entreprise et une liste des ESB Open Source, ils ont choisi d'en traiter trois (Mule, ServiceMix et Open ESB) en utilisant comme fil conducteur pour la démonstration, l'implémentation du système automatique de péage par vidéo du centre ville de Londres.

Ils ont commencé par traiter de Mule qui permet le routage et la transformation des messages selon une grande quantité de protocoles et repose sur Spring. Les avantages de Mule sont une simplicité de développement et de tests sans assommer le développeur par le XML.

Au début de la seconde partie, ils ont introduit JBI (Java Business Integration) qui est spécifié par la JSR 208 pour standardiser un container ESB. L'avantage de JBI est que la spécification vous rend indépendant du vendeur, par contre cela amène plus de rigidité. Ils ont alors présenté ServiceMix qui permet de masquer une partie de la complexité de JBI et supporte le déploiement à chaud.

Enfin ils ont conclu Open ESB qui est l'implémentation de SUN de JBI et par conséquence dispose d'un excellent support outils dans NetBeans avec notamment un éditeur BPEL par Drag and Drop.

Pour ma part ( Gildas Cuisinier ), j'avais déjà eu l'occasion de tester Mule dans sa première version, et j'ai pu découvrir la version 2 en action lors de la présentation.
Sa force est clairement sa simplicité, la configuration de cet ESB étant directement liée à Spring, on s'y retrouve très facilement.

J'ai découvert la spécification JBI durant cette conférence, et j'en sors assez déçu. Sa complexité me rappelle vaguement la celle des EJB 2.

Les slides de la présentationLes slides de la présentation

David J. Anderson a animé cette session sur les pratiques agiles.
Il a commencé par évoquer le thème de la confiance et de la transparence (trust and transparency), tant au niveau d'une équipe que dans les relations entre les différents acteurs d'un projet.

Selon le speaker, la recette d'un bon projet est :

• un focus sur la qualité
• une réduction de l'encours (Work-In-Progress)
• équilibrer demande et capacité d'avancement
• prioriser

Ces conseils sont pleins de bon sens et il ne vous est pas difficile de faire un parallèle avec la vie courante pour s'en convaincre.
Par exemple, lorsque j'ai beaucoup de choses à faire, il m'arrive d'en arriver à des interblocages au point de ne plus rien avancer. En décidant de limiter l'encours à un nombre fini de tâches, il est beaucoup plus facile de focaliser la motivation, et c'est là également qu'intervient la priorisation (et assez souvent, je l'espère pour vous, les contraintes ne sont pas drastiques).

Est venu ainsi le temps d'une première mise en situation, à travers le thème How to create or destroy trust ?
Très intéressant comme exercice : nous avons en petits groupes réfléchis, soit à comment créer une atmosphère de confiance, soit à comment rendre les gens méfiants.
Autant dire que pour la seconde question, la plupart des participants n'a pas eu de mal à fournir une liste exhaustive de "solutions".

En synthèse, parmi les éléments favorisant la confiance : l'utilisation du tableau blanc pour y tracer les actions et témoigner de l'avancement, rendre les informations accessibles de la façon la plus simple pour n'importe qui.
Et lorsqu'on dit n'importe qui, en particulier le client ou donneur d'ordre avec pour objectif une totale transparence favorisant un travail en commun sur les variables d'ajustement (augmenter les effectifs ou restreindre les fonctionnalités) sans en arriver à devoir négocier (qui favoriserait la méfiance).

Un second exercice a été de lister les éléments permettant de suivre et identifier la valeur ajoutée sur un projet.
Parmi ces éléments on retiendra en particulier le Work In Progress (l'encours) et le Lead Time (délai de réalisation d'une fonction).
On se rend notamment compte que l'encours diminue le niveau de qualité via l'augmentation du délai de réalisation d'une fonction. Par exemple, de l'expérience de David J. Anderson, le passage d'un délai d'une semaine à 3 mois peut entraîner une diminution d'un facteur 30 de la qualité.
C'est d'autant plus un cercle vicieux si on n'agit pas rapidement, car la baisse de qualité va entraîner davantage d'anomalies et donc de corrections et donc potentiellement encore allonger le Lead Time si on laisse augmenter le Work In Progress.

En conclusion sur ce thème, rien de tel que le désormais classique triplet (calendrier, coût, fonctionnalité) qui régule un projet et en particulier sa qualité et sur lesquels on peut jouer pour ne pas mettre en péril la qualité.

Les deux autres thèmes de cette session ont été l'identification des goulets d'étranglement et la planification des itérations.
A ce sujet, on retiendra qu'on peut décomposer une itération sous la forme suivante : initialisation - attente - réalisation - attente - nettoyage (en anglais : Setup - Queue - Task - Wait - Cleanup), le speaker ayant illustré cela par une analogie avec le passage chez le dentiste et son expérience personnelle (repeindre les murs entourant son habitat).
A la vue de cette analyse, on comprend mieux pourquoi on a tendance à prévoir des itérations longues. Dans le cas de l'agilité, le focus sera plutôt sur la réduction de certaines étapes comme par exemple l'initialisation.

Les slides de la présentationLes slides de la présentation

Quelques jours après la sortie de Spring 2.5, rien de tel qu'une petite session de 3 heures pour bien assimiler les nouveautés.
D'autant plus que la présentation a été très agréable à suivre.

Parmi les nouveautés qui ne sont pas déjà reprises dans ce billet blog, nous avons notamment appris que le JDK 1.3 n'était plus supporté par la version 2.5 du Spring Framework dont la compatibilité débute donc au JDK 1.4.
Côté JDBC, en plus du support de JDBC 4 (java.sql.wrapper, gestion de LOB, nouvelle hiérarchie d'exceptions), on notera le support des mises à jour en lot (ou encore appelé batch) ainsi que l'apparition de nouveaux templates SimpleJdbcCall et SimpleJdbcInsert.

Nous avons également appris que Spring pourrait utiliser le serveur HTTP embarqué dans le JDK 1.6 dans la version 2.5.1 pour faire des tests de services web par exemple.
Pas de surprise du côté Java EE 5 : EL unifié, prise en charge des annotations de la JSR-250, le support de JTA et de Jax-WS en particulier en mode stand-alone sans un contexte "Java EE".

Spring 2.5 rend plus flexible l'autowiring, via l'utilisation des annotations et de @Autowired, en acceptant des configurations hétérogènes au sein d'une classe.
De plus, il introduit l'autowiring par type sur n'importe quelle méthode (avec un ou plusieurs paramètres), de permettre une alternative à l'autowire si aucun candidat n'est trouvé, ou encore de fournir un "@Qualifier" permettant de résoudre les conflits dans le cas de plusieurs candidats à la résolution par type. Le tout étant possible via la déclaration <context:annotation-config> qui permet d'activer le processor pour la gestion des annotations et de l'autowiring.

A cet instant de la session, le speaker a pris le temps d'identifier les défauts de l'approche annotations + autowiring vis à vis de l'approche classique (toujours possible) via xml : les changements nécessitent recompilation, et la configuration porte sur une finesse de niveau classe et non d'instance.

Enfin, concernant le core de Spring, le speaker est revenu sur d'autres éléments du nouveau namespace context, en particulier le <context:component-scan qui, couplé au <context:include-filter et <context:exclude-filter, permet de gérer les déclarations de composants Spring via l'annotation @Component.
Sans oublier les extensions d'AspectJ dont le META-INF/aop/xml couplé avec le <context:load-time-weaver/> permet de mettre en place de l'injection au niveau d'objets non managés Spring.

Au rayon des différentes extensions Spring, il y en a 2 qui ont réellement attiré mon attention (Eric) : Spring MVC et Spring Test Context Framework.

Spring MVC se décline désormais tout en annotations, bref de simple POJOs annotés pouvant très simplement être testés.
De plus, les prototypes de méthodes sont beaucoup plus larges et permettent de simplifier le développement.
Voici quelques extraits de code :

@Controller
public class MyController {
    
    @RequestMapping("/myAction")
    public void handleAction(HttpServletRequest req, OutputStream out) {
        ...
    }
    
    @RequestMapping("/myOtherAction")
    public String monTraitement(@RequestParam("monParam") String param, ModelMap model) {
        ...
        return "redirect:myAction";
    }
}

@Controller
@RequestMapping("/myEditAction")
@SessionAttributes("item")
public class MyController {

    @RequestMapping(method = RequestMapping.GET)
    public void setup(@RequestParam("itemId") int id, ModelMap model) {
        ...
    }
    
    @RequestMapping(method = RequestMapping.POST)
    public String processSubmit(@ModelAttribute("item") Item item, BindingResult bindingResult, SessionStatus sessionStatus) {
        ...
    }
}

@Controller
@RequestMapping("/myAction")
public class MyController {
    
    @RequestMapping(params = "action=list"))
    public String list(ModelMap model) {
        ...
    }
    
    @RequestMapping(params = "action=show"))
    public String show(RequestParam("id") int id, ModelMap model) {
        ...
    }
}

Le framework de test supporte JUnit ainsi que TestNG.
Son objectif est de faciliter la gestion de contexte des tests et la mise en cache de certains éléments, et bien entendu de permettre d'injecter des dépendances dans les tests pour faciliter leur écriture.

Avec son lot d'annotations @RunWith, @ContextConfiguration, @Transactional, (...) en complément des annotations classiques (par exemple @Autowired), un certain nombre de "Runner" sont déjà proposés notamment pour s'intégrer à JUnit (selon versions).
Il propose également des extensions à JUnit via les annotations @ExpectedException, @Timed et @Repeat.

Indépendemment du Test Context, 2 classes utilitaires sont proposées : SimpleJdbcTestUtils et ReflectionTestUtils, servant respectivement à réaliser des opérations répétitives sur la base de données (compter, vider une table, lancer un .sql) et à utiliser l'API Reflection pour modifier des éléments non accessibles à partir du test (attribut privé par exemple).

Mais le principal apport de ce framework est la gestion de contexte avec un mécanisme d'annotations et de listeners permettant par exemple de gérer un contexte transactionnel sur une méthode de test : l'annotation @Transactionnal permet de demander à ce que les modifications en base de données se fassent dans le cadre d'une transaction qui sera invalidée en fin de test (le comportement pouvant être affiné par exemple via l'annotation de classe @TransactionConfiguration qui peut définir si un rollback doit être mené ou non, ou encore préciser explicitement le bean en charge de la gestion de transaction.

Nous avons également eu droit à une petite démo illustrée du PetClinic, se focalisant sur la partie Spring MVC qui a un peu évolué et devient complètement dans l'esprit POJO (des idées très intéressantes), très aisément testable.

Puis, le portfolio Spring a été passé en revue : on apprend notamment que Spring WebFlow 1.0.5 (compatible Struts / JSF / Spring MVC) introduit 3 nouveaux scopes entre request et session, qu'il prend en charge certaines problématiques comme le bouton "précédent", et que la version 2.0 pourra fonctionner en standalone.
Certaines APIs comme Spring Batch et Spring JavaConfig à venir pour 2008 n'ont été qu'évoquées, ainsi que Spring IDE pour lequel nous avons appris qu'il restait Open Source et gratuit mais va être utilisé comme socle d'une solution payante Spring Tool Suite.

Les slides de la présentationLes slides de la présentation

Cette conférence a été très intéressante, car il s'agissait d'une présentation de SEAM par des utilisateurs et pas les concepteurs. Comme ils l'ont annoncé au début de leur session : "not what it is, but what it is like". Il ne s'agissait donc pas d'une présentation de type "notre API est la meilleur, utilisez la" mais plutôt : "cette API est bien, on l'utilise, toutefois ces quelques points sont gênants/énervants..."

Ils ont commencé par une présentation de JSF et EJB3 rapide, indiquant les points forts par rapport à Struts et EJB2. Puis ils ont parlé des problèmes de JSF/EJB3 : le fait que le backing bean de JSF ne soit qu'un couplage entre couches qui est verbeux (XML de configuration) et difficile à refactorer (xml et outcome String), le fait que les EJB ne peuvent être utilisés comme backing beans (voir point précédent) et n'ont pas de concept de scope, l'absence de support de worflow type wizard...

C'est alors qu'ils ont introduit Seam qui vient pallier un certain nombre de ces points avec entre autres l'apport de nouveaux scopes (conversation, page et business process, la notion de bijection, l'utilisation des validator d'Hibernate....) Ils ont aussi appuyé sur les écueils qu'ils ont rencontré comme la dispersion de la documentation, la non rétro compatibilité, la lenteur de déploiement et certains concepts nouveaux pour les développeurs comme les conversations.

Les slides de la présentationLes slides de la présentation

Cette session d'une heure était l'occasion pour le speaker de nous expliquer la démarche qu'il a suivie pour générer un CRUD pour une application web développée avec Spring MVC et Web Flow.
L'idée était de pouvoir générer pour chaque classe du modèle les composants suivants :

• un DAO
• un Manager
• un FormAction
• une JSP d'édition, une autre de recherche, et une de liste
• le XML pour Web Flow

Autre contrainte de cette expérience, l'analyse était en retard et il n'était pas envisageable d'attendre : des ajustements étaient donc à prévoir.
Dernière contrainte, la version de Java, liée à la date de démarrage du projet : Java 1.4.

Le point de départ a été la modélisation en base de donnée des objets métiers.
Puis à partir de cette définition, une génération via AppFuse + AppGen et ANT des classes du domaine annotés avec des commentaires XDoclet (comprenant des extensions personnalisées).
Et enfin une génération, via les XDoclet et notamment Hibernate, des différents composants listés précédemment.

Dans un second temps, Maven a été utilisé et FreeMarker est venu remplacer les XDoclet (plus flexible et pouvant s'interfacer avec la base de données utilisées pour la modélisation selon le speaker), et la possibilité de ne plus tout générer à chaque fois. L'état final du système de génération étant la suivante :

• génération des objets métiers à partir des définitions en base de données
• génération du descripteur Hibernate pour le mapping de base de données à partir des objets métiers
• génération de la structure de la base de données à partir du descripteur Hibernate
• génération des différents fichiers de vues et de navigation à partir des définitions en base de données

Personnellement, je m'attendais davantage à un guide de bonnes pratiques / outils pour la génération de code.
Malheureusement il ne s'agissait que d'un retour d'expérience sans illustrations concrètes.

Les slides de la présentationLes slides de la présentation

J'espérais de cette session une présentation générale de BPM. Cette présentation s'est limitée à moins de 10 minutes. Ensuite la présentation commerciale du produit WebMethods a pris le dessus et je suis sorti de la conférence pour souffler un peu après cette première journée et pouvoir profiter des discussions de couloirs qui font aussi l'attrait de ce genre de conférences.

Je ( Gildas ) rejoins tout à fait les propos de Christophe, en ajoutant que la conférencière n'était pas du tout captivante, et donnait presque l'impression de découvrir son sujet en même temps que nous.

Les slides de la présentationLes slides de la présentation

Hudson est un système d'intégration continue, âgé de trois ans qui commence à faire de plus en plus parler de lui. Il est extensible avec plus de 35 plugins existant. Ce qui fait le plus son intérêt est sa simplicité d'utilisation. Il est possible de le télécharger sous forme d'une archive WAR embarquant un serveur Jetty. Il suffit alors de le lancer : java -jar hudson.war et de tester son interface web. Pour ceux qui trouveraient cela encore trop compliqué il est possible d'utiliser la version Java Web Start lançable depuis son site. Après renseignement de quelques variables d'environnement (répertoire d'installation de Maven, du repository...) il suffit d'indiquer l'emplacement du pom.xml de votre projet pour avoir terminé. Hudson propose aussi des fonctionnalités comme les flux RSS, la messagerie instantanée ou la possibilité de retrouver le build qui avait passé tous les tests pour en faire une version de votre logiciel.

Les slides de la présentationLes slides de la présentation

Javaforge est, comme son nom l'indique, une forge développée en technologie Java, née à l'initiative de la communauté Javalobby qui recherchait un outil collaboratif pour sa communauté.
Javaforge a vu le jour en 2006 (SVN + Java) et propose un certain nombre de modules :

• des outils de communication : forum, email, chat, RSS, blob, wiki, partage de documents
• des outils de gestion de communautés : accès anonymes, gestion de projet, ...
• des outils de suivi : anomalies, exigences, changement, ...

Javaforge supporte CVS et SVN, ANT et Maven, propose des APIs permettant de plugger des listeners (par exemple une détection de virus) ou la construction de plugins Wiki.
Il propose bien entendu un certain nombre de métriques, un moteur d'indexation et de recherche, ainsi qu'une intégration avec Eclipse, NetBeans, ou encore Mylyn.

Javaforge en quelques chiffres, c'est 7500 développeurs et 1400 projets.

Les slides de la présentationLes slides de la présentation

Ne connaissant Flex que de réputation, c'est avec un grand intérêt que je me rendais à cette conférence.
Malgré les problèmes réseaux durant cette session, les deux orateurs ont réussi à captiver le public facilement. L'humour était de la partie, par le biais de remarques cyniques comparant Flex et Java pour la création d'interface graphique.

La présentation a tout d'abord débuté sur les problèmes d' "expérience utilisateur" avec les interfaces graphiques, introduisant ainsi Flash/Flex pour combler ces manques, comme par exemple la validation des formulaires.

Nous avons eu ensuite droit à une démonstration de création d'application avec FlexBuilder, un IDE payant basé sur Eclipse pour le développement Flex.
Le développement pouvant être fait par simple Drag'n Drop ou par l'édition du fichier XML directement.
Durant la démonstration, un système d'affichage d'une galerie FlikR ( récupérée par WebService ) sous la forme d'un CoverFlow ( à la iTunes ) a été créé très rapidement, montrant ainsi la force de Flex pour les interfaces utilisateurs.

Ils nous ont ensuite présenté quelques applications Flex abouties, citons par exemple Flow ( un petit jeu sympathique ) ou BuzzWord ( un éditeur de document complètement fait en Flex qui est assez bluffant )

Une présentation de AIR a ensuite été faite, technologie intéressante et qui pourrait prendre une part de marché de Java pour les applications standalones.
AIR est aussi basé sur une machine virtuelle et les applications AIR peuvent donc être exécutée sur tout système possédant une implémentation de celle-ci. Mais AIR étant basé sur Flash, elle apporte aussi tous les effets et possibilités graphiques de celui-ci.
Le tout avec une simplicité étonnante, comparé à Swing par exemple.

Bref, je suis sorti de cette conférence en ayant découvert une technologie vraiment intéressante, et qui mérite à première vue sa réputation.

Je partais pour apprendre plein de choses sur JSF lors de cette session. Ed Burns est l'un des co-leader de la spec JSF et Yara M. H. Senger un instructeur reconnu.

La première partie de la conférence était un historique de JSF puis une présentation des 4 piliers de JSF : le cycle de vie, la navigation, les interactions avec le modèle et les vues.
Ils ont commencé par la partie vue avec rapide présentation du concept de bibliothèque de tags qui est convertie en arbre de composants qui est ensuite converti en arbre DOM.
Ils ont ensuite parlé de l'interaction avec le modèle et notamment de EL, des objets implicites, du binding de valeur ou de composant, des validateurs et convertisseurs.
Pour la navigation, ils ont abordé la possibilité de navigation statique ou dynamique.
Enfin, ils ont conclu la première partie en parlant du cycle de vie JSF et de la possibilité d'utiliser des Listeners.

Dans la dernière partie, ils ont parlé rapidement des librairies de composants graphiques.

Pour conclure j'ai été plutôt déçu par cette session. Les speakers et le titre me laissait penser que j'allais avoir une série d'astuces permettant d'être encore plus productif, mais il s'agissait tout simplement d'être productif par rapport à une débutant. Toute la conférence, je me suis répété qu'il ne fallait pas que je sorte, que cela allait devenir plus complexe avec plus d'infos sur JSF, mais la présentation est restée dans le domaine de l'introduction générale. Finalement j'ai regretté de ne pas être allé écouter Bruce Eckel parler de Flex.

Les slides de la présentationLes slides de la présentation

Cette session animée par Mark D. Hansen, auteur du livre de même nom que l'intitulé de la session, se focalisait sur l'utilisation des Web Services pour la mise en place d'une architecture orientée service.
Le speaker a commencé par évoquer la difficulté de prise en main du modèle de programmation de Web Services en Java, en précisant que le plus troublant était le "S" de SOAP qui signifie "Simple", pour aboutir à la conclusion que l'écriture de WebService était effectivement lourde aux premiers abords.
Il a illustré cela par la nécessité de mettre en correspondance les 2 mondes que sont le monde objet et le monde XML, à l'image de la problématique d'ORM qui se focalise elle sur la mise en correspondance d'objets avec un modèle relationnel.

Une citation reprise au sujet des WebServices "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." illustre également les architectures SOA.

La première partie de la présentation s'est focalisé sur les notions d'architecture, les concepts (un peu de vocabulaire ne fait pas de mal), et les standards.
Il a commencé par mettre en balance REST et SOAP en insistant sur le fait que SOAP ne se limitait pas au protocole HTTP pour véhiculer un message (on peut y ajouter notamment FTP, JMS et SMTP). D'ailleurs en voyant le comparatif entre REST et SOAP sur les aspects (format, définition d'interface, transport), on se rend bien compte de la simplicité de l'approche REST.

Nous avons ensuite eu droit à 2 exemples d'implémentation REST :

• l'une avec un simple HttpURLConnection sollicitant une Servlet via un HTTP GET, cette dernière écrivant tout simplement du XML dans le flux de réponse
• l'autre avec l'API JAX-WS 2.0 qui permet de s'abstraire des contraintes HTTP avec l'interface Provider<Source> et sa méthode invoke côté serveur, la fabrique Service et l'interface Dispatch<Source> côté client.

Puis nous nous sommes intéressés à JAXB, en commençant par évoquer la différence entre le Binding (partir d'un objet pour générer un schéma XML ou l'inverse) et le Mapping (faire correspondre un objet et un schéma XML), puis en examinant la manière dont fonctionne JAXB et en évoquant rapidement quelques éléments avancés telle la classe XmlAdapter qui permet de surcharger le mapping lorsque nécessaire (par exemple une chaîne de caractères à décomposer en plusieurs attributs d'un objet).
Cette première partie a fini avec une démo sur l'utilisation de JAX-WS.

Puis, sur un thème plus proche de la réalité des applications d'entreprise, Mark D. Hansen a commencé par évoquer les différentes approches en matière de mise en oeuvre :

• Code First : on développe puis on génère les définitions d'interfaces (WSDL, XSD)
• Contract First : on définit les interfaces (WSDL, XSD) et on génère les squelettes
• Meet in the Middle : le scénario le plus courant en SOA, qui nécessite de passer par une ou plusieurs transformations pour réaliser en quelque sorte un "Mapping"

On notera que par défaut, dans l'approche Contract First, le WSDL déployé n'est pas exactement celui utilisé pour définir l'interface et générer les classes. Ils sont cependant équivalents et il est possible de forcer le WSDL via l'annotation @WebService.

On retiendra les outils WsImport WsGen (utilisables en ligne de commande, ANT, ou directement en Java) qui permettent respectivement de générer les classes à partir d'un WSDL et les différentes classes / ressources à partir d'un POJO @WebService.
On retiendra également la facilité de test en utilisant le serveur HTTP embarqué avec le JDK 1.6 qu'on peut lancer avec la classe Endpoint et sa méthode publish.

Les slides de la présentationLes slides de la présentation

Cette session avait pour principaux objectifs de décrire les grandes lignes des spécifications EJB 3 et JPA 1.0 et de pointer du doigt les principaux pièges ainsi que les bonnes pratiques.

C'est tout d'abord Kenneth Saks (spec lead EJB 3 et EJB 3.1) qui nous a parlé des EJB.
Il a tenu à insister sur la différence entre la déclaration de type Global Namespace et Component Environment Namespace dans la déclaration de ressource, par exemple @Resource(name="componentName", mappedName="globalName") en nous recommandant de recourir à la déclaration mappedName avec parcimonie.
En effet, toute ressource vivant en dehors de l'application doit avoir une déclaration, cette déclaration n'a lieu d'être définie qu'au déploiement. Ce qui explique pourquoi on associe un nom local avec un nom global et on référence systématiquement le nom local (via l'attribut name ou un lookup sur le SessionContext ou en utilisant le préfixe java:comp/env/, et non directement sur le contexte).

Il a également mentionné via un exemple les différents scopes dans le cas de déploiement de ressources, en faisant apparaître un scope par EJB et un scope par .war, ce qui peut parfois donner lieu à des comportements inattendus si on n'y prête pas attention puisqu'un code donné pourra avoir un comportement différent selon le contexte dans lequel il s'exécute (tel ou tel EJB ou war).
Il a également rappelé que le conteneur prenait en charge la concurrence d'accès sur les EJB, ce qui ne prive pas le développeur de garder à l'esprit qu'une Servlet ne doit pas avoir d'état.
A ce sujet, il nous a montré comment injecter proprement une ressource avec état dans une servlet : en déclarant la dépendance au niveau de la classe et en y accédant par un lookup (et non en déclarant un attribut).

Après quelques rappels sur des erreurs classiques comme l'instanciation d'une dépendance empêchant l'injection et amenant un NullPointerException, ou encore l'appel d'une méthode interne de l'EJB sans se servir de la référence (qu'on peut obtenir via sessionContext.getBusinessObject(MonInterface.class)) qui n'est pas un appel managé par l'EJB, nous avons abordé les EJBTimer.

Pour ceux qui ne le sauraient pas, les EJBTimer sont transactionnels et peuvent donc s'inscrire dans une transaction globale, ce qui peut permettre de gérer finement un certain nombre de choses (création, destruction, ...).
De plus, les EJBTimer ne sont pas liés à une instance exclusivement, le timeout peut se déclencher sur n'importe quelle instance (et de manière plus large, sur n'importe quelle instance d'un cluster) et pas nécessairement celle qui a donné naissance au timer. Par conséquent, seules les informations de type Timer fournies en paramètres de la méthode annotée @Timeout doivent être utilisées pour obtenir des données quant à l'état du Timer.

Enfin, il nous a également décrit l'une des spécificités encore mal connue : le Standalone EJB client (lequel est inclus dans la spécification) et la façon dont on peut écrire un client proprement.

Puis ce fût au tour de Linda DeMichiel (spec lead EJB 3 et JPA 2.0) d'occuper la scène et de nous parler de la persistance.
Linda est revenue sur les concepts de Entity, Persistence Unit, Persistence Context, Entity Manager et Entity Manager Factory (un par unité de persistance) en illustrant avec du code (la version avec annotations) et en rappelant par exemple qu'il reste un fichier xml incontournable (celui qui permet de configurer une unité de persistance).
Elle nous a ensuite montré via des exemples de code les situations les plus courantes de relations entre objets (et les annotations utilisées) en insistant sur les relations bidirectionnelles et la nécessité de gérer de manière cohérente une relation (vous savez bien, un set/add/remove où le développeur gère explicitement la relation pour éviter qu'elle ne soit définie qu'à moitié).
Enfin, le problème des entités filles orphelines a également été évoqué, mentionnant que ce dernier devrait être adressé avec JPA 2.0.

Puis, chose désormais classique dans les présentations de type ORM, elle nous a ensuite présenté les différentes approches pour gérer une hiérarchie de classes avec JPA (toujours en illustrant avec du code et les annotations utilisées, leurs avantages et inconvénients) en insistant sur ce qui est intégré dans la norme JPA (la stratégie une table par classe y est notamment actuellement optionnelle).

Puis, la speaker a abordé le thème de l'accès aux données, comprendre les requêtes implicites ou explicites que le provider JPA exécute en fonction de la configuration du modèle ou des requêtes JPQL.
Ce fût donc l'occasion de décrire un certain nombre de concepts comme EAGER/LAZY (à noter que LAZY n'est qu'un conseil qu'on donne, il se peut que l'ORM n'en tienne pas compte) qui s'appliquent à la navigation dans un modèle ou aux requêtes, pour en arriver au classique problème du nombre de requêtes SQL engendrées selon la configuration.
Un petit détour par les NamedQuery et la façon dont on peut les déclarer, les externaliser, les utiliser, mentionnant notamment le mot clé FETCH et ses limitations (une seule collection et sur un seul niveau), le fait que ces requêtes peuvent être compilées au démarrage de l'application (ce qui peut permettre de faire apparaître des erreurs dans la syntaxe), l'utilisation de requêtes SQL natives étant possible mais bien entendu déconseillée.

Linda est ensuite revenue sur des points précis comme le détachement d'un objet, pointant du doigt le manque de définition actuelle dans JPA 1.0 sur le comportement intervenant lorsqu'on accède à une entité détachée de la session, chose qui sera sans doute spécifiée dans JPA 2.0.
Sur le thème du détachement / rattachement d'une entité, elle nous a montré que cette stratégie, conjuguée à l'approche POJO, pouvait très venir remplacer des stratégies aujourd'hui devenues peut-être un peu trop envahissantes/complexes comme le pattern DTO.

Enfin, parmi les recommandations faites sur la fin de la session, notamment dans le cadre de la gestion de transactions et de l'injection/appel de l'EntityManager, il ne faut pas oublier de passer par une EntityManagerFactory (ou un lookup JNDI) dans le cas d'un appel à partir d'une servlet (l'EntityManager n'étant pas Thread safe), tout comme il faut penser à recourir à @PersistenceContext(type=EXTENDED) dans un contexte Container-managed si on souhaite que l'EntityManager soit propagé par un appel à un autre EJB par exemple, et enfin de ne pas oublier le joinTransaction sur l'EntityManager pour l'associer à une transaction lorsqu'on ne travaille pas avec un conteneur.

Les slides de la présentation de KennethLes slides de la présentation de Kenneth

Les slides de la présentation de LindaLes slides de la présentation de Linda

En fin de journée, j'ai eu l'occasion de suivre une session courte de Xavier Hanin sur Apache Ivy qui est un gestionnaire de dépendances.
Ivy gère pour vous la transitivité des dépendances et s'intègre avec ANT. Ce n'est pas pour autant qu'Ivy est concurrent de Maven puisqu'il ne se concentre que sur une partie de ce que propose Maven, d'autant plus qu'Ivy est compatible avec les repositories Maven 2 (compatibilité qui devrait être totale Maven 2 d'ici la version 2 d'Ivy).

La démo a très bien illustré l'objectif de l'outil (dans Eclipse) lequel permet de mettre en évidence les dépendances et d'éventuels conflits de version (plusieurs chemins de dépendances amenant à 2 versions différentes d'une même librairie).

Un jour après la session, on apprenait qu'Ivy était disponible en version 2 beta 1.

Les slides de la présentationLes slides de la présentation

Dernière session (courte) de la journée, la présentation de Mylyn par Wayne Beaton.

Pour ceux qui ne connaissent pas Mylyn, le point de départ est le constat qu'un développeur passe approximativement 10% de son temps à réellement développer. Le reste du temps est donc du temps pouvant être optimisé, notamment la lecture du code et l'organisation du travail.
Sur la base de cette réflexion a été conçu Mylyn (anciennement Mylar), davantage connu pour l'intégration à Eclipse de différents gestionnaires de tâches / de bugs (Bugzilla, JIRA) mais dont la force est une gestion du contexte utilisateur avec pour objectif de n'afficher dans Eclipse que ce qui est susceptible d'intéresser le développeur (filtre dans le package explorer notamment).

Mylyn permet d'aller jusqu'à persister tout un contexte pour pouvoir le recharger plusieurs jours ou mois plus tard et bénéficier de l'analyse de l'outil pour retrouver les éléments de contexte utiles aux tâches qu'on souhaite réaliser. Mylyn propose bien d'autres fonctionnalités complémentaires, notamment la réorganisation des tâches permettant au développeur d'organiser sa semaine.

Une présentation très intéressante par deux passionnés avec qui j'ai pris plaisir à discuter par la suite.
Francois Orsini est évangéliste JavaDB (Apache Derby). Jean Francois Arcand est leader du projet Grizzly (un framework basé sur NIO et utilisé dans Glassfish, Open ESB...) et des activités Ajax Push (Comet) chez SUN.

Ils ont commencé par nous présenter le concept d'Ajax Push, avec une connexion suspendue entre le client et le serveur, permettant au serveur de pousser des données vers le client à volonté, sans que le client ne fasse d'interrogation à répétition (polling). Le framework repose sur NIO qui permet l'établissement d'une socket non bloquante et d'éviter alors le problème du 1 connexion/client servi par 1 thread. L'utilisation de NIO permet de servir jusqu'à 10 000 clients grâce à 5 thread sans effondrer les performances. Ils ont aussi abordé les problèmes de cette technologie : la surcharge du client en événements, les firewalls pouvant couper la connexion, la norme HTTP qui limite à deux connexions vers un hôte, la similarité avec une attaque de type DoS (Denial of Service) et les pertes de données lors des déconnexions-reconnexions. Enfin ils ont aussi parlé du challenge du streaming avec les proxy faisant cache, la surcharge de la mémoire et le comportement de IE (les données ne sont pas disponibles avant la fin de la connexion ou un flush déclenché par l'envoi de 2k d'espaces).

Ils ont ensuite présenté JavaDB, une petite base de données que vous pouvez embarquer dans vos applications. Ils ont alors fait la démonstration d'une applet de chat utilisant la technologie de push Ajax. Cette applet embarque une base JavaDB pour retenir les conversations, permettre de stocker les messages en cas de déconnexion, jusqu'au retour de la connexion.
La technique a légèrement trahi François lors de sa démonstration, mais ce sont les risques des présentations reposant sur des démonstrations techniques...

Les slides de la présentationLes slides de la présentation

Le Keynote a débuté par l'intervention de Stephan Janssen, revenant sur les 2 premières journées, évoquant l'avenir de JavaPolis et nous invitant tous à revêtir le t-shirt pour la photo de groupe du lendemain.
Du côté de l'avenir de JavaPolis, il a évoqué la limite désormais atteinte en nombre de participants, avec une tendance à vouloir rester dans le lieu MetroPolis auquel JavaPolis est historiquement lié. Autre aspect de la conférence, le questionnement sur le mois lié à l'événement : en effet, Stefan a sondé l'assistance pour savoir quelles étaient les préférences parmi les mois d'octobre / novembre / décembre.

Puis il a laissé la parole à James Gosling, dont ce fût la première apparition à JavaPolis (ou pas tout à fait).
Souvenez vous du thème de JavaPolis 2006 "Meet your idols" et du film de promotion mettant en scène un clone de James.
Le père fondateur de Java a souhaité revenir sur ceci pour préciser qu'il ne roulait pas en Hummer ;-) puis sur un ton un peu plus sérieux il a fait un point sur l'actualité de l'univers Java.

Autre première, celle de Bruce Eckel qui nous a sensibilisé aux "Unconference" ou encore "Open Space", expliquant brièvement les principes et nous invitant à contribuer.

Enfin, la fin du keynote fût l'occasion pour l'assistance de poser des questions à James Gosling.
Au programme, Apple et le support du JDK 6.0, Google avec GWT et Android, le futur de Java.

Dirk Koenig et Guillaume Laforge ont animé cette session sur Groovy, en particulier sur la version 1.5 qui ponctue une belle année au cours de laquelle Groovy a également remporté les JAX Award.

Parmi les nouveautés du kit de développement, GPath pour la partie XML, l'ORM, ainsi que l'automation Office, ont été évoqués.

Groovy se positionne également sur la scène des DSL (Domain Specific Language) en misant sur l'expressivité du langage, en particulier :

• les parenthèses optionnelles
• la syntaxe pour l'utilisation des Maps
• la déclaration / utilisation des propriétés ou encore des unités (ex.: 3.days)
• les closures
• la surcharge d'opérateurs (ex.: a.plus(b)

Au rayon des nouveautés de Groovy 1.5, on retiendra notamment la prise en charge des fonctionnalités de Java 5, l'amélioration des performances, ou encore l'intégration aux environnements de développement.
La grande force de Groovy est son intégration avec Java, et la prise en compte de fonctionnalités de Java 5 (comme les annotations et génériques) apporte encore plus de possibilités sur le plan Java EE (cf. des exemples d'intégration à JBoss Seam avec une classe Groovy utilisant des annotations JPA et Validation).
Groovy propose également une API de test qui peut elle également séduire pour sa capacité de concision et de lisibilité (Mocks, Stubs, GroovyTestCase).

Groovy mise également sur la JSR-223 "Scripting", son intégration avec Spring 2.x et le namespace lang via <lang:groovy .../>.

Groovy c'est également une communauté et une actualité relayée par http://groovyblogs.org ou encore http://aboutgroovy.org/.

Les slides de la présentationLes slides de la présentation

Cette présentation était faite par "Crazy" Bob Lee. J'y allais dans l'idée de découvrir Guice dont mes connaissances se limitaient à "un framework d'injection à base d'annotations". En sortant il en était de même....

Non pas que Bob Lee ait fait une mauvaise présentation, mais il a profité de cette conférence pour faire un "Effective Guice" comme "Effective Java" de Joshua Bloch. Pendant une heure, il a enchaîné les conseils d'utilisation sur les annotations et API de Guice.

La conférence était sans doute très intéressante pour quelqu'un connaissant Guice, mais pour quelqu'un d'ignorant comme moi, on avait une heure de recommandations du genre : "prefer getInstance() to getProvider()" sans savoir de quoi ils s'agissait. Je pense qu'un petit avertissement dans l'abstract aurait été le bien venu, celui-ci laissait plus penser à une présentation générale (comme bon nombre à Javapolis) qu'une présentation nécessitant une pratique du framework.

Les slides de la présentationLes slides de la présentation

Quel avenir pour la plateforme Java EE ? C'est ce à quoi a tenté de répondre Roberto Chinnici (Sun), membre du groupe d'experts Java EE 6 et spec lead.
Cette JSR est très récente : la public review est prévue pour début 2008 et la release est attendue pour la mi 2009.

Il a donc commencé par nous parler du problème de la taille des dépendances et du contenu de la spécification.
En particulier, l'introduction des "profiles", c'est à dire un sous-ensemble cohérent permettant de traiter une catégorie d'applications : ainsi, le profil Web fait partie de la spécification (et c'est le seul, d'autres profils pourront voir le jour via le JCP).
Il y a également la volonté de briser progressivement les dépendances historiques ("pruning") que ce soit pour EJB Entity (remplacé par JPA) ou encore JAX-RPC (remplacé par JAX-WS) qui deviendront optionnels dans une release ultérieure.

La volonté est également à la simplification de la configuration (davantage d'annotations pour supprimer le web.xml), et du packaging (des EJB directement dans un .war).

Java EE 6 reposera sur Java SE 6, et parmi les JSR dont l'intégration est probable mais encore incertaine on citera :

• Bean Validation
• Timer API
• Work Manager API

Les slides de la présentationLes slides de la présentation

Dans la série des nouveautés en prévision pour la plateforme Java EE 6, ce fût au tour de Kenneth Saks (spec lead EJB 3 et EJB 3.1) de mettre quelques éléments en perspectives pour le futur des EJB via la JSR 318.

L'objectif avoué est toujours et encore à la simplification : réduire le nombre d'interfaces, notamment en rendant les interfaces locales optionnelles.
Sur le principe du packaging des EJB (évoqué lors de la session précédente), l'objectif est également d'avoir un unique contexte java:comp/env et par exemple de pouvoir partager les Persistence Unit (JPA).

Du côté des fonctionnalités, on notera une volonté de gérer la concurrence d'accès, notamment par l'introduction des annotations @Singleton, @ReadOnly, @ReadWrite, @BeanManagedConcurrency, permettant de la paramétrer.
Le speaker nous a également décrit la partie "Timer API", insistant notamment sur la notion de transaction, de champs d'action allant au delà de l'arrêt / redémarrage du serveur, de sa gestion dans un cluster, du scheduling avec une syntaxe Cron, ou encore de l'annotation @Schedule.

Enfin, il a également été question de thème tel la gestion asynchrone via l'annotation @Asynchronous et l'interface java.util.concurrent.Future<V> introduite par le Java SE 5, mais aussi la mise en oeuvre de communication avec état via WebServices.

Les slides de la présentationLes slides de la présentation

Session de fin de journée regroupant James Gosling, Neal Gafter, Joshua Bloch, Martin Odersky, pour un débat / réflexion sur l'évolution du monde de l'informatique.

Ce qu'on peut retenir entre autres :

• l'informatique est et sera plus que jamais partout
• l'offshore a évolué, ce n'est désormais plus majoritairement motivé par l'aspect économique, mais de plus en plus lié à un manque de gens formés
• un challenge évoqué pour illustrer les problématiques à étudier : arriver à certifier qu'un programme sera exempt d'erreurs de type NullPointerException, ClassCastException

Un BOF assez attendu, animé par Neal Gafter, sur les closures et plus précisément sur le thème de la gestion des exceptions, de la gestion des ressources.
Sans rentrer dans le détail (la session étant extrêmement technique), Neal proposait une réflexion et une syntaxe autour de scénarios classiques dans les APIs Java classifiés en tant que "control structure", en particulier la libération de ressources dans un bloc finally (ex. ouverture de fichier).

Pour être plus concret sur le sujet, nous reprenons ci-dessous un extrait du blog de Stephen Colebourne résumant les cas d'utilisation ciblés :

 // resource management
 try {
   // open resource
   // use resource
 } finally {
   // close resource
 }

 // locking
 try {
   // lock
   // process within the lock
 } finally {
   // unlock
 }

 // looping around a map
 for (Map.Entry<String,Integer> entry : map.entrySet()) {
   String key = entry.getKey();
   Integer value = entry.getValue();
   // process map
 }

L'objectif étant d'intégrer cette gestion dans les APIs via l'introduction de closures, permettant aux développeurs utilisant l'API de ne pas avoir à traiter ces problématiques et donc d'améliorer la lisibilité du code.

Le Keynote du jeudi fût l'occasion de faire la photo de groupe promise la veille.
Puis ce fût au tour de Bruce Eckel de prendre les commandes pour nous parler de Flex, aidé par d'autres intervenants pour illustrer de façon exhaustive avec des démos.
Ce fût également l'occasion d'annoncer le récent passage Open Source de la technologie AMF et d'illustrer pour les développeurs Java la mise en oeuvre d'une application Flex+Java (utilisation basique de <mx:DataService ...>).

Ensuite vint le grand moment pour Stephan, l'heure de parler de son bébé, j'ai nommé Parleys.com.
Après avoir expliqué les différentes alternatives qu'il avait pour la mise en oeuvre de la V2, il nous a présenté Benjamin Dobler qui a travaillé avec lui pour la mise en oeuvre de Flex AIR côté client.
Au programme beaucoup de nouveautés : client standalone avec mise à jour automatique et visualisation offline, une interactivité entre la version en ligne dans le navigateur et le client standalone, affichage simultané des slides et de la vidéo, utilisation de la timeline pour ajouter des commentaires et des tags, etc.

Puis, dernière partie de ce keynote, une présentation de Sun en particulier sur Java ME et Java FX.

Linda DeMichiel (spec lead EJB 3 et JPA 2.0) est venue nous parler du travail autour de la nouvelle version de JPA.
Le contenu de JPA 2.0 n'en était qu'à ses prémisses et rien n'était vraiment arrêté (comprendre qu'il ne faut pas tirer de conclusion hâtive de ce qui est décrit dans les paragraphes suivants).

Elle a commencé par nous parler de l'annotation @ElementCollection permettant de déclarer le mapping d'une collection de type primitifs (ex. Set < String >) avec également les annotations complémentaires @CollectionTable et @Column.
Puis, sur le même thème, elle est revenu sur l'annotation @Embeded permettant de déclarer un attribut de type complexe dans le cadre d'une composition, et nous a montré comment la déclaration d'une collection de nature identique pourrait se faire toujours en ayant recours à @CollectionTable. Ainsi, il serait possible de décrire le mapping d'une classe @Embeddable au niveau d'une autre classe, en conjonction avec les annotations @CollectionTable, @AttributeOverrides et @AttributeOverride. Cette dernière annotation permet de customiser le mapping pour un ou plusieurs attributs, avec la possibilité de recourir à la notation pointée dans le cas d'imbrication sur plusieurs niveaux (ex. name="embedded1.embedded2.attribut").
Elle est également allée plus dans le détail sur des choses plus compliquées tournant autour de la notion d'@Embeddable (relations déclarées et leurs limites).

Autre évolution qui devrait intéresser les développeurs, l'amélioration de la prise en charge de tris allant au delà de l'annotation @OrderBy utilisée pour le chargement de données.
Ainsi, l'annotation @OrderColumn permettrait de prendre en compte également une relation d'ordre au niveau persistance. Malgré tout, l'intérêt de la chose est discutable dans la mesure où ce mapping pourrait empiéter avec le rôle de la base de données.

Autre amélioration potentielle, celle autour des Maps qui élargirait les possibilités tant pour la clé et que pour la valeur (type primitif, Embeddable, Entity) avec l'apparition d'une nouvelle annotation permettant d'expliciter la déclaration au niveau mapping, permettant d'aller jusqu'à la déclaration de relations ternaires (Map < Entity, Entity >).
Enfin, il devrait pouvoir être possible, via l'annotation @Access, de définir plus finement la stratégie utilisée par l'outil de persistance, à savoir l'utilisation directe de l'attribut (FIELD) ou celle des mutateurs (PROPERTY) lors des lectures / écritures en base de données.

Parmi les thèmes alors en pourparler, ont été mentionnés l'inclusion ou non de la stratégie de persistance "une table par classe concrète" à la spécification (actuellement elle est facultative), ainsi que la gestion des suppressions d'orphelins.

• l'enrichissement du langage de requête (concat, group by, ...)
• la possibilité de se restreindre à une ou plusieurs classes données (clause CLASS(x) IN) dans le cas d'une requête sur une hiérarchie de classes
• amélioration de la syntaxe de construction de CriteriaQuery en s'inspirant de ce que proposent les différentes implémentations.
• ...

Les slides de la présentationLes slides de la présentation

Un petit Quickie par Lucio Benfante qui nous a présenté une partie du méta framework Parancoe.
Il nous a montré comment écrire des DAOs en se limitant à l'essentiel, à savoir spécifier dans une interface ce qu'on attend de telle ou telle méthode ... et c'est tout !
L'implémentation proposée repose sur 3 éléments : une description du contrat dans une interface, un nommage des méthodes basé sur des conventions, l'utilisation de l'AOP pour en générer au Runtime l'implémentation.

J'ai vraiment trouvé l'idée et la présentation intéressantes, montrant comment on peut rendre un code plus que lisible et ne pas s'embêter avec les classiques écueils (gestion d'exception et libération de ressources notamment).

Que dire si ce n'est de vous encourager à visionner la session sur Parleys.com.

On citera notamment certains arguments de Joshua Bloch, à savoir "the feel of Java" prôné par James Gosling lors de la création de Java. Cet esprit de simplicité étant, selon Joshua Bloch, mis en danger par certains éléments de la proposition BGGA (pour ceux qui n'auraient pas déjà décrypté : Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé).
En particulier, il nous a par exemple sensibilisé aux dangers du non local return (cf. vidéo).

Ce qu'on peut retenir de cette session improvisée (elle n'était pas prévue et s'est substituée à la session "Effective Java reloaded" initialement proposée par Joshua Bloch, c'est dire l'importance de la chose sachant que la session abandonnée servait également de promotion à la mise à jour de l'ouvrage éponyme prévue pour 2008), c'est de ne pas se précipiter et d'étudier d'autres approches peut-être plus dans l'esprit "the feel of Java" (il a notamment cité les propositions CICE et ARM) ou de se poser la question du support de ces fonctionnalités par un autre langage (il a cité Scala, mais on peut également compléter avec Groovy et JRuby).

Les slides de la présentationLes slides de la présentation

Que dire de particulier sinon encore une fois vous renvoyer vers le podcast ...

Côté animation, nous avons eu droit à une distribution de bières, de gadget Google (petit pin's avec animation lumineuse).
Il faut dire qu'en plus des 2 Googlemen habitués au JavaPosse (Carl Quinn et Dick Wall) présents à Anvers (Tor Norbye et Joe Nuxoll étant eux de la fête par Skype interposé), nous avons eu le droit à la participation de Joshua Bloch et Neal Gafter !

Loin des débats de très haute voltige qu'animent les discussions autour des closures, voila une JSR très attendue par la majorité des développeurs Java.
Qui n'a jamais été confronté aux limites de l'API actuelle et a été tenté de s'orienter vers des alternatives ?
Qui d'autre que Stephen Colebourne, auteur et Project Lead de Joda Time, Java Champion, pouvait prendre en charge cette JSR qui a fait l'unanimité ?

Que les connaisseurs de Joda Time se rassurent, ils ne seront pas perdus avec la JSR 310.
Vous pouvez d'ailleurs très facilement accéder aux informations liées à cette JSR que ce soit par des mailing list publiques, un wiki, ou encore un SVN accessible sans restriction.

Venons en aux faits.
Avant de parler des nouveautés, Stephen a illustré les nombreux écueils ou bugs potentiels (6 en 5 lignes de code sur son exemple) que l'utilisation actuelle de l'API Date pouvait engendrer.

L'API sera compatible avec les classes existantes, celles-ci implémenterons les interfaces définies par cette JSR et ne seront pas dépréciées.
La construction des objets immuables (les classes et attributs rendus de plus final) sera rendue user friendly de par l'utilisation du builder pattern.

Cette API profite des fonctionnalités introduites par Java 5, en particulier dans l'utilisation des imports statiques et des énumérations.
Quant aux spécificités de Java 7 côté langage, il était trop tôt pour pouvoir évoquer leur utilisation (on peut penser aux properties, closures, self types notamment).

Par la suite, le speaker a expliqué la réflexion qui a donné lieu à la hiérarchie de classe fixant le contenu de la JSR : il a notamment expliqué les différentes visions possibles de ce qu'on appelle le temps, à savoir un instant qu'on mesure de manière absolue (Instant) et une délimitation entre 2 instants (InstantInterval), ou encore une durée (Duration). Sans oublier la vision plus humaine qui se base sur les notions de date et d'heure ainsi que de zone de temps, avec les normalisations (ISO-8601) qui en découlent.
Le résultat de cette réflexion donnant lieu par exemple aux classes LocalDate, LocalTime, ZoneOffset, ainsi que toutes les combinaisons résultantes.
Il a par la suite illustré la construction de tels objets comme le montre le code suivant :

LocalDate date = calendarBuilder().year(2007).december().day(3).build();

Stephen Colebourne a ensuite présenté les classes DateResolver et DateResolvers qui permettent la validation de dates ou l'application de stratégie particulières en cas de date invalide (par exemple prendre la dernière date valide qui précède).
Il a ensuite explicité les problèmes de "TimeZone" et présenté les classes TimeZone et ZoneOffset qui se partagent ces responsabilités.

En résumé, les différentes interfaces introduites par la JSR 310 nous ont été présentées, illustrant à la fois les implémentations et la manière dont l'existant s'y intègre (java.util.Date implémentant par exemple l'interface ReadableInstant).
Il nous a également parlé de java.sql.Date et des composantes JDBC et XML de la JSR.
Enfin, en dehors des parties concernant le formatage et le parsing (qui devraient se baser sur Joda-Time), parmi les choses peut-être un peu plus isolées, sachez que la notion de date/heure courante devrait être rendu possible avec la classe Now.

Les slides de la présentationLes slides de la présentation

Encore une session par le couple inséparable Bloch/Gafter, ou plutôt les Click & Hack Brothers.
Vous n'avez jamais entendu parlé des Java Puzzlers ? Et bien sachez tout simplement qu'il existe un recueil de ces puzzles que proposent Bloch et Gafter régulièrement en conférences.

Nous avons eu droit à 10 puzzles inédits traitant de l'opérateur ternaire, des JUnit, ou encore de l'initialisation/chargement d'une classe.
Parfois tirés par les cheveux, tous ces exemples sont détectés par l'outil FindBugs et permettent parfois de mettre en évidence des défauts du langage ou de l'API.

Dans cette présentation, Dion Almaer, un speaker plein d'entrain, nous a présenté Google Gears et son futur.
Google Gears est composé de trois parties : un serveur local, une base de données, une API WorkerPool.
Le serveur local agit comme un proxy cache qui comprend les réponses 200 (OK) et 304 (Not Modified).
La base de données est SQLite pour laquelle ils ont contribué la recherche full text.
Le WorkerPool de son coté est une API permettant de simuler le multithread en javascript.

Il a ensuite présenté les améliorations à venir pour Google Gears. Parmi ces évolutions, on trouve un mapping ORM avec GearsORM, des outils pour migrer la base de données (GearsShift) et pouvoir la gérer (Gears In Motion), une API pour des raccourcis bureau vers vos applications offline (Desktop API), une API vers du code Natif (Channel API), une version Offline de Dojo et une intégration GWT et Gears. Une chose intéressante aussi est GearsMonkey, sur la base de GreaseMonkey pour ajouter des boutons permettant de rendre offline n'importe quel site.

Si je trouve tout cela intéressant pour l'avenir du web, certaines choses m'inquiètent concernant la sécurité des applications. Par exemple le fait de pouvoir exécuter du code natif depuis javascript va sûrement donner des idées aux pirates. De même lors de la présentation, Dion Almaer nous a montré que les bases SQLite sont directement accessibles sur le poste client et ne sont pas codées par défaut (il semble qu'il y ai une possibilité). Cela risque de poser problème de confidentialité dans le cas d'utilisation depuis des postes partagés (université, cybercafé...).

Les slides de la présentationLes slides de la présentation

Un BOF qui fût l'occasion de rencontrer les différents JUGs leaders, en particulier ceux du ParisJUG et un JUG inédit : celui des femmes.
Parmi les échanges qu'il y a eu, les discussions se sont focalisées sur la gestion d'un JUG : de la création, sponsoring, organisation d'événements, à la gestion d'une popularité comme celle du BeJUG qui organise JavaPolis.

Ce BOF de fin de soirée fût l'occasion pour Neal Gafter et Joshua Bloch de sonder l'adhésion de l'assistance à différentes propositions d'évolutions du langage.
Pour faire court, il s'agit des discussions que nous avons relayé quelques jours plus tard sur les forums : renseignez vous.

Qui n'a pas entendu parler de Wicket ?
Comment ça ? Vous ne lisez pas le blog de Joseph Pachod ?
Sachez donc que beaucoup regrettent que Wicket ne soit pas aujourd'hui à la place de JSF, et vont jusqu'à le qualifier de meilleur framework Web Java.

L'objectif de la session présentée par Martijn Dashorst était de nous montrer à quel point il était facile de créer une application avec Wicket en partant de pages statiques (pour ne pas dire maquettes).
Il a commencé par un bref historique montrant que Wicket n'était pas le dernier framework à la mode mais bien un framework stable et mature.
Pour illustrer ce fait, il nous a montré les statistiques de téléchargement et de fréquentation (Wicket est en tête au classement des frameworks Web, au classement des projets Apache, et troisième au classement Java derrière Java.net et NetBeans.org ... excusez du peu).

Le speaker est revenu rapidement sur les concepts de Wicket, notamment l'incontournable attribut wicket:id, nous montrant par exemple à quel point la partie présentation pouvait être simple à manipuler.
Pour ceux qui seraient surpris au premier contact, sachez que les pages .html de présentation se doivent d'être dans un paquetage Java au même niveau que la classe Java faisant office de contrôleur.
Enfin, il nous a présenté sommairement la gestion de composants et la notion de Model.

Une grande partie de la session était destinée à illustrer Wicket par la construction d'une application. Cela n'a pas été très concluant dans la mesure où le speaker a fait quelques erreurs d'inattention (les joies des démos), mais on peut néanmoins en retenir la manière dont on peut progressivement construire une application Wicket.

Les slides de la présentationLes slides de la présentation

Unitils est un framework de test présenté ici par Filip Neven, l'un des 2 créateurs.
L'objectif de ce framework est de simplifier l'écriture de tests qui supporte JUnit (3 et 4), TestNG, DBUnit et EasyMock.

L'utilisation de ce framework se base sur un pré requis assez important : chaque développeur dispose de sa base de données, ceci afin de pouvoir développer et tester sans risquer des dommages collatéraux.

Unitils introduit différents concepts, à commencer par le @DataSet (ou son équivalent @ExceptedDataSet) qui permet de référencer une définition XML de données qui doit être utilisée pour remplir la base de données dans le cadre d'un test (portée de niveau classe ou méthode).
Il se repose donc sur DBUtils et se propose de prendre en charge certaines contraintes de ce framework.

Unitils prend également en charge les notions de transaction (et pourrait se rapprocher sur Spring Test Framework à cet effet) et propose une intégration de Hibernate (injection d'une SessionFactory par exemple).
A ce sujet, il propose d'ailleurs une méthode permettant de vérifier la cohérence entre le mapping Hibernate et la structure de tables (cf. HibernateUnitils).

Au delà de toutes les fonctionnalités orientées assert et de l'intégration avec Spring (injection de Spring Beans), Unitils a également une valeur ajoutée du côté de la mise à jour de la base de données.
En effet, si chaque développeur possède sa base de données, cela multiplie les opérations de maintenance de la structure de tables. Par conséquent, un utilitaire "DBMaintainer" est lancé avant et après chaque test, permettant de passer des scripts incrémentaux qui seraient apparus depuis la précédente exécution (mémorisation du numéro du dernier incrément en base de données).
Ainsi, en cas de modification d'un script incrémental déjà existant, l'utilitaire recrée la structure de table du début en passant le script initial puis tous les scripts incrémentaux. Ce processus n'étant bien sur rendu possible que par la gestion des scripts sous SCM avec normalisation du répertoire et des noms de fichiers.

Les slides de la présentationLes slides de la présentation

TDD ou Test Driven Development est une de ces expressions à la mode comme extreme programming et SOA...
La conférence de Lasse Koskela était découpée en deux parties : une présentation très courte du concept puis une mise en pratique.

TDD c'est un cycle de développement en trois temps :

1. écriture d'un test qui échoue, ce test doit être un test de comportement et pas un test de classe ou méthode (on ignore l'implémentation)
2. faire que le test passe, sans se soucier de l'implémentation, même une valeur codée en dur est correcte, de toute façon on corrigera au cycle suivant. Le plus important est le temps.
3. rendre le code joli : refactoring, c'est à ce moment que se découpent les classes et méthodes

L'approche de développement est alors appelée Outside-in (du comportement au design) par opposition aux méthodes classiques inside out (du design vers le comportement).

Il a ensuite abordé le prozac du développeur TDD : les Test Doubles avec :

• les stubs qui retournent des valeurs codées en dur
• les fakes qui permettent aux tests de fonctionner plus vite (comme des substituts de base de données en mémoire)
• les mocks qui sont capables de dire si les interactions attendues sont arrivées

La seconde partie de la conférence a alors été une démonstration live de TDD. Il a d'abord demandé un sujet dans la foule puis a commencé l'implémentation d'un système de score de Volley Ball en appliquant TDD.

Les slides de la présentationLes slides de la présentation

Cette année encore, l'équipe de BeJUG a montré une organisation parfaite. J'ai plus apprécié cette édition de Javapolis qui était la deuxième pour moi, sans doute du fait que je connaissais plus de monde. Si les conférences sont souvent intéressantes (même si je me suis fait avoir avec celle sur JSF et celle sur Guice) je trouve que les discussions de couloir, suite à une conférence ou pas, permettent d'échanger et apportent un éclairage différent sur les technologies ou outils pour leur aspects moins "commerciales".

Les deux points qui ont marqué cette édition pour moi :

• la présence de nombreux Spec Leaders pour les présentations qui contribue à la qualité des conférences mais surtout montrait que Java EE 6 se prépare intensément
• la volonté de retour de la part de la communauté avec notamment les présentations de Neal Gafter et Joshua Bloch et toutes les invitations à nous exprimer sur les futures évolutions de la plateforme. On voit bien que, suite à son passage en Open Source l'évolution de Java est aux mains de la communauté

Mon premier JavaPolis, et l'occasion de rencontrer des membres de la rédaction de Developpez.com (Christophe que j'avais déjà rencontré, Vincent Brabant, et Gildas), mais également des professionnels aguerris et passionnés (je pense notamment à Alexandre Snaps, Gaël Blondelle) ainsi que des speakers très disponibles.

Le lieu est vraiment atypique et rend cette conférence unique, sans compter la présence de "stars" internationales tels James Gosling, Bruce Eckel, Erich Gamma (et j'en oublie volontairement) et de nombreux professionnels impliqués dans la communauté (Christophe évoque les specs lead, je rajouterai les membres des JSR tels Antonio Goncalves et Xavier Hanin, ainsi que des leaders de projets Open Source).

Il est très difficile de se faire son programme sans regretter de ne pouvoir assister à l'une ou l'autre session, mais c'est sans compter la mise à disposition progressive des vidéos sur Parleys ! On peut donc se permettre des écarts et parfois faire l'impasse pour profiter de l'événement, d'autant plus qu'on est largement gagnant par rapport au prix de la conférence.

Je n'ai vraiment pas été déçu par cette édition, et je me demande bien comment je ferais pour opter pour telle ou telle conférence dans les années qui viennent, tellement il y en a qui s'avèrent intéressantes.

Ce fût la première édition de Javapolis pour ma part, mais sûrement pas la dernière. Malgré mon anglais trop peu souvent utilisé, j'ai pu suivre les conférences assez aisément.
Le Metropolis est assez simple d'accès, et le parking suffisamment grand pour ne pas se soucier de trouver une place.

Au niveau des conférences les plus importantes, je n'ai pas été déçu par celles de 4h, mais j'ai été moins conquis par les mini conférences de 30 minutes auxquelles j'ai assisté.
Mais Javapolis est aussi une occasion de rencontrer diverses personnes. J'ai ainsi pu faire la connaissance de Eric et Christophe, mais aussi de l'équipe JavaBlackBelt, de Peter Meijer ( Spring Source ).

Vivement l'année prochaine !