Deuxième journée de la réunion annuelle des Java-holic européens. Le programme est chargé :

• Total cost of ownership
• Unleash your processor(s)
• What’s new in hibernate
• iPhone/Ipad development from Java perspective
• Harnessing the power of HTML5 Web Sockets to create scalable real-time applications
• GPars: Parallel programming concepts for the JVM in Groovy
• Cloud Computing with Scala and GridGain
• How Java powers large online retail sites

Suivez le guide …

Total cost of ownership

La keynote de la seconde journée est tenue par Ken Schwaber, le co-fondateur de Scrum. Il revient sur les bénéfices à tirer de Scrum. Le message n’est pas très neuf pour la communauté des agilistes mais il est toujours bon de se rappeler pourquoi nous essayons de changer les façons de faire. Dans un style très posé, il nous expose quelques axes pour inviter les spectateurs à s’améliorer.

• Les gens ne sont pas des ressources
• Il est important de définir la notion de tâche « terminé » pour chaque projet (Definition of Done)

Si votre définition de Done laisse de côté des points importants comme l’écriture de tests ou l’intégration aux autres composants, l’équipe accumule rapidement une grande quantité de tâches non réellement finies. Cette dette devra être prise en compte en mettant en place des sprints dédiés à la stabilisation. Cette solution est bien souvent beaucoup plus coûteuse que de correctement définir et de respecter la definition of done au fil des développements.

Il annonce également le lancement d’une formation de 5 jours spécialement adaptée aux développeurs destinés à travailler en équipe Scrum : Professional Scrum Developper Program.

Unleash your processor(s)

Václav Pech nous fait ensuite une présentation sur différents patterns de programmation concurrente. Selon lui, pratiquement aucune application ne profite des architectures multicore et celles qui en profitent ne le font que par hasard.
Václav présente ensuite un ensemble de patterns notamment :

• Parallel Arrays qui permet d’effectuer des opérations comme du filtrage ou du calcul sur des éléments stockés dans une collection en parallèle. Tout ce qu’il y a à faire, c’est de définir les opérations qui seront appliquées à la collection. Ceci de facon simple sans manipuler de thread, ni gérer de moniteur transactionnel.

//create a thread pool and store the collection in a Parallel Array
final ForkJoinPool pool = new ForkJoinPool(2);
final ParallelArray people = ParallelArray.createFromCopy(friends, pool);
//Create a predicate for filtering
final Ops.Predicate aWoman = new Ops.Predicate() {
   public boolean op(final Person friend) {
      return !friend.isMale();
   }
};
//Create an operation to retrieve the name from an element
final Ops.Op retrieveName = new Ops.Op() {
   public Object op(final Person friend) {
      return friend.getName();
   }
};
//Perform filtering and mapping concurrently on all elements of the collection
final ParallelArray namesOfWomen =
   people.withFilter(aWoman).withMapping(retrieveName).all();
System.out.println("namesOfWomen = " + namesOfWomen);

• Fork and join A partir du JDK 7, une nouvelle API du package java.util.concurrency va permettre de définir des tâches et de gérer leur exécution. Le principe de base est de diviser les données à traiter en petites unités de travail et de traiter ces unités en parallèle. Les résultats obtenus en retour seront ensuite agrégés.

Václav présente ensuite d’autres patterns tels que le dataflow concurrency, les actors, les agents, le principe de Shared Mutable State et de Persistent data structures. Ces patterns seront présentés plus en détail dans un futur article dédié à la programmation concurrente.

What’s new in hibernate

Emmanuel Bernard présente les principales évolutions intégrées dans la dernière version d’Hibernate. Le but principal de la version 3.5 était d’implémenter la spécification JPA2. Il revient sur quelques fonctionnalités de la spécification. Notamment :

• Packaging

Hibernate Annotations et Hibernate Entity Manager sont maintenant dans le même projet que Hibernate Core. Les releases sont maintenant toutes synchronisées, ce qui met fin à la complexe matrice de compatibilité. Les releases du projet d’audit et de gestion de version Envers seront également synchronisées avec le core.

• Application de formule

Il est désormais possible d’appliquer des fonctions avant la lecture ou l’écriture dans une colonne par la base de données. Un des cas possibles peut être l’utilisation des fonctions d’encryption native d’un SGBD.

<property name="password">
   <column name="PASSWORD" not-null="true"
      write="encrypt(?)"
      read="decrypt(PASSWORD)"/>
</property>

• Fetch profile

Pour éviter de générer un trop grand nombre de requêtes, il est possible de charger un arbre d’entités lors du chargement par clé primaire. On paramètre alors dans le fichier de mapping la stratégie de chargement.

<hibernate-mapping>
   <class name="Client">
      <set name="factures" inverse="true" fetch="join">
         <key column="client_id"/>
         <one-to-many class="Facture"/>
      </set>
   </class>
</hibernate-mapping>

La stratégie sera statique et appliquée que l’on charge les entités par la méthode get, les Criteria ou le chargement implicite durant la navigation à travers une association. Une des solutions était de créer un ensemble de méthodes, du type loadCustomer, loadCustomerWithAddress, loadCustomerWithOrders, et d’utiliser une requête HQL pour dynamiquement appliquer une stratégie de chargement (en HQL : inner join fetch). Mais ceci ne permet pas de définir des stratégies dynamiques pour les chargements implicites.

Hibernate propose maintenant une manière plus simple de gérer les stratégies de chargements. On peut désormais définir dans le fichier de mapping plusieurs stratégies pour une association.

<hibernate-mapping>
   <class name="Client">
      ...
      <fetch-profile name="clientAvecFacture">
         <fetch association="factures" style="join"/>
      </fetch-profile>
   </class>
</hibernate-mapping>

et définir la stratégie à utiliser pour chacune des sessions avec la méthode suivante :

Session session = ...;
session.enableFetchProfile( "clientAvecFacture" );
Client client = (Client) session.get( Client.class, clientId );

iPhone/iPad dev from Java perspective

Ognen Ivanovski, de la société Netcetera, nous présente son retour d’expérience sur les développements pour l’iPhone (et donc pour l’iPad). Étant développeur Java à la base, il nous expose les écueils auxquels risquent de se heurter les développeurs Java en arrivant sur cette plateforme, ainsi que les points importants à garder en tête pour le design.

N’espérez donc pas voir apparaitre une méthode magique pour développer en Java pour l’iPhone. Comme Ognen l’a rappelé, Apple n’autorise dans AppStore que les applications rédigées en Objective-C. Il commence par un petit rappel sur l’environnement de développement sanctifié par Apple, à savoir : XCode, Interface Builder, iPhone Simulator et Instruments (pour le profiling).

Voici, d’après lui, les facteurs clés à garder en tête lors d’un développement pour cette plateforme :

• Le hardware est limité, en mémoire comme en CPU : Cependant la performance est cruciale. Il faut donc designer ses applications pour la vitesse et les tester sur de vrais appareils. L’émulateur fourni dans le kit de développement ne rend pas compte des performances réelles. Pensez donc à gérer votre mémoire: ici, pas de Garbage Collector. Et si par hasard le SDK ne vous fourni pas ce que vous voulez, vous pouvez toujours embarquer des librairies en C pur.
• La résolution est différente : Là encore, un test sur un device réel ne saurait être remplacé par un test sur l’émulateur, des changements subtils peuvent impacter fortement l’effet obtenu, à cause de la taille et de la résolution de l’écran.
• Le mode d’utilisation change : En développement web on suppose l’utilisateur assis avec clavier, souris, etc. Mais en mobile, il sera plutôt en déplacement, ou dans un canapé avec l’iPad. Ceci doit être pris en compte dans le design. L’interface multitouch, la taille des doigts, etc., tous ces paramètres doivent être exploités intelligemment.
• Les barrières posées par Apple : Le iPhone Developer License Agreement est fluctuant et contraignant. Il existe une constante inquiétude de la censure quand on développe. La médaille de ce revers est que, si votre application passe la censure, les utilisateurs feront confiance à l’AppStore et n’auront aucune réticence à l’installer sur leur iPhone/iPad.
• Chaque application est partie intégrante de l’appareil : D’après les retours d ‘Apple, les utilisateurs d’iPhones ne se servent que marginalement de la fonction de recherche. Ils trouvent une application qui leur récolte et présente les données d’un domaine particulier. Il faut donc penser une application comme partie intégrante du device physique et travailler au mieux son intégration.

Il enchaîne sur un rapide exposé des API disponibles, puis met en garde son auditoire sur les méfaits du hype. En effet, le positionnement marketing peut amener à se lancer dans un développement iPhone mais il faut faire les choses bien. Une application médiocre, même si elle offre une visibilité sur l’AppStore, sera mal notée par les utilisateurs et occasionnera donc une perte d’image.

Une présentation avec très peu de technique mais qui donne une bonne idée des contraintes à considérer pour ne pas perdre son temps lors d’un premier développement.

Harnessing the power of HTML5 Web Sockets to create scalable real-time applications

Peter Lubbers, de chez Kaazing Corporation, nous présente les avantages à tirer d’une communication full-duplex entre navigateurs et serveurs web. Il commence par rappeler les besoins de réactivité des pages web et les problèmes des solutions actuelles :

• polling : Basé sur des requêtes AJAX périodiques pour récupérer les données. Le martelage du serveur par des requêtes AJAX en provenance de tous les clients connectés pose des problèmes de charge et d’occupation de la bande passante (chaque requête arrive avec ses headers HTTP). De plus cette solution ne fait que fournir du presque temps réel et scale très mal.
• long polling : Technique des architectures Comet. Cela permet d’éviter de marteler le réseau pendant les périodes où il n’y a pas de données à fournir, mais dès que le flux est continu, la fréquence des polling augmente et revient au même que le polling classique.
• streaming : fonctionne bien mais la conservation d’une connexion ouverte trop longtemps peut poser des problèmes avec les proxies et firewall sur la route.

Peter enchaîne sur une démonstration de Comet et de son occupation du réseau en capturant les trames réseau avec WireShark, et nous présente enfin la solution d’avenir : les WebSockets de HTML5.

Nous avions parlé il y a quelques temps des API Javascripts qui y sont liées. Un autre point mis en avant est qu’une fois établi, les communications passant par une WebSocket se passent de header HTTP (871 octet en moyenne) et sont remplacées par 2 octets qui encadrent chaque message, diminuant d’autant l’occupation de la bande passante.

Il détaille un peu l’aspect sécurité de la chose, les WebSockets sont également disponibles en version sécurisé, basé sur TLS (comme HTTPS) et s’établissent simplement par une poignée de main (Handshaking) sur HTTP. Actuellement les WebSockets du coté browser ne sont supportés que par Chrome 4.0+, et les nightly builds de WebKit. Opera et Firefox promettent de le supporter bientôt.

Il termine par la démonstration d’une application de Poker, avec WebSockets liés à un Kaazing Gateway et nous montre les trames réseau.

On peut regretter tout de même que Peter ne fasse aucun autre commentaire sur la partie serveur que d’évoquer le Kaazing WebSockets Gateway. A aucun moment la spécification Servlet 3.0, ni GlassFish, ni Jetty, ne sont évoqués.

GPars: Parallel programming concepts for the JVM in Groovy

Dans une session presque purement technique, Dierk König nous présente la librairie GPars, destinée à apporter la facilité à la gestion de la concurrence dans Groovy. Il commence par un rappel reprenant les concepts déjà exposés par Václav Pech dans sa session du matin, puis enchaîne sur une session de live coding pour démontrer la simplicité d’usage de la librairie.

Parmi les exemples codés devant nos yeux ébahis, on trouve notamment :

• la parallélisation d’opérations sur des collections
• les opérations asynchrones avec pool de thread
• les Actors inspiré de Scala
• les Agents inspirés de Clojure, destinés à protéger des ressources non thread-safe

Il est pratiquement impossible de coucher un live-coding dans un article, mais la vidéo devrait sortir en même temps que les autres tournées dans la salle 5 de Jazoon. Vous les retrouverez dans la revue de presse, dès leur sortie.

A noter qu’un problème avec son IDE favori l’a forcé à utiliser uniquement la Groovy Console, exercice mené donc sans filet, et avec brio.

Cloud Computing with Scala and GridGain

Nikita Ivanov, de chez GridGain Technologies, vient nous exposer les travaux de sa société autour de Scala. Il commence par nous rappeler le contexte en revenant de façon synthétique sur certaines définitions :

• Grid : 2 ordinateurs ou plus fonctionnant en parallèle sur des parties distinctes d’une tâche commune
• Grid Computing : Grid de calcul et data Grid fonctionnant de concert
• Cloud : Virtualisation de Data Center
• Cloud Computing : Cloud et Grid Computing

GridGain Technologies a choisi d’adopter un langage plus simple pour exploiter leur architecture de Cloud Computing. Nikita nous explique que Groovy a été écarté à cause de ses performances, que JRuby a été écarté pour des problèmes d’intégrations et que Scala remplissait tous les critères de choix de GridGain :

• Scalable
• Post fonctionnel
• Performances égales à Java
• Statiquement typé
• Pleinement compatible Java

Ils ont donc développé un DSL nommé ScalaR, qui permet de créer des programmes à lancer dans un Cloud GridGain en quelques lignes. S’en suit une nouvelle session de live coding, comparant l’approche traditionnelle de l’API GridGain, et l’utilisation de ScalaR. On devine assez bien quelle version a remporté la manche. DSL intéressant, dommage que le manque de temps a forcé Nikita à écourter un peu la démonstration.

How Java powers large online retail sites

Notre journée se conclut par une présentation de Robert Brazile, CTO chez ATG, qui rend hommage à l’apport des technologies Java au monde du commerce en ligne. Il revient sur la place grandissante de la vente sur internet dans l’ensemble des ventes sur le territoire américain, puis nous expose les problématiques générales des sociétés de vente :

• haute disponibilité : les sites de vente en ligne doivent rester disponibles malgré les pics d’affluence. Les travaux sur le load balancing ont beaucoup apporté.
• la vitesse avant tout : bien plus que le design graphique, c’est la performance d’une application qui est cruciale. Un peu trop d’attente, trop de clic à faire, et la vente est perdu.
• la couche de présentation séparée : pour pouvoir déléguer les manipulations de présentation et de gestion des backend à des équipes séparées. Cela évite que les développeurs soient pris par des tâches « subalternes » alors qu’ils doivent réfléchir à des problèmes complexes comme la charge ou la récupération des données.
• éviter de payer l’infrastructure nécessaire aux pics de charge pendant les creux : grâce aux avancées dans le Cloud computing, les vendeurs en ligne ont pu faire beaucoup d’économies.

Robert a multiplié les anecdotes sur les ratés de l’automatisation, comme ce moteur de recherche qui a mal réglé son moteur de suggestion :

search for : abortion => Did you mean adoption ?
(trad. : rechercher : avortement => Vous voulez dire adoption ?)

Son expérience encyclopédique du monde des systèmes d’informations pour les sites de vente en ligne lui a servi à illustrer à quel point le langage Java a permis la percée des techniques de vente en lignes modernes. Il prévoit d’ailleurs que cela continue dans les années à venir avec certains sujets qui animent déjà la communauté Java :

• Virtualisation et Cloud Computing : pour toujours plus de scalabilité
• Bases de données NoSQL : pour un meilleur accès aux données, chaque archi répondant à des besoins spécifiques
• Scripting : PHP, Ruby, Groovy et autres, pour des modifications rapides sur les sites publics
• Frameworks : Rails, Grails, Lift et autres, pour concevoir et déployer rapidement des sites vitrines à faible durée de vie
• Parallélisme et concurence : Pour exploiter de façon efficace les architecture multi-core et le Cloud

Java est mature donc, mais certainement pas proche de la retraite.

Epilogue

Nous avons dû choisir entre les sessions Jazoon Rookie et notre avion. Vous devinez sûrement ce que nous avons décidé . Dans l’ensemble, Jazoon est toujours une conférence très intéressante, les orateurs sont de très bon niveau et très accessibles pour discuter en dehors des présentations.

Un grand merci aux organisateurs et aux orateurs. Nous attendons avec impatience les vidéos.

Premières observations :

• légère baisse d’affluence par rapport à l’année dernière,
• forte présence de JavaFX avec pas moins de six sessions, ainsi que d’OSGi,
• très bonne ambiance et organisation,
• excellents speakers, merci à eux.

Nous allons vous rendre compte des sessions suivantes :

• Java SE and JavaFX: The Road Ahead
• Client / Server 2.0 with Java and Flex
• Frameworks and security : how they kill your security scanning
• Object of value
• Construction techniques for domain specific languages
• Servlet 3.0
• 97 things every programmer should know

Java SE and JavaFX: The Road Ahead

Jazoon 2010 commence par une keynote de Danny Coward sur l’évolution du langage java. Danny revient sur l’évolution de Java depuis le début du langage (Java a 15 ans depuis le 24 mai). Il y a désormais plus de 7 millions de développeurs Java à travers la planète, près d’un milliard de JVM déployées, et plus de 2 milliards de téléphones mobiles avec une JME.

Il nous montre également une vidéo de 1995, avec James Gosling présentant un prototype de PDA avec des interactions proches des smartphones récents, notamment la navigation dans les menus, l’écran tactile, un véritable iPhone préhistorique.

Danny insiste fortement sur l’effort de modularisation de la JVM, illustré par le projet Jigsaw, pour améliorer la taille de la JVM et sa rapidité de démarrage. Il nous parle également de la gestion du parallélisme avec le récent travail sur le garbage collector G1, mais aussi de l’API fork/join et ParallelArray sur laquelle nous reviendrons en détails.

Danny nous parle également du grand nombre de langages qui tournent sur la JVM : près de 200. Il met en lumière le projet Da Vinci Machine, destiné à fournir des optimisations bas niveau aux langages tiers pour obtenir des performances proches de Java sur tous les langages tournant sur la JVM.

Puis viennent toutes les nouveautés du langage attendues prochainement :

• nouvelles annotations,
• amélioration de l’inférence de type pour les Generics (mieux connu sous le nom de ‘diamond operator’)
• possibilité de catcher plusieurs exceptions à la fois,
• supports des chaines de caractères pour les commandes switch/case,
• support des closures à travers le projet Lambda.

Danny consacre également beaucoup de temps pour nous parler de JavaFX. Il a tenu à rappeler que JavaFX est bien vivant, la preuve en est qu’il y a eu 4 releases en 18 mois. Parmi les nouveautés de la version 1.3 on peut noter :

• l’arrivée de nouveaux composants graphiques plus scalables,
• la nouvelle stack graphique nommée Prism,
• des optimisations : il annonce un démarrage 2 à 3 fois plus rapide sur un Java SE 6 update 18,
• JavaFX TV : annoncé comme nouveauté mais déjà présent dans la version 1.2, avec son émulateur de TV.

Et pour finir cette keynote de lancement, il nous fait la démonstration d’une partie du site des JO de Vancouver 2010, écrite avec JavaFX.

Si l’on se replonge dans les sessions de l’année dernière, il est troublant de voir que les sujets abordés dans cette keynote sont exactement les mêmes que ceux abordés par James Gosling et Danny Coward l’an passé, au même endroit (si l’on omet l’omniprésence de JEE6 en 2009). Si nous étions taquins, on pourrait presque dire que cette keynote d’ouverture est un copier / coller de celle de l’année dernière. Et si nous étions vraiment irrévérencieux, nous dirions que depuis un an, Sun / Oracle n’a pas grand chose à annoncer concernant Java.

Client / Server 2.0 with Java and Flex

James Ward nous présente les interactions entre le monde Flex et le monde Java. James revient sur toutes les méthodes de communication, d’une jsp renvoyant du contenu en xml, en passant par les appels SOAP, jusqu’à l’utilisation des annotations fournies dans spring-blazeds.

L’annotation @RemotingDestination permet d’exposer automatiquement un service Java vers le monde Flex en utilisant le protocole AMF.

Il insiste également sur le coût du parsing de chacun des formats. AMF est peu coûteux en CPU et en mémoire comparé au parseur XML. Ce point peut être important dans le cadre de clients Flash sur mobile, ne possédant pas la même puissance de calcul et de mémoire qu’un desktop. Pour conclure, James nous présente Flash sur un téléphone Android.

Frameworks and security : how they kill your security scanning

Christian Hang, de chez Armorize Technologies, nous fait part de son point de vue sur les problèmes d’audit de sécurité posés par l’utilisation des frameworks. Il commence par un rappel assez complet sur la sécurité en général et les méthodes de détection de failles :

• black box testing : simulation d’attaques extérieures
• white box testing : analyse statique de code pour trouver des failles potentielles (ou SCA : Static Code Analysis)
• analyse dynamique : mise en place d’agents ou de moniteurs sur une application en fonctionnement pour tracer les failles

Il expose rapidement les risques de détection de faux positifs et faux négatifs et leurs conséquences avant d’approfondir sur l’analyse statique de code et ses limites. C’est là qu’arrivent les frameworks et le défi lancé aux outils de SCA. En effet, la forte utilisation de fichiers configuration casse la chaine d’invocation que tentent de suivre les outils de SCA. Comme chaque framework possède ses propres normes de configuration, il est très complexe de poser une méthode générique. De plus comme les frameworks sont des librairies tierces, la chaine d’invocation va se perdre au sein d’un jar et oblige à inspecter le framework en lui-même et non l’application seule. Il nous fait la démonstration de son propos avec le déroulement d’une requête dans Struts.

Christian termine en exposant les solutions qu’il entrevoit à ces problèmes, à savoir la génération de code source ‘glue’, basée sur les fichiers de configuration, qui permette aux outils actuels de SCA de continuer à suivre la chaine d’invocation jusqu’au bout. Ce code ‘glue’ serait injecté avant le passage de l’analyse de code et évidemment pas committé sur l’application.

Avec ses propositions, Christian nous ouvre de nouvelles perspectives d’améliorations pour les outils de SCA. Il y a du chemin à faire mais le gain en détection automatique de failles est potentiellement énorme.

Object of value

Première présentation de la journée pour Kevlin Henney. Il revient sur le concept de Value Object en insistant beaucoup sur la différence fondamentale qui existe entre une Valeur et son implémentation.

L’exemple le plus parlant qu’il donne est celui d’un md5 de fichier. Pour être manipulé, nous aurons sûrement tendance à le stocker dans un String, mais fondamentalement, ce n’est pas une quelconque chaîne de caractères, c’est un MD5 qu’on souhaite manipuler. Ce qui devrait se traduire par la création d’un Value Object MD5.

Pour un rappel sur ce concept, vous pouvez vous pencher sur ce blog.

Kevlin Henney nous invite à réfléchir à la meilleure façon de manipuler des Valeurs dans nos programmes et non un énorme assemblage de String et de numériques.

Nous reparlerons prochainement de ses idées sur la question.

Construction techniques for domain specific languages

Neal Ford, de ThoughtWorks, nous parle de l’élaboration de DSL et des outils les plus adaptés à cela. Après un rappel sur les motivations de l’écriture de DSL et la différence fondamentale entre une API et un DSL, il nous livre ses cinq clés pour l’élaboration de DSL :

• langage de programmation
• langage naturel, proche d’un langage oral
• focalisé sur un aspect particulier du domaine
• expressivité limitée
• ne doit pas être Turing-complet

Il tente alors une approche des principes exposés en Java, code à l’appui. De son point de vue, il n’est pas possible de réaliser de vrais DSL en Java pur. Ce qui s’en rapproche le plus est le method chaining, qui consiste à retourner this à la fin de chaque méthode pour pouvoir enchainer les appels. Un bon exemple illustrant ce principe est l’API Criteria d’Hibernate :

List cats = sess.createCriteria(Cat.class)
    .add( Restrictions.like("name", "Fritz%") )
    .add( Restrictions.between("weight", minWeight, maxWeight) )
    .list();

Puis il passe au langage Groovy, qui lui semble bien plus adapté que Java pour ce cas de figure. Certains aspects de Groovy facilitent la tâche :

• le typage dynamique
• les closures
• 2 techniques de classes ouvertes : les Categories, et les MetaClasses

Ce qui amène Neal a parler de EasyB, projet codé en Groovy pour rédiger des spécifications en BDD, de la forme :

given "an invalid zip code", {
  invalidzipcode = "221o1"
}
and "given the zipcodevalidator is initialized", {
  zipvalidate = new ZipCodeValidator()
}
when "validate is invoked with the invalid zip code", {
  value = zipvalidate.validate(invalidzipcode)
}
then "the validator instance should return false", {
  value.shouldBe false
}

EasyB étant basé sur RSpec, un projet BDD pour Ruby, Neal enchaîne naturellement sur les avantages de ce langage pour la rédaction de DSL, à savoir :

• classes ouvertes
• aliasing de méthodes
• polishing, méthodes de nettoyage de code ‘presque’ Ruby en ‘vrai’ Ruby.

Pour information, il est tout à fait possible de réaliser ses DSL en Ruby et de les faire exécuter en Java, grâce à JRuby. Neal nous livre donc son choix pour les DSL : Ruby. Et il termine sa présentation en rappelant les éléments indispensables à conserver en tête lors de la rédaction de DSL :

• c’est un langage de programmation limité à un aspect du domaine.
• construire par composition et non par élaboration : il vaut mieux faire beaucoup d’opérateurs simples qu’on composera en utilisant le DSL.
• démarrer par la fin : il faut poser la syntaxe que l’on souhaite obtenir dès le début et créer le DSL de façon à respecter cette syntaxe.
• évolution, pas révolution : un DSL se construit petit à petit, il ne faut pas espérer penser tous les opérateurs dès le début, les besoins apparaitront à l’usage.

Servlet 3.0

Ravij Mordani présente la spécification Servlet 3.0, introduite dans la plateforme JEE6. Il nous présente les améliorations selon quatre axes qui reflètent le nouveau visage des Servlets.

Facilité de développement

Profite des améliorations de Java 5, comme les annotations.
On peut directement annoter une servlet plutôt que de devoir la configurer dans le fichier web.xml. Le très verbeux

<servlet>
   <servlet-class>com.servlet.HelloWorldServlet</servlet-class>
   <servlet-name>HelloWorld</servlet-name>
</servlet>
<servlet-mapping>
   <servlet-name>HelloWorld</servlet-name>
   <url-pattern>/hello-world</url-pattern>
</servlet-mapping>

devient donc

@WebServlet(urlPatterns="/hello-world")
public class HelloWorldServlet extends HttpServlet

On notera qu’il est toujours obligatoire d’étendre HttpServlet et de fournir une implémentation aux méthodes doGet, doPost, etc.

De la même manière, on peut définir des Filter ou des ContextListener directement par annotations. Le fichier de configuration web.xml devient optionnel, les annotations suffisent. Si toutefois vous le voulez, vous pouvez écrire un fichier web.xml, qui surchargera alors les directives des annotations.

La configuration peut également être faite de façon programmatique, grâce à une nouvelle API, mais uniquement au chargement du contexte.

context.addServlet(String servletName)
context.addServlet(String className)
context.addServlet(Class<?> servletClass)
context.addServlet(Servlet servlet)
...

Pluggabilité

La notion de web-fragment fournit un moyen de partitionner le descripteur de déploiement. On peut directement fournir de la configuration dans un jar, en plaçant un fichier nommé web-fragment.xml dans META-INF. De la même manière on peut intégrer des JSP dans les jars dans le répertoire META-INF/resources/.

La notion de plug-in de container apparait également. Elle est déjà utilisée notamment par les implémentations de référence JSF (Mojora) et JAX-RS (Jersey).

Exécution asynchrone

L’exécution asynchrone de servlet permet de s’affranchir du pattern Thread by request. Les requêtes demandant un traitement long au back-end, telles que des requêtes bases de données couteuses ou les appels à des systèmes externes de type webservice, peuvent désormais être facilement exécutées de manière asynchrone. Cela permet de rendre le thread disponible pour le traitement des autres requêtes.
Cette fonctionnalité est également très utile pour le développement de fonctionnalités poussant des données vers le client. Le thread n’est plus en permanence bloqué pour un client, mais uniquement lors de l’arrivée d’un évènement.
Pour que le mode asynchrone fonctionne, il faut que toute la chaîne de traitement soit effectivement compatible (filtres, servlets…).

Sécurité

Un ensemble d’annotations permet désormais de gérer le contrôle d’accès à une servlet. On peut également obliger l’utilisation d’un protocole sécurisé (HTTPS) pour l’appel à la servlet. Les 4 annotations suivantes : @DenyAll, @PermitAll, @RolesAllowed, @TransportProtected pourront être utilisées sur les méthodes traitant les requêtes dans HttpServlet (doGet, doPost et les autres) ou bien directement sur la classe.

@WebServlet(urlPatterns="/secure/hello-world")
@RolesAllowed("authentified")
@TransportProtected
public class HelloWorldServlet extends HttpServlet

Il est aussi possible d’implémenter directement la méthode d’authentification HttpServletRequest.login(String username, String password);

97 faits que tout programmeur devrait connaître

Pour clore la journée, tout le monde se regroupe dans la salle 5 (la plus grande) pour écouter Kevlin Henney présenter quelques conseils extraits du livre publié par O’Reilly 97 things every programmer should know

Le livre étant très conséquent, il a choisi de se focaliser sur :

• Apprenez à estimer : Learn to estimate
• Ne commentez que ce que le code ne dit pas : Comment only What the code cannot say
• Encaspulez un comportement, pas seulement un état : Encapsulate behavior not just state
• La règle du boyscout : The boy scout rule (Try to leave this world a litte better than you found it…)
• Le test est la rigueur professionnelle du développement logiciel : Testing is the Engineering rigor of software development
• Écrivez des tests accessibles aux autres : Write test for people

Les anecdotes et la verve de Kevlin nous font passer un très bon moment, avant de nous rendre au Jazoon Networking Event, où tous les participants peuvent souffler un peu autour d’un verre, partager leurs impressions sur les différentes sessions de la journée, ou discuter avec les speakers.

Le programme s’annonce chargé et diversifié, choisir entre les conférences en parallèle risque d’être très dur. Voici quelques-uns des sujets principaux :

• JEE6
• RESTful SOA
• OSGi
• Security patterns
• Scala in the cloud
• JavaFX
• Parallel programming with Groovy
• Maven 3.0
• Hibernate from JPA2 perspective

Le tout sera porté par des acteurs J2EE de renommée mondiale : Danny Coward, Ken Schwaber, Dan Allen, Emmanuel Bernard …

Les journées risquent d’être denses et nous espérons y collecter un maximum d’informations que nous vous relayerons ! Nous avons décidé de ne couvrir que les deux premières journées, qui nous ont semblé être les plus attrayantes au niveau du programme.

Vous pourrez vivre Jazoon en direct, mardi et mercredi prochain, en nous suivant sur Twitter.

Xebia France :

Julien Buret :

Aurélien Maury :

Actualité éditeurs / SSII

• StreamBase lie le Complex Event Processing à Twitter
• Atlassian Summit : le présent et l’avenir des outils Atlassian

Le coin de la technique

• Sortie d’Eclipse Galileo
• Des applications Web modulaires avec SpringSource Slices
• Que devient JMX 2 ?

Evènements de notre communauté en France et à l’étranger

• Retour sur la conférence Jazoon

Actualité éditeurs / SSII

StreamBase lie le Complex Event Processing à Twitter

StreamBase est un éditeur qui fournit une solution de Complex Event Processing (CEP) très populaire dans le monde de la finance. Il s’agit d’un middleware capable d’analyser un flux de messages en temps réel pour y reconnaître des évènements complexes.

Dans un communiqué de presse, l’entreprise annonce proposer un connecteur Twitter pour sa solution de CEP. Il devient ainsi possible pour les systèmes d’information du monde de la finance d’analyser les messages Twitter pour en extraire un sentiment global en temps réel pouvant être utilisé dans un système de trading ou d’analyse marketing.

John Davies, directeur technique d’une société américaine spécialisée dans ce type de traitements financiers, analyse cette annonce et avoue qu’après avoir été sceptique quant à cette idée au premier abord, il y voit désormais une opportunité d’améliorer la réactivité des systèmes par rapport à l’utilisation de simples flux Reuteurs apportant l’information plus tardivement.

Ce type d’annonce permet surtout de réaliser le potentiel de la technologie CEP appliquée à l’exploitation de sources diverses provenant de l’intérieur comme de l’extérieur du système d’information de l’entreprise.

Atlassian Summit : le présent et l’avenir des outils Atlassian

Au début du mois de juin s’est déroulé l’Atlassian Summit à San Fransico. Il s’agissait de la première conférence du genre pour l’éditeur et a pu profiter de l’occasion pour présenter toutes ses nouveautés à venir et revenir sur les dernières évolutions de ses produits. L’ensemble des sessions de cette conférence sont maintenant accessibles librement en ligne.

Nous nous attarderons principalement sur le keynote de Mike Cannon-Brookes, CEO et co-fondateur d’Atlassian, qui résume la majorité des éléments à retenir.

Confluence

La version 3.0 de Confluence a été finalisée il y a peu. Elle apporte principalement :

• Ajout d’un macro browser permettant de naviguer facilement parmi les macros disponibles
• Apport de nombreuses extensions de nature « sociale » avec une gestion de réseaux, un microblogging de type Twitter, un espace personnel repensé
• Gain significatif de performance lors de la navigation et de l’édition

Jira et GreenHopper

Jira 4.0 n’est pas encore finalisé, mais est dors et déjà disponible en version beta. Il apporte quelques nouveautés intéressantes :

• Refonte du dashboard de Jira. Il devient largement personnalisable grâce à l’ajout de gadgets à l’image d’iGoogle
• Introduction du Jira Query Language (JQL) permettant de faire des recherches avancées simplement grâce à un système de complétion. Les résultats des requêtes peuvent alors être ajoutés au dashboard
• Le plugin GreenHopper, permettant d’exploiter le moteur de tâches de Jira pour gérer un projet agile (gestion d’itérations, production de burndown charts, …), devient un produit Atlassian. L’éditeur en ayant annoncé l’acquisition lors du Summit.

Open Social

La généralisation de l’utilisation de l’API Open Social au sein des produits Atlassian est probablement ce qui restera le plus marquant. Ainsi la plupart des produits Atlassian proposeront des gadgets Open Social pouvant être intégrés à n’importe quel conteneur Web s’appuyant sur cette technologie.

Concrètement, il est alors possible d’intégrer un gadget Jira au sein de l’interface de Gmail afin de simplifier la saisie d’une nouvelle anomalie suite à la réception d’un mail décrivant un problème. De même, le dashboard de Jira 4.0 devenant un conteneur Open Social, il est possible d’intégrer un gadget indiquant l’état des derniers builds de Bamboo conjointement aux gadgets indiquant l’état des anomalies et tâches Jira actives. Open Social devient ainsi le vecteur d’intégration des produits Atlassian.

Fisheye, Crucible et Eclipse Connector

Fisheye 2.0 et Crucible 2.0 ne sont également pas encore finalisés mais accessibles en beta. Ils apporteront tous deux une meilleure intégration à Jira, une interface utilisateur refondue et une vue permettant de visualiser l’activité des développeurs sur les différents projets.

Atlassian a également publié fin mai la version finale de l’Eclipse Connector, un plugin permettant d’intégrer certaines fonctionnalités des produits Atlassian au sein d’Eclipse :

• Jira est un task repository pour Mylyn, la gestion de tâches s’intègre donc à tous les niveaux dans l’IDE. Il est par exemple possible avec un clic d’ajouter, en pièce jointe de l’anomalie Jira, le context Mylyn et, dans un autre environnement, de le restituer d’un autre clic.
• Une vue est dédiée à Bamboo et permet d’observer et d’interagir avec les builds du serveur d’intégration continue de l’éditeur
• Il devient possible d’effectuer les code reviews Crucible directement depuis Eclipse
• Il est possible de lancer l’affichage de la page Fisheye correspondant à un fichier spécifique par simple clic droit

Ces fonctionnalités étaient déjà disponibles pour IntelliJ, elles le sont maintenant également pour l’IDE Java le plus populaire.

Atlassian continue de se montrer très innovant en apportant un lot intéressant de nouvelles fonctionnalités sur ses produits déjà très populaires. L’acquisition de GreenHopper lui permet quant à elle de se positionner sur le créneau des applications de gestion de projets agiles que Thoughtworks Studios commençait à investir avec Mingle.

Le coin de la technique

Sortie d’Eclipse Galileo

Comme chaque année depuis 2004, fin juin sera marquée par la sortie d’une nouvelle version d’Eclipse IDE.

Après Callisto, Europa et Ganymède, voici venu Galileo (ou Eclipse 3.5).

Difficile de faire un résumé des 24 millions de lignes de codes ni même de la trentaine de projets qui le compose, cependant plusieurs nouvelles fonctionnalités ressortent. A signaler qu’un top 10 de ces nouveautés a d’ailleurs été publié par Ian Bull sur le site d’Eclipse Source (série de 10 billets).

On notera ainsi :

• Compatibilité avec Mac OS X (portage SWT vers Cocoa).
• Memory Analyzer Tool (MAT), un outil d’analyse de heap (consommation, fuite mémoire …).
• Mylyn (gestion de tâches, synchronisation…) qui n’est pas nouveau mais qui devient de plus en plus populaire avec le support entre autre de Jira.
• XText qui permet la création de DSL (auto-complétion, coloration syntaxique …).
• Rich Ajax Platform (RAP) qui permet de déployer son application en tant que WebApp.
• SWT Browser qui gère le pont entre Java et Javascript dans les 2 sens.
• Mylyn WikiText, un éditeur de fichier wiki.
• Plateforme (p2 avec update manager revu, target platform, deploy into self pour tester ses plugins …).

Le téléchargement se passe par ici avec comme d’habitude plusieurs packages disponibles qui vont de la version classique à la version Java, JEE ou RCP sans oublier, pour les non javaistes, les versions C++ et PHP. D’autres packages ciblant le reporting ou la modélisation sont aussi disponibles.

Et bien sûr, rendez-vous est pris l’année prochaine même date (par Chris Aniszczyk) pour la release d’Eclipse 3.6 qui se nommera Helios !

Des applications Web modulaires avec SpringSource Slices

Rob Harrop a présenté une ébauche d’un nouveau projet SpringSource appelé Slices.

Il s’agit d’un framework basé sur dm Server 2.0 et permettant le développement d’applications Web modulaires. Cette modularité est bien sûr offerte par OSGi, ce qui lui en apporte les caractéristiques particulières : gestion de dépendance versionnées et chargement et arrêt des modules à chaud.

Concrètement une application utilisant Slices offrira un module Web host et un ensemble de modules fils appelés slices. Chaque module apporte du code applicatif et un ensemble de ressources Web (CSS, JavaScript, JSP, images). Le framework offre alors une couche d’abstraction aux slices leur permettant de posséder leur propre session et servlet mappings. Il offre également l’infrastructure nécessaire pour rendre les ressources du module host visibles par tous les autres et pour permettre aux modules de se détecter les uns les autres et ainsi d’opérer des altérations visuelles et comportementales en conséquence.

Dans son état actuel, Slices n’offre qu’une infrastructure de base, la version finale devrait apporter en supplément :

• Un framework de composition d’UI. On imagine que celui-ci apportera des tags permettant l’affichage conditionnel en fonction de la présence ou non de certains modules. Cette fonctionnalité est actuellement gérée manuellement par des EL dans l’application d’exemple
• Le support des servlet filters
• Une intégration à Tiles 2
• L’intégration à SpringSource Tool Suite

Slices apportera donc de nouvelles possibilités en apportant la modularité jusqu’à la couche Web. Ainsi, parallèlement à son offre tc Server, résolument orienté vers le marché actuel, SpringSource continue d’innover en apportant des fonctionnalités supplémentaires à son offre modulaire centrée autour de dm Server.

Que devient JMX 2 ?

JMX est une API standard Java permettant le monitoring et le management d’applications, elle est définie par la JSR-3 et étendue par la JSR-160 (Remote JMX). Depuis sa création en 1998, l’API a évoluée au fil des maintenance releases de sa JSR, incrémentant au passage sa version depuis 1.0 jusqu’à 1.4. Au départ disponible sous forme de librairie externe, JMX a finalement été intégré au JDK 5.0 puis mis à jour dans le JDK 6.0, fin 2006, pour s’aligner avec sa dernière version.

La prochaine évolution majeure de JMX est la version 2.0, cette fois-ci définie dans une nouvelle JSR, la JSR-255 (JMX 2.0). Actuellement en statut early draft review, il est dors et déjà possible de se rendre compte des chantiers prévus :

• Des namespaces permettant de préfixer les noms des MBeans afin d’offrir une meilleure scalabilité lors que de très nombreux MBeans sont manipulés.
• Le cascading permettant de fédérer un ensemble de MBeans situés sur des serveurs différents.
• Définition de MBeans standards par annotations (@MBean, @ManagedAttribute et @ManagedOperation) et de leur injecter des ressources telles qu’un MBeanServer ou un ObjectName. Ce principe de définition de MBeans par annotations est calqué sur ce que Spring permet actuellement.
• Un nouveau langage de requête permettant d’accéder facilement à tous les MBeans dont les propriétés se conforment à certains prédicats.

JMX 2.0 était initialement prévue pour être intégrée au prochain JDK, l’API avait fait son apparition au sein de la Javadoc des previews du JDK 7 mais restait absent de sa liste de features. Eamonn McManus a clarifié cette situation en annonçant sur son blog que JMX 2.0 ne serait pas intégré au JDK 7 tel qu’initialement prévu, qu’il n’était pas pour autant annulé mais reporté … au JDK 8. L’officialisation de ce report est une mauvaise nouvelle, car cette nouvelle mouture de JMX serait arrivée à temps pour apporter un renouveau à cette API, qui bien que très puissante, souffre parfois de lourdeurs à l’usage.

Evènements de notre communauté en France et à l’étranger

Retour sur la conférence Jazoon

La semaine dernière se tenait à Zürich la conférence où les Javaistes se rencontrent. Xebia était présent à cette conférence et en a publié des résumés quotidiens :

• Jour 1 : JEE6 et Glassfish v3
• Jour 1 : Groovy
• Jour 1 : Développement mobile
• Jour 1 : Prospective
• Jour 2 : JDK 7
• Jour 2 : DDD et Value Objects
• Jour 2 : Java FX
• Jour 3 : Un arbre est tombé
• Jour 3 : Les secrets des programmeurs Rockstars
• Jour 3 : Hibernate Search

• Trier les résultats par pertinence
• Extraire la quintessence : « le Blog de XEbia » -> « blog xebia »
• Approximation : « xeiba » -> « xebia »
• Recherche phonétique
• Synonymes
• Même famille/racine : « opérer, opération, opérez »

Pertinence

La pertinence est déterminée par le nombre d’occurences trouvées :

• Nombre d’occurences par document pour un mot-clef.
• Nombre d’occurences de nombre de mots-clefs pour un document.

La pertinence dépend aussi des champs dans lesquels on effectue la recherche. On peut « prioriser » certains champs par rapport à d’autres. Par exemple on peut affecter un poids plus important au titre d’un livre qu’à sa description.

Extraire la quintessence

Le moteur de recherche tokenize la « requête » pour découper et récupérer tous les mots, puis il applique des filtres. Il peut notamment mettre tous les mots en minuscules ou retirer les mots trop courants, sans interêt (« le », « un », « de », etc).

Approximation

L’approximation permet de compenser notamment les fautes de frappe.
Une première approche est de mesurer la similarité entre les mots (distance de Levenshtein/d’édition) mais cela est coûteux niveau performance.

L’autre approche est le N-grammes. Cela consiste à découper les mots en morceaux de n caractères puis d’indexer ces morceaux.
Exemple d’utilisation d’un tri-grammes :

• On découpe et indexe "Hibernate" -> [hib, ibe, ber, ern, rna, nat, ate]
• L’utilisateur tape "ybernat" -> [ybe, ber, ern, rna, nat]
• On compare les morceaux en communs : [ber, ern, rna, nat].

Recherche phonétique

Des algorithmes (Soundex, ou plus évolué Metaphone) permettent de calculer des codes phonétiques qui sont stockés dans un index. Mais ce type de recherche n’est pas le plus courant.

Synonymes

La recherche de synonymes se base sur un dictionnaire qui indexe tous les synonymes de chaque mot.
Ce dictionnaire est évidemment propre à chaque domaine métier, chaque application, et c’est pour cela qu’il a une réelle valeur ajoutée car même Google ne peut connaitre votre métier aussi bien que vous.
Pour chaque groupe de synonymes il est conseillé d’avoir un mot de référence, qui sera celui indexé. Ainsi les mots saisis par l’utilisateur sont traduits en mots de référence avant d’être comparés à ceux de l’index.

Même famille

L’approche brutale consiste à indexer toutes les variations d’un mot. Plus subtil, on peut supprimer certains suffixes pour ne garder que la racine.
Il existe ensuite des algorithmes avancés (mais majoritairement pour l’anglais), comme celui de Martin Porter avec son langage Snowball.

En pratique

Si vous voulez savoir comment mettre en pratique ces fonctionnalités avec Hibernate Search, (re)lisez ce hands-on.

Cette conférence était l’occasion de découvrir des extraits d’interviews (audio) qui ont servies à la réalisation du livre, et de percer les secrets de ces grands noms qui trustent conférences et honneurs.

De manière tout à fait arbitraire, Ed Burns a classé ces secrets en deux catégories : les secrets des temps anciens (on pourrait dire millénaires) et les secrets des temps modernes (qui ont particulièrement trait à l’édition logicielle).

Commençons par les secrets des temps anciens :

• Avoir de la fierté mais la tempérer par beaucoup d’humilité : il ne faut pas hésiter à soutenir ses décisions, défendre son avis, mais ne pas oublier que nul n’est omniscient.
• Reconnaître son ignorance : fortement liée à la notion d’humilité énoncée ci dessus.
• Remettre en cause la sagesse conventionnelle : ce n’est pas parce qu’une position est la plus répandue que c’est celle qui va le mieux répondre à votre besoin.
• Collaborer : l’homme est un animal social et il doit savoir s’appuyer sur son entourage.
• Utiliser le collège invisible : liée à la notion de collaboration. Il ne faut jamais hésiter à s’adresser à l’expert d’un sujet donné pour continuer à avancer. La qualité du réseau est essentielle.
• Compter sur la chance / le destin : le succès se battit parfois sur un coup de dé, la bonne idée au bon moment, comme Kohsuke Kawaguchi qui a comblé un vide avec Hudson.

Pour les secrets modernes :

• Être expert de son outillage : celui qui maîtrise ses outils, sait choisir le bon utilitaire pour une tâche donnée, possède un avantage concurrentiel.
• Sentir les tendances : cette notion, qui permet de voir plusieurs coups en avance, est essentielle dans notre secteur de marché en constante mouvance. Par exemple, Max Levchin a été visionnaire en utilisant Rails pour Paypal, ce qui lui a donné beaucoup de flexibilité. A noter que Dave Thomas voit le cloud computing devenir un standard sous dix ans.
• Être motivé (et motivant).
• Savoir imposer son idée : certains excellents frameworks / langages dorment sûrement dans des tiroirs, faute d’avoir convaincu les décideurs. Il faut savoir changer son point de vue et adapter son discours pour convaincre.
• Savoir quand changer de métier (et / ou de mission) : il est normal d’atteindre un seuil de saturation devant un ordinateur. Il est important à ce moment d’être capable de lâcher de la pression pour regagner en sérénité.
• Avoir un plan B en dehors du monde de l’informatique : curieusement, tous les interviewés ont sous le coude un rêve bien loin de l’informatique (Adrian Colyer vise un poste de garde forestier).

Même si elle ne s’écarte pas énormément des sentiers battus, cette présentation nous a séduite par sa forme : il est rare d’entendre un si grand nombre d’acteurs connus de notre écosystème s’exprimer avec autant de recul sur nos professions.
Elle nous a aussi séduit pour une autre raison, plus personnelle : la très grande majorité de ces secrets fait partie du code génétique de Xebia. Et entendre des cadors mettre en avant les valeurs que nous défendons au quotidien est une forme de fierté.

Secrets of the Rockstar Programmers, le livre à l’origine de cette présentation.

Et pour changer, l’opening keynote n’était pas tenue par Sun, mais par Adrian Colyer, CTO de SpringSource. Et le moins que l’on puisse dire, c’est que le changement de ton a été radical.

Par une analogie avec la forêt primaire, A. Colyer a annoncé la chute de Sun, et la très prochaine émergence de nouvelles firmes leader dans le monde JEE (on imagine bien que SpringSource fait partie de ces nouvelles pousses).
Il a expliqué la chute de Sun sous un angle différent de celui du pur rachat financier : selon lui, les acteurs du monde JEE ne veulent plus suivre les recommandations (dogmes) énoncés par Sun, et c’est pour cela que nous voyons apparaitre de nouveaux langages, mais aussi de nouvelles volontés de modulariser la monolithique stack JEE.

Il a ensuite donné sa vision du futur. Sur les langages dynamiques d’abord, et en prenant un fort pari sur l’avenir (comme Neal Ford l’avait fait avec Clojure). Dans les candidats au « java.next » langage, il a cité Erlang, JRuby, Groovy, Clojure, Scala, Jython et Ruby. Il a rapidement éliminé tous ceux qui ne tournent pas sur une JVM (lui aussi pense que la force de Java est sa JVM, un thème récurrent durant ce Jazoon).
Restent donc 4 candidats : deux orientés fortement syntaxe et framework (Groovy et JRuby), et deux orientés gestion de la concurrence (Scala et Clojure). Selon Adrian, le prochain langage star devra, pour bénéficier d’une adoption large et rapide, avoir une syntaxe proche de Java, ce qui élimine rapidement Clojure et Scala. Attention cependant, cela ne signifie pas que ces langages sont plus faibles, mais simplement qu’ils ont moins de chances d’être largement adoptés.
Restent donc Groovy/Grails face à JRuby/Rails.
La deuxième force que devront posséder ces langages est leur capacité à se mélanger avec Java (en ayant des interactions bidirectionnelles), car les millions de programmes Java actuellement en production ne risquent pas de disparaitre du jour au lendemain. Dans ce domaine, Adrian donne l’avantage à Groovy, d’autant plus que Grails interagit avec un framework très largement adopté : Spring.

Le CTO de SpringSource a réussi ensuite une belle pirouette : à ceux qui vont lui reprocher de mettre en avant deux poulains de l’écurie SpringSource (Groovy et Grails), il répond que si ils font partie de sa firme, c’est bien parce qu’il croit qu’ils sont l’avenir… Imparable.

Autre sujet, les frameworks qui vont se développer autour de ces nouveaux langages. Il cite Grails, Rails, Lift (framework pour Scala) et Spring ROO. Ils sont l’avenir, car même si ils demandent de sacrifier un peu de liberté, ils offrent une nette augmentation de productivité (avec notamment la notion de scaffolding).

Sujet suivant, le nécessaire besoin de modularité dans la pile JEE. Avec OSGI bien sûr, mais surtout avec le seul serveur d’application qui expose OSGI à ses utilisateurs, à savoir le produit maison dmServer et sa notion de service BluePrint.

Enfin, et c’est une vision qu’on voyait clairement se dessiner depuis quelques mois, Adrian Colyer prévoit un changement de paradigme pour les techniciens que nous sommes : à l’avenir, il ne sera plus question de se concentrer uniquement sur la phase de développement dans le cycle de vie d’une application, mais d’embrasser la totalité de ce cycle, en particulier les phases de déploiement et de supervision (on se souvient des annonces faites lors du rachat de Hyperic). Il a mis en avant la notion de BluePrint de déploiement : un déploiement, c’est une injection de références (l’adresse de la DB), une injection de configuration (la taille du pool de la dataSource) et des considérations transverses (sécurité, …). Bref, cela est très similaire à une configuration SpringCore, et il n’y a donc pas de raison que la stack Spring ne puisse pas s’en occuper !

Bref, les changements interviennent aujourd’hui à de très nombreux niveaux … Et une chose est sûre, le futur arrive, que nous soyons prêt ou pas. Cette vague arrive, et la seule chose importante pour pouvoir la surfer est d’être dans l’eau au moment où elle arrivera. Il est donc important, dans ces temps troublés, d’expérimenter et de prendre du plaisir, avant l’arrivée d’une autre période stable.

Nous retiendrons deux choses de cette keynote : comme tous les speakers qui ont donné ces conférences d’ouverture, Adrian Colyer est un orateur né, et il a une vision très précise du futur qu’il envisage. Deuxième enseignement, pour lui, Sun est à terre et il est temps que de nouveaux acteurs s’avancent pour prendre la place du grand arbre.

• Plus de plate-formes : un prototype de téléviseurs montré à JavaOne, le support (partiel) de Linux et Solaris, et la promesse de voir les téléphones de LG, HTC et Sony arriver bientôt sur le marché public
• Plus de composant UI, tous skinnable à l’aide de CSS
• L’ajout de layouts
• De meilleures performances
• Un meilleur accès et un meilleur usage des données

Etrange top 5 à vrai dire, puisque quelques uns de ses points ne sont que partiellement implémentés.

Mais Sun met en avant son produit, et les démonstrations effectuées par D. Coward restent relativement impressionnantes (table de photos FlickR, arbre fractal en mouvement, et même PacMan !)

Plusieurs conférences permettaient de prolonger l’expérience avec le RIA de Sun. Ainsi, nous avons pu suivre une démonstration mêlant deux des stars de Jazoon, à savoir Glassfish et JavaFX. En effet, le back-end d’administration de Glassfish V3 est exposé en REST et pilotable par les quatre verbes. Il a alors été facile pour Ludovic Champenois de récupérer la configuration de son serveur local pour l’injecter dans les samples de JavaFX 1.2. Ce qui donne un « livre » qui dévoile au fil de ses pages des domaines, des serveurs et des datasources… L’expérience s’arrête là, et il n’est pas (encore) question de créer une console Glassfish en JavaFX.

Autre sujet abordé, celui du casual gaming. C’est ce segment de marché qui pourrait permettre aux mobiles FX, ainsi qu’au Java Store, de décoller. La présentation très succincte a tout de même donné un aperçu des facilités apportées par JavaFX pour le développement des jeux. Etant donné la fragmentation du marché mobile, cela donne un avantage non négligeable à JavaFX. Cette présentation nous a donné envie d’en voir plus, à travers ce blog.

Dernière conférence, deux développeurs discutent à la machine à café de qui est le meilleur entre Android et JavaFX Mobile. Ils se lancent un défi de développer la même application sur 2 terminaux mobiles. Cela vous rappelle quelque chose ? Et pourtant, il s’agit d’une conférence donnée par deux ingénieur de Canoo (les grands esprits se rencontrent dit on…).
L’application JavaFX a profité des fonctionnalités d’échange avec Photoshop pour avoir un design très léché. L’application Android a tiré le meilleur parti de l’application framework et des composants gaphiques « out-of-the-box » (qui n’ont pas d’équivalent chez Sun). Au final, on obtient un match nul en terme de résultat (pas vraiment en terme de courbe d’apprentissage, ni de temps de développement, clairement plus courts sur la plate-forme de Google).
Pour le dernier slide de la conférence, l’assistance a été mise à contribution. Elle devait voter pour l’un des choix suivant :

• 1. JavaFX Mobile va signer l’arrêt de mort d’Android
• 2. Android va signer l’arrêt de mort de JavaFX Mobile
• 3. Les deux technologies vont cohabiter pacifiquement
• 4. Sun (ou une autre firme) va proposer un portage JavaFX sur Android
• 5. Sun va poursuivre Google en justice pour non-respect du contrat de licence

La seconde proposition a remporté très largement l’adhésion de la salle, ce qui prouve que malgré le déploiement médiatique, et les nettes améliorations proposées de version en version, Java FX Mobile peine encore à convaincre.
Pour conclure, on pourra réfléchir à la remarque taquine d’un des membres de l’assistance : « il manque un numéro 6 dans les votes : Apple a déjà gagné la guerre »…

Comme la présentation, commençons par la conclusion. Evitez d’éparpiller la logique métier ou pire d’utiliser des règles de gestion implicites, utilisez notamment les Value Objects pour décrire la logique métier. Cela rend le code plus compréhensible et plus facile à tester.

Dan Bergh Johnsson a pris l’exemple d’un numero de téléphone saisi dans un formulaire et géré en backend sous forme de String. Cette String est passée en paramètre à différents services qui valident le format du numéro avant d’en extraire l’indicatif de la région (+33 pour la France). Voilà une situation courante qui présentent de nombreux défauts :

• La validation est faite dans un service (pas forcément intuitif) et a donc peu de chances d’être réutilisée
• Cela conduit souvent à une duplication de code (chaque service redéfinit sa validation) voire pire, la validation est déléguée à des classes « utilitaires »
• On créé des règles métier implicites : derrière le String se cachent de nombreuses règles métier, un format précis, un indicatif, etc

C’est là que les Value Objects viennent à notre secours. Centralisons la « logique métier » dans une classe PhoneNumber (notre ValueObject). Cette classe possède un constructeur prenant un String en paramètre et se charge de la validation du format. Ajoutons une méthode qui extrait l’indicatif du numéro (définition du comportement, de la programmation OO tout simplement) et tout devient plus clair.

Prenons un peu de recul sur notre Value Object, et comparons le avec une validation par Service :

• API : plus besoin de chercher, les méthodes sont définies sur la classe PhoneNumer
• Validation / gestion d’erreur : la validation est faite dans le constructeur, une fois la classe instanciée il n’y a plus de risque de mauvais format
• Compréhension métier : tout est dans une seule classe, intuitive à lire
• Testabilité : les cas à tester sont moins nombreux grâce à la validation faite à la construction

Cette présentation a réussi à aborder le DDD avec pragmatisme, en évitant le baratin habituel sur ce genre de sujets.

• La modularité : introduite par le projet Jigsaw, actuellement au cœur d’une polémique, elle devrait permettre de supprimer les principaux reproches faits aux précédents JDKs, à savoir leur lenteur au démarrage, le plat de spaghettis des dépendances, et l’enfer du classpath.
• La JVM polyglotte : capable d’exécuter de nombreux langages (la voie a été ouverte par JRuby), elle devrait faciliter l’émergence des langages dynamiques. C’est le projet DaVinci.
• Les ajouts au langage : ils sont listés dans le projet Coin. Danny a listé les switch sur les String, la gestion d’exceptions multiples, une meilleure inférence de type, et l’opérateur Elvis
• Plus d’APIs I/O : le Path remplace le File, manipulation des Directory, recherche en utilisant des FileVisitor, opérations asynchrones. On peut se demander si ce genre de fonctionnalités sera vraiment cross-platform (comportement identique ?).
• Nouveau Garbage collector : le fameux G1 (dont nous avons parlé ici) est disponible en preview dans le JSE 6 update 14 en utilisant l’option -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

La final release devrait être disponible (selon la roadmap annoncée) dans le courant du premier trimestre 2010.

On apprécie les efforts continus faits sur la VM mais nous regrettons que les évolutions du langage restent superficielles (c’est bien mais pas suffisant). C’est probablement l’une des raisons de l’émergence des langages dynamiques. Comme si Danny Coward avait voulu légitimer l’opening keynote de James Gosling : « la force de Java ce n’est pas son langage, mais sa VM ».

Nous allons cependant essayer d’en aborder les grandes lignes :

• Prédire le futur est un exercice délicat, car notre cerveau n’est pas correctement armé pour le faire, en particulier au niveau des statistiques. Cependant, dans nos métiers, quelques signes peuvent nous mettre sur la voie : il faut tout d’abord rechercher les « paradigm changers« , ceux qui par leur vision novatrice révolutionnent certains concepts, par exemple l’iPhone. Autre signe, les technologies réchauffées : parce qu’elle n’était pas sorti au bon moment, la VM de pascal n’a pas pris, alors qu’elle était antérieure à la JVM inventée par James Gosling.
• Les sujets sensibles dans les prochaines années devraient être le multi threading, la programmation fonctionnelle et les langages dynamiques. Ce qui fait de Clojure (ie LISP dans une JVM) un bon candidat pour la future technologie star.
• Nos technologies devraient s’appliquer à un nouveau domaine fonctionnel, la robotique. Nous voyons d’ailleurs les prémisses avec le robot garde frontière Corée du Nord / Corée du Sud (qui n’hésite pas à abattre les contrevenants) développé par Samsung. Attention à ne pas basculer dans les visions SF de Matrix, Terminator et autres scénarios catastrophes à base de robots intelligents et autonomes.
• Les tendances récentes le montrent, la syntaxe du langage importe : on ne pense bien que ce que l’on peut formuler. C’est pour cela qui nous vivons une « renaissance des langages », avec l’apparition de nouvelles syntaxes qui collent au besoin. D’ailleurs, il serait ridicule de vouloir se contraindre à n’utiliser qu’un seul langage quand au final tous ces langages sont compilés et exécutés au sein de la JVM sous forme de bytecode. Vive la programmation polyglotte.
• Les réseaux sociaux proposent de nouveaux modes de consommation, et même la plus « stupide » des applications (Ocarina pour iPhone) peut rapporter des millions de dollars si elle propose une expérience sociale originale.
• Si la bataille des RIA fait rage à coup de millions de dollars, c’est pour reproduire le schéma de Microsoft qui a « obligé » tout le monde à coder avec l’API win32 pendant des années. Gagner ce « jeu de plate-formes », c’est imposer ses standards à la concurrence durablement.
• Les téléphones mobiles font aussi, de par leur absence de standard, partie de ce « platform play« . Et à ce petit jeu, Apple, en imposant son terminal, est devenu par la même occasion le premier fournisseur de musique au monde. Et d’ailleurs, si Apple parvenait à facturer tout type de service en utilisant l’AppStore, ne deviendrait-il pas rapidement la plus grande banque mondiale ?

Pour conclure, et comme annoncé en introduction, il est très délicat de prédire le futur. Et même si cela tient plus du lieu commun que de la grande réflexion philosophique, le futur sera ce que les acteurs du monde J2EE décideront d’en faire.

Après Neal Ford, Ivar Jacobson a clôturé la journée en présentant « ce que l’on ne vous dit pas à l’école sur le software » : « be smart« .

Derrière ce titre mystérieux, Ivar nous a livré une présentation agile !

Après un bref rappel des courants de programmation ou modélisation (OO, UML, RUP, CMMI, XP, Scrum…et demain ?), il a comparé une série de situations « pas smart » opposées à leurs solutions « smart ».

Des solutions pleines de bon sens, comme par exemple « pensez grand, mais avancez à petits pas », c’est-à-dire ne développez pas une application complète d’un coup, réalisez d’abord le squelette minimum puis enrichissez-le petit à petit.

Cette « smartitude » doit s’appliquer à tous les niveaux (développeur, équipe, architecture, documentation…), afin de faire de votre développement logiciel un succès (développé rapidement, répondant au besoin, dans des coûts et des délais raisonnables).

Un autre sujet « mobile » était présenté aujourd’hui, à savoir la fragmentation du marché des mobiles. Cette fragmentation intervient à tous les niveaux : hardware, OS, environnement applicatif.

Le chaos est positif, car il amène l’innovation, mais il complique considérablement la tâche des développeurs. Pour réaliser une application fonctionnant sur toutes les plates-formes, plusieurs stratégies se présentent :

• Développer spécifiquement pour chaque appareil : la portabilité et l’expérience utilisateur sont maximales, mais le travail titanesque.
• Développer une application n’utilisant que le plus petit dénominateur commun entre les plates formes, ce qui revient à sacrifier l’expérience utilisateur.
• Utiliser un player, ce qui équivaut à la solution ci dessus (l’expérience utilisateur est limitée par les fonctionnalités du player, elles mêmes limitées par les adhérences entre les différents mobiles).
• Utiliser un framework de portage.

C’est cette dernière solution qui était présentée, par les créateurs du framework J2ME Polish. L’idée sous-jacente est d’écrire son programme en Java, et d’utiliser un framework pour le porter sur la majorité des mobiles. Le code est transcrit par le framework en J2ME en utilisant un repository d’appareils, qui spécifie les caractéristiques de chacun (taille de l’écran, interactions possibles avec l’appareil) …

Il est possible de migrer le code sous Android ou Blackberry (J2ME Polish utilise pour ces deux cibles une reconstruction des classes J2ME spécifique).

Il est même possible de transformer ce code source pour le déployer sur Windows mobile et sur iPhone : le code Java est représenté sous forme d’arbre et un ‘cross-compiler’ est utiliser pour transformer cet arbre en langage cible.

Même si l’exercice est intéressant, il est un peu surfait, notamment parce que l’expérience utilisateur offerte par l’iPhone surclasse tous ces concurrents et qu’il n’est donc raisonnable que de porter une logique business lourde (la conception des IHM étant trop différente selon les mobiles).

A noter que les créateurs du framework apprécient l’initiative JavaFX, mais ne se pencheront réellement dessus que si le marché des terminaux mobiles porte cette nouvelle technologie.

Dierk König (Canoo) a commencé la matinée en présentant « sept patterns d’utilisation de Groovy » sur les projets.
On a bien apprécié la concision du « reader RSS en swing » et le « script ant musical » (en faisant jouer jfugue quelques notes au début et fin du build). Vous pouvez retrouver les 7 points très bien résumés sur le blog du Touilleur Express.
Pour l’anecdote, les extraits de code étaient tapés dans une console Groovy, recopiés caractère par caractère par … un script Groovy ! (la classe, non ?)

Neal Ford (ThoughtWorks) a enchainé avec les « design patterns » dans les langages dynamiques : il a pris quelques patterns du GoF et a montré en quoi les langages dynamiques – comme Ruby ou Groovy – sont plus adaptés pour résoudre les problèmes posés par ces patterns.

Après un salade/saucisse/cornetto (bon appétit) rapidement avalé, ce fut le tour de Gradle. Il s’agit d’un système de build qui élève Ant grâce à la puissance de Groovy. Il se veut plus souple que Maven et apporte les capacités de programmation des scripts Groovy (boucles, conditions, etc).
Dommage que la présentation se soit contentée d’exemples du style « hello world », c’est du coup assez difficile de juger le potentiel de l’outil. Néanmoins, ça a l’air prometteur.

Pour finir avec Groovy, Jetbrains nous a fait une démo très séduisante du support Groovy/Grails sur IntelliJ IDEA. C’est définitivement le (seul) meilleur outil pour coder en Groovy !

Jazoon nous confirme que les langages dynamiques gagnent du terrain, et Groovy est le grand représentant de ces langages dans la sphère Java.

Premier sujet abordé, le futur de Java, à savoir JEE 6 et son implémentation de référence, Glassfish V3.

Dès l’opening keynote (par ailleurs relativement décevant étant donné l’aura qui l’entourait), James Gosling, le papa de Java, plante le décor : pour Java, « we’re we heading », c’est JEE6 (et ses profils) et Glassfish V3, l’implémentation de référence.
On a même droit dès cet opening keynote à une démo des key features de Glassfish 3 (démo qui sera resservie dans la session dédiée au serveur d’application) : configuration des webapp par annotations, déploiement (exploded) à chaud, préservation des sessions, simplicité d’utilisation des EJB 3.1.

D’ailleurs, Roberto Chinnici insistera, dans sa présentation des nouveautés de JEE 6, sur ses JSR « coup de coeur », à savoir Servlet 3.0 (en particulier les Servlets asynchrones), JAX RS (qui abstrait les API HTTP bas niveau et facilite les développements REST), BeanValidation (mieux vaut tard que jamais), EJB 3.1 (et les nombreuses annotations qui vont faciliter leur utilisation : @Singleton, @Asynchronous, @Startup, @Locka …).
Faute de temps, il est passé rapidement sur d’autres JSR qui devraient « révolutionner » les développements : JPA 2.0, scopes JNDI multiples, Web Profile …
Cependant, deux informations que nous attendions ont été évoquées au détour d’une phrase : la JSR 299 (ex Web Beans) serait en cours d’adoption (aucune allusion à la JSR @Inject) et la date de final release de J2EE 6 est toujours septembre 2009.

On n’insistera pas sur une très bonne présentation GlassFish, qui a été malheureusement fortement déflorée par l’opening keynote. On notera cependant le fort accent porté sur la modularité OSGi du serveur d’application de Sun.

Enfin, James Gosling a fait d’autres annonces plus étonnantes : NetBeans serait le meilleur IDE pour développer en Java (ce dont il va falloir nous convaincre, même si la version 6.7 apporte des nouveautés intéressantes), et son intégration au projet Kenaï devrait faciliter le travail collaboratif (notion de developers cloud).
Il a aussi abordé dans le désordre les performances de Java comparées à C/C++ et même Fortran la voiture électrique de Neil Young pilotée par des smart cards Java, les améliorations continues de JSE 6, et enfin la création d’UI avec JavaFX.

Bref, de nombreux sujets dont nous aurons l’occasion de reparler ces deux prochains jours.

RIA

• Vaadin 6
• Adaptateur Gilead pour GAE
• Une série d’annonces chez Adobe

Le coin de la technique

• Scalabilité avec Hibernate et Shards
• Jigsaw vs OSGi
• Pourquoi utiliser un portail ?
• Embarquer le Web dans Java avec JWebPane

Evènements de notre communauté en France et à l’étranger

• Xebia @ Jazoon 09

RIA

Vaadin 6

Au revoir IT Mill Toolkit et bienvenue à Vaadin (vu sur leur blog) !

Pour ceux qui ne le connaissent pas encore, Vaadin (anciennement IT Mill Toolkit) est un framework de développement d’applications RIA qui s’appuie sur GWT. Sa particularité est d’être runtime donc aucune compilation spécifique n’est demandée avant de packager la webapp (à l’inverse de GWT).

Simple changement de nom ? En tout cas très peu de changement côté API selon les auteurs du framework. Il faut plutôt se tourner vers l’outillage pour voir quelques nouveautés : un plugin eclipse (création de projets, de composants UI, de thèmes…) et, inclus dans le plugin, un éditeur WYSIWYG.

Côté liens utiles, l’habituel showcase, le livre et la comparaison maison avec les autres frameworks du marché (et la concurrence est rude dans le monde du RIA).

A noter que Vaadin sera présent à Jazoon pour une conférence sur RIA Security le mardi 23 juin à 15h (slides, projet et autres sur cette page).

Adaptateur Gilead pour GAE

Vous connaissez GWT, Gilead, et Google App Engine ? Et bien il ne reste plus qu’à mélanger tout ça et on obtient le Gilead GWT adapter for Google AppEngine (vu sur le GWT Blog).

Tout démarre d’un thread google groups avec comme point de départ la serialization exception lancée par les entités persistantes transférées vers GWT. Évidemment, la solution qui ressort très rapidement, outre l’utilisation de DTOs, est de passer par Gilead pour transformer nos entités persistantes en POJOs. Il suffit d’ajouter le jar adapter4appengine et de remplacer la classe PersistentRemoteService par EngineRemoteService dans vos remotes services. Dès lors, il sera possible d’envoyer ses entités persistantes vers le client GWT sans exceptions de sérialisation sur GAE.

1.0 M2 téléchargeable à cette url, documentation par ici. Attention toutefois, cette version n’est pas production ready.

Une série d’annonces chez Adobe

Après l’annonce de la sortie de la plateforme Flash il y a quelques semaines, voici une nouvelle série d’annonce de la part d’Adobe.

Pour commencer, deux news relayées par Andrew Twice dans InsideRIA.
La première concerne la sortie d’Adobe Table en version bêta. Cet outil permet de créer des feuilles de calcul, des plannings ou encore des listes de tâches en ligne:

• Les utilisateurs peuvent ajouter des données en même temps: les données sont mises à jour en temps réel pour tout le monde.
• Possibilité de savoir qui travaille sur Adobe Table.
• Création d’écrans communs et privés : les utilisateurs peuvent travailler de manière coopérative, et/ou créer des espaces privés pour ne garder que les informations importantes.
• Filtrage : les utilisateurs peuvent filtrer leurs données en temps réel.
• Tri.

Similaire à Google Document, cet outil a été développé sur la plateforme Flash et va continuer à évoluer. La démo se passe ici, la seule contrainte : avoir un compte Adobe.

La deuxième annonce concerne l’ouverture de la spécification de Real-Time Messaging Protocol (RTMP). Comme nous en avions parlé ici, la spécification a été publiée lundi dernier.

Enfin, Michael Chaize parle de la sortie de LiveCycle Data Services 3 en bêta. Disponible sur le labs d’Abobe, cette nouvelle version propose une meilleure qualité de service pour des applications dont la fiabilité est primordiale telles que les applications bancaires par exemple. Venant compléter la plateforme Flash (avec Flex 4 et Flash Builder 4), Adobe incite la communauté à faire ses retours sur le forum.

Le coin de la technique

Scalabilité avec Hibernate et Shards

Une session de QCon 2008, traitant de la scalabilité d’Hibernate, vient d’être mise en ligne. Présentée par Emmanuel Bernard, project lead d’Hibernate Search, et Max Ross, project lead d’Hibernate Shards, cette présentation offre une approche peu courante sur un problème pourtant récurrent.

Outre les classiques solutions permettant d’éviter certaines pertes de performance avec l’augmentation du volume traité, telles que la bonne gestion du cache, et les optimisations SQL, il a été question d’utiliser Hibernate Search et Hibernate Shards.

Hibernate Search est connu pour sa capacité à simplifier les recherches dans un ensemble d’entités grâce à l’utilisation de Lucene conjointement à la base de données. Emmanuel Bernard proposait ici de déléguer à Search certaines recherches qui s’avèrent très coûteuses à effectuer en base. Lucene étant placé sur une machine séparée, et pouvant même fonctionner en maître / esclave, il est ainsi possible d’obtenir une intéressante répartition de la charge.

Hibernate Shards, bien que plus ancien, est moins répandu du fait qu’aucune version finale n’a encore été produite. Il s’agit d’un module additionnel pour Hibernate permettant à une application de manipuler des données partitionnées sur plusieurs BDD. Le but étant d’encapsuler la conscience du partitionnement des données au sein de la couche Hibernate afin que l’application n’ait pas à gérer cette problématique. Les possibilités du framework sont intéressantes :

• La gestion correcte des Criterias sur des données partitionnées grâce à ShardedCriteria.
• Virtual Shards permettant de faire la distinction entre shard logique et shard physique et ainsi d’augmenter le nombre d’instances de base de données au fur et à mesure de l’augmentation des besoins.
• Generation d’IDs compatibles avec l’utilisation sous-jacente de plusieurs BDDs grâce à l’utilisation d’UUIDs.
• Gestion correcte de BDDs hétérogènes.

Ce sont finalement les fonctionnalités manquantes qui permettent de comprendre pourquoi Shards est toujours en version bêta. Max Ross s’est expliqué il y a plusieurs mois sur les problématiques rencontrées, de manière succincte sur un forum et plus longuement dans une interview. De nombreux défis restent ainsi à relever concernant la gestion correcte des agrégations dans les ShardedQuery et la fourniture d’outils d’aide au partitionnement et repartitionnement des données.
Max Ross est employé par Google et non par JBoss, tout comme les deux autres committers du projet (le code ayant été donné à JBoss par Google), et affirme ne disposer que de 20 % de son temps pour Shards. Ceci n’explique que partiellement le peu de commits sur le projet et ne nous rassure guère quant à sa finalisation prochaine.

Jigsaw vs OSGi

Sept mois après le démarrage du projet Jigsaw, sa légitimité n’est toujours pas reconnue face à OSGi qu’il est venu défier sur son propre terrain.

La semaine dernière JavaPosse diffusait une interview de Mark Reinhold et Alex Buckley, où ils ont pu présenter plus en détail leur vision de Jigsaw :

• Il a été conçu pour modulariser le JDK et est intégré au langage.
• Il ne repose pas sur une spécification car cela n’était pas possible compte tenu du calendrier de JDK 7. Il est donc à considérer comme un « détail d’implémentation » tout comme la gestion du classpath l’était dans les JVMs précédentes.
• Il n’est pas supposé entrer en concurrence avec OSGi, des outils permettant l’intégration entre modules Jigsaw et bundles OSGi étant prévus, mais non prioritaires.

Dans le même temps, Eric Newcomer (Co-Chair, Enterprise Expert Group de l’OSGi Alliance), postait une série de billets très virulents à l’égard du projet Jigsaw, reprochant principalement que Sun n’ait pas voulu se tourner vers OSGi, ne cherchant pas à combler les manques qu’il y trouvait, se tournant immédiatement vers une nouvelle technologie et ignorant donc les 10 années d’expérience acquises par OSGi.

En fait, il semble n’y avoir aucune justification technique permettant d’expliquer l’orientation de Sun vers Jigsaw plutôt que vers OSGi ou vers une évolution d’OSGi intégrée au langage. La véritable raison serait alors à chercher sur le plan politique : la modularisation est un concept important qui manque à Java actuellement et Sun ne pouvait probablement pas se permettre, pour l’ajout d’un tel concept, de s’appuyer sur une spécification émise en dehors du JCP sur lequel il a la gouvernance.

Pourquoi utiliser un portail ?

Le dernier podcast des Cast Codeurs était l’occasion d’une interview de Thomas Heute et Julien Viet sur les portails d’entreprise et sur le partenariat entre eXo et JBoss dont nous vous parlions la semaine dernière.

Les détails liés au partenariat ont déjà été largement couverts par la blogosphère, et c’est surtout le tour d’horizon du concept même de portail que l’on retiendra. Celui-ci reste en effet souvent un élément ambigu au sein de l’écosystème JEE.

Le rôle du portail est d’agréger plusieurs applications au sein d’une unique application Web. Ce besoin technique peut être atteint à plusieurs niveaux de l’architecture de l’application :

• Au niveau back-end, par agrégation de Web Service, se conformant ainsi à l’un des préceptes des SOAs.
• Au niveau applicatif, par l’utilisation d’un portail, ou d’une solution spécifique.
• Au niveau du navigateur Web, par l’utilisation de gadgets, en suivant le principe des Mashups.

En outre, il a également été question des problématiques d’intégration des frameworks Web aux portlets, de complexité éventuelle, et d’adaptation des technologies Web aux portlets. Déterminer si un portail doit être utilisé dans une architecture dépend alors du niveau de tolérance à ces problématiques.

Embarquer le Web dans Java avec JWebPane

Depuis plusieurs années, lorsque l’on veut afficher une page Web au sein d’une application Swing, il faut se tourner vers le composant Browser de la librairie Jdic. Ce composant utilise Embeddable Mozilla, et se présente sous la forme de code natif décliné pour chaque OS et d’un wrapper Java. Outre la nécessité de fournir une version spécifique à chaque OS, ce composant présente également l’inconvénient de mal s’intégrer aux applications Swing du fait de sa nature heavyweight. Pour rappel, un composant est dit heavyweight lorsqu’il est dessiné par l’environnement graphique du système d’exploitation ; à l’opposé il devient lightweight s’il est dessiné par l’application, ce qui est le cas de l’ensemble des composants Swing. Or, faire cohabiter les deux types de composants est délicat car n’étant pas dessinés au même moment, leur superposition est confuse et des chevauchements non contrôlables apparaissent.

Lors de JavaOne, Alexey Ushakov a fait la démonstration du composant JWebPane sur lequel il travaille actuellement et vient de poster des captures d’écrans. Contrairement à Jdic Browser, JWebPane se base sur le moteur WebKit pour effectuer le rendu HTML. Or celui-ci se caractérise par sa nature lightweight s’intégrant agréablement à Swing. La présentation d’Alex Ushakov permet également de constater que son composant est particulièrement riche en possibilité d’interactions et apporte un support pour d’éventuels plugins tels que Flash.

On ne peut qu’apprécier le choix de Sun de créer un composant pour Swing, réutilisable dans JavaFX, plutôt que de privilégier uniquement JavaFX comme cela est souvent le cas depuis son arrivée. L’intégration de JWebPane au JDK 7 est maintenant indispensable pour rendre ce composant réellement exploitable : se basant sur WebKit, il repose donc sur des librairies natives qu’il sera nécessaire de livrer avec les applications Java et seul l’intégration au JDK permettrait de l’éviter. Or, malgré les appels de la communauté, JWebPane reste pour le moment absent de la liste des features du JDK 7 et il est uniquement question d’une mise à disposition sur Java.net.

Le programme s’annonce chargé et diversifié, et l’on espère des annonces un peu plus sexy que celles offertes par les conférenciers de JavaOne. Voici quelques uns des sujets principaux :

• JEE6 : apprendra t-on quand la spécification sera finalisée ?
• RIA : Flex, GWT, JavaFX
• Spring 3.0
• Cloud computing
• Développement mobile, Android
• Langages dynamiques (Groovy / Grails)

Ajoutez à cela de nombreuses présentations transverses touchant au cœur de notre métier :

• Performance / concurrency
• Persistence JPA 2.0, Hibernate
• Intégration continue avec Hudson
• Modularisation OSGi
• Testing / refactoring
• Design (DDD)

Le tout sera porté par des acteurs J2EE de renommée mondiale : James Gosling, Neal Ford, Adrian Colyer, Danny Coward, Kirk Pepperdine, Ivar Jacobson …

Les journées risquent d’être denses et nous espérons y collecter un maximum d’informations que nous vous relayerons !

Vous pourrez vivre Jazoon en direct (du mardi au jeudi) en nous suivant sur Twitter.