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.

Cette formation approfondie de 4 jours vous permettra d’obtenir les compétences nécessaires pour optimiser la performance de vos applications Java. Vous aborderez pendant cette formation tous les aspects de la performance : l’outillage nécessaire, les méthodologies à appliquer, les concepts d’architecture sous jacents à la performance, les meilleures pratiques, le benchmarking et la gestion de mémoire.

A l’issue de cette formation, vous serez en mesure :

• D’identifier rapidement et régler les problèmes de performance de vos applications.
• D’identifier et résoudre des problèmes de fuite mémoire en quelques heures.
• D’isoler des problèmes classiques et d’éviter de s’engager dans des plans d’actions couteux et inefficaces.
• D’identifier des problèmes de performance avant qu’ils ne deviennent critiques pour les applications.

Les stagiaires bénéficieront des Tips de Kirk Pepperdine, référence reconnue dans le monde de l’optimisation de performance objet.
Kirk Pepperdine dispose de 15 ans d’expérience dans les technologies OO et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java.
Vous pouvez consulter le programme complet de cette formation en consultant notre site : http://training.xebia.fr/formation-java-performance-tuning-kirk-pepperdine/.

Actualité éditeurs / SSII

• dm Server 2.0 transféré de SpringSource à Eclipse
• HornetQ 2.0, un véritable renouveau ?
• Nexus sous license GPL: Sonatype explique son choix

Agilité

• Le rôle des leaders dans une équipe agile

RIA

• Le nouveau jQuery est arrivé !
• Survol de la galaxie Flex.

Actualité éditeurs / SSII

dm Server 2.0 transféré de SpringSource à Eclipse

SpringSource annonce cette semaine la finalisation de dm Server 2.0. Il s’agit là d’une mise à jour importante qui agit principalement sur la réduction des nuisances causées au développeur de par la nature même d’OSGi. En effet, si beaucoup peuvent s’accorder sur le fait que la modularité dynamique peut constituer un intérêt sur de nombreux projets, c’est le coût en nuisances et en lourdeurs qui fait que cette solution n’est toujours pas très populaire au sein des applications d’entreprise. L’enjeu est donc crucial puisqu’il s’agit maintenant pour SpringSource de rendre attractif son serveur modulaire pour les entreprises. Un an et demi après le lancement du projet l’évolution de cette version 2.0 sera donc à suivre…

Parallèlement, SpringSource annonce le transfert de dm Server au sein de la fondation Eclipse. Il tiendra alors le rôle d’implémentation de référence de la spécification BluePrint OSGi 4.2 récemment finalisée. Tout comme le travail de simplification apporté à la nouvelle version, la standardisation permettra de rassurer les entreprises sur la pérennité de la technologie proposée par dm Server, qui restait jusqu’alors propriétaire.

HornetQ 2.0, un véritable renouveau ?

Pour mémoire, HornetQ est le nouveau nom de JBoss messaging. En bref, c’est pour le moment un projet Open Source sans support ayant vocation à s’intégrer dans le futur aux produits d’entreprise RedHat. Nous en parlions déjà en aout l’année dernière. La roadmap visait alors clairement la mise à disposition d’une API de messaging RESTful. Malheureusement, il n’y en a même pas l’ombre pour le moment et cela reste dans la roadmap. Gageons que quelques problèmes d’architecture accompagnés de bugs bloquants ont empêché le développement de cette nouvelle fonctionnalité.

L’annonce reprend principalement la précédente et ne liste rien de neuf par rapport à Aout 2009. Mais s’il y a bien dans le Jira du projet un grand nombre de bugs corrigés, c’est surtout la maturité du source qui a grandi.
Malgré tout, la bonne nouvelle est que JBoss espère bien pouvoir l’intégrer dans sa ligne produit et que RedHat continue l’investissement sur le projet.

Nexus sous license GPL: Sonatype explique son choix

Nexus est le gestionnaire de dépôts Maven développé par Sonatype. La version 1.0 est sortie à l’été 2008 sous la licence GPL. Il faut croire que Sonatype a fait face à de nombreuses critiques car la société vient de publier sur son blog un post intitulé « Why we chose the GPL for Nexus » lui permettant d’argumenter son choix. Alors quelles furent ces raisons ?
Le « problème » de la GPL est qu’elle force à redonner à la communauté les changements effectués dans le source au cas où le logiciel obtenu est redistribué. Dans le cas spécifique de Nexus, Sonatype explique que le produit était vu dès l’origine comme un produit commercial, sans question d’open source. Puis, trouvant le processus de développement plus fun, intéressant et plus productif, couplé au fait que l’équipe voulait « protéger son investissement », il fut décidé de passer en Open Source. Sonatype est franc sur ce dernier point et affirme l’avoir toujours été.
Ensuite, la société explique les idées qui guident généralement ses choix de licence:

• L’Affero GPL ne permet pas aux utilisateurs de développer des extensions, même à usage interne, sans avoir à redistribuer les sources. Dans le cas de Nexus, cela aurait sans doute impacté négativement son adoption.
• Sonatype considère que, pour un projet open source, passer d’une licence donnée à une licence plus restrictive n’est pas correct. On se souvient que certains on déjà réalisé cette transition en s’attirant alors des critiques d’utilisateurs. Sonatype déclare que ce ne sera pas leur cas.
• La documentation, elle, est soumise à un principe différent. En effet, la compagnie pense que celle-ci constitue une bonne partie de la plus-value apportée. Ainsi, ils ne veulent pas voir de concurrents se servir de leur travail. C’est pourquoi ils ont choisi la licence Creative Common 3.0 BY-ND-NC interdisant à quiconque de modifier cette documentation.

Au final, cet article est passionnant dans la mesure où il nous permet de bien appréhender le raisonnement derrière le choix d’une License pour des produits très répandus dans l’écosystème Java. Nous les utilisons tous les jours sans forcément nous poser de questions. Pourtant, pour certains clients, il peut être important de garder fermées leurs sources. Après, savoir si c’est une réelle nécessité ou un simple état d’esprit difficile à changer est une autre histoire !

Agilité

Le rôle des leaders dans une équipe agile

Mike Cohn, auteur de nombreux livres sur l’agilité et membre fondateur de l’Alliance Agile, revient sur le rôle des managers au sein d’une organisation de type agile. Un des principes forts des méthodes agiles est la mise en place d’une équipe auto-organisée, où il n’y a théoriquement plus de chef de projet. Cependant, Mike nous averti qu’une auto-organisation ne veut pas dire les développeurs font tout ce qu’ils veulent. Au contraire, Mike explique que des managers ont tout à fait leur rôle à jouer dans ce type d’organisation. Ainsi, il développe l’idée d’une influence subtile et indirecte des managers sur l’équipe.
C’est alors au fur et à mesure des challenges, des échecs et réussites que l’équipe évolue d’elle-même vers l’organisation la plus appropriée. Les managers sont néanmoins là pour poser certaines limites et contraintes.
A la fin de son article, Mike nous présente un exemple concret d’un scrum master au prise avec un développeur, qui est un peu trop solitaire, et nous expose comment il pourrait résoudre ce problème de manière subtile. Le scrum master peut être alors vu comme un agitateur au sein de l’équipe pour l’aider à devenir plus agile. Et, c’est là l’un des plus gros challenges d’un scrum master, qui consiste à naviguer entre un subtil mélange de contrôle et d’influence.

RIA

Le nouveau jQuery est arrivé !

Un an jour pour jour (ou presque) après la sortie de jQuery 1.3, voici venir la nouvelle mouture du framework qui nous arrive dans une version 1.4. Le détail complet des nouveautés se trouve sur cette page. Le mot d’ordre : performance !

L’API a subit une réécriture complète. Un des points marquants est la fonction live(), déjà présente dans la version précédente, qui supporte désormais tous les évènements Javascript (click, change…). Pour ce qui est des nouveautés au niveau de l’API, on retiendra plus particulièrement :

• contains() : vérifie l’existence d’un nœud DOM dans un autre nœud DOM,
• isEmptyObject() et isPlainObject() : vérifie si un objet est vide ou existant (new Object ou {}),
• detach() : supprime du DOM un set d’éléments,
• focusin() et focusout() : ajoute un événement de type focus,
• clearQueue() : supprime de la pile les éléments qui n’ont pas encore été lancés,
• delay() : définit un timer pour l’exécution de certains éléments dans la pile,
• toArray() : récupère tous les éléments du conteneur jQuery dans un tableau.

Côté performance, on peut noter une réelle amélioration pour les méthodes remove, html et empty. Un gros travail a donc été effectué au niveau des méthodes de manipulation du DOM. Il en va de même pour la gestion des attributs et des propriétés css.

Pour le téléchargement de la librairie production (minifié et GZippé) ou développement (code non compressé) ou pour consulter la documentation, je vous renvoie directement sur la home page du site. Et pour les fans de CheatSheet (comme moi ), la version 1.4 est déjà disponible au format HTML, PDF ou PNG.

Et si vous appréciez jQuery et le travail de toute l’équipe qui se trouve derrière, vous pouvez faire une donation de 20$ et ainsi recevoir un eBook jQuery gratuitement !

Survol de la galaxie Flex.

Vous voulez passer à Flex, mais vous ne savez pas par où commencer ? Suivant l’adage « Pour bien travailler il faut avoir de bons outils », InfoQ propose un survol de la galaxie Flex. Sans rentrer dans les détails de l’article, on notera :

• les IDE : le célèbre FlexBuilder, mais aussi IntelliJ, ou encore des environnements plus exotiques comme Amethyst, EnsembleTofino et FlashDevelop. Nous n’avons pas (encore) eu l’occasion d’essayer ces derniers, mais si l’un de nos lecteurs possède une expérience avec ces outils, qu’il n’hésite pas à la partager !
• les frameworks : là encore, outre les classiques (PureMvc, Cairgorm…), quelques petits nouveaux tentent d’émerger, dont deux qui nous ont interpellé : Ruboss (pour intégrer Ruby on Rails) et Prana (IoC). Nous espérons bientôt les tester.
• les outils de support du developpement : là encore, Flex commence à se doter d’un arsenal conséquent : tests unitaires (FlexMonkey), couverture de code (FlexCover), tests de GUI (RIATest). Il ne reste plus qu’à monter une usine logicielle digne de ce nom en agrégeant ces utilitaires.
• les outils d’intégration dans l’entreprise : là encore, un certains nombre de ces outils sont archi-connus (comme BlazeDs), et d’autres plus confidentiels, peuvent présenter un réel intérêt : intégration à Struts (FxStruts), AmFast (Python)… Nous aurons probablement l’occasion d’en reparler.

Au final, InfoQ propose un survol relativement complet et permet de découvrir de nouveaux outils. Ne reste plus qu’à les tester, ou à recueilli vos retours d’expérience !

SOA

• Spring Integration et Apache Camel : 2 ESB lightweight en action

Le coin de la technique

• Impala, la modularité pour Spring sans OSGi
• La définition de DataSources dans JEE 6
• Les google-collections sont finales !
• Spring Roo en 1.0.0 pour terminer l’année

SOA

Spring Integration et Apache Camel : 2 ESB lightweight en action

La mouvance SOA a amené un certain nombre de produits classifiés comme ESB (Enterprise Service Bus) dont le but est de répondre aux problématiques d’intégration courantes en entreprise. Dans un premier temps, ces produits prenaient la forme de middlewares très lourds dont la mise en œuvre devait être justifiée par des besoins importants. Il y a deux ans, nous assistions à l’avènement d’ESB qualifiés de lightweight car ils prenaient la forme de frameworks moins gourmands en ressources et plus simples à utiliser. Spring Integration et Apache Camel sont les deux principales options à envisager en matière d’ESB léger.

C’est justement de l’utilisation de chacun de ces deux frameworks que discute l’article que vient de publier Biju Kunjummen. Il y propose une problématique d’intégration qui consiste en l’exposition d’un service qui, lorsqu’il est invoqué, entraîne l’invocation multiple d’un même service de bas niveau via l’utilisation d’un pattern splitter sur la requête et d’un pattern aggregator sur la réponse. Les deux frameworks offrent nativement ce type d’EIP (Enterprise Intergration Pattern).

Aucun favori ne se démarque clairement dans la comparaison entre ces deux implémentations : Spring Integration vient s’intégrer naturellement à l’Application Context de Spring en reprenant le même type de structure de définition XML, tandis qu’Apache Camel, bien qu’offrant également la possibilité d’une configuration XML, sera surtout apprécié pour son DSL Java permettant la définition des routes d’intégration.

Le lecteur intéressé par ces deux frameworks pourra se tourner, au-delà des documentations respectives, vers les deux livres en préparation chez l’éditeur Manning, Spring Integration in Action et Camel in Action, prévus pour l’été prochain.

Le coin de la technique

Impala, la modularité pour Spring sans OSGi

La modularité est un sujet porteur en ce moment, tant du côté du JDK avec Jigsaw, que du côté Java Entreprise avec OSGi dont le principal acteur actuellement est sans conteste SpringSource avec Spring Dynamic Modules et son serveur d’application associé Spring dm Server.

Phil Zoio a été interviewé il y a peu pour présenter le projet Open Source qu’il a fondé : Impala. Il s’agit d’une vision différente de la modularité pour applications d’entreprise. Ainsi, Impala repose sur Spring, tout comme Spring Dynamic Modules, mais contrairement à ce dernier, il n’utilise pas OSGi et adopte une stratégie radicalement différente : il constitue lui-même des modules encapsulant chacun un application context qui déclare un certain nombre de beans. La solution de modularité ainsi produite offre tout comme OSGi un fonctionnement dynamique permettant le chargement à chaud de nouveaux modules.

Dans un climat où beaucoup s’interrogent sur la potentielle lourdeur d’OSGi, ce type d’initiative proposant une solution alternative plus simple face au standard prend tout son sens et n’est pas sans rappeler l’offensive de Spring Framework lui-même, il y a quelques années, face au contesté standard EJB.

La définition de DataSources dans Java EE 6

Matt Corey poste cette semaine un article mettant en avant une facilité rarement (jamais ?) évoquée de Java EE 6 : la configuration des sources de données par annotation. En effet, si la nouvelle spécification de Sun est largement couverte depuis des mois, y compris sur notre blog, il est en général question des nouveautés qui retiennent le plus l’attention telles que les beans singletons d’EJB 3.1, l’API query builder de JPA 2.0 ou encore ses nouveaux modèles de composants.

En fait il s’agit d’une standardisation de la technique de configuration des sources de données dans les serveurs d’application Java EE. Cette définition était en effet jusqu’alors un détail d’implémentation des serveurs et n’était donc pas portable. Cette configuration peut donc maintenant se faire par l’annotation @DataSourceDefinition ce qui évite ainsi l’utilisation de XML et va donc dans le sens de la logique initiée depuis Java EE 5. L’exemple suivant permet de mieux se rendre compte de son utilisation :

@DataSourceDefinition (
className="org.apache.derby.jdbc.ClientDataSource",
name="java:global/jdbc/AppDB",
serverName="localhost",
portNumber=1527,
user="user",
password="password",
databaseName="dev-db"
)
public class Config {
...
}

Si tout le monde n’appréciera pas forcément d’avoir recours à une annotation pour ce type de configuration, les projets souhaitant distribuer des war ou ear portables qui se connectent à une base de données embarquée ou locale devraient en revanche y trouver leur compte.

Les google-collections sont finales !

Annoncée sur la users list du projet, l’API google-collections passe en version finale 1.0.
Pour ceux qui ne connaissent pas encore cette API de collections type-safe, rendez-vous sur cette page pour une introduction à la librairie.

La finalisation de Google Collections constitue un changement majeur dans l’environnement des développeurs Java. En effet Apache Commons Collections constituait jusqu’alors le principal complément à l’API de base du JDK. Or, la librairie de la fondation Apache est vieillissante et ne propose toujours pas les generics de Java 5. Google Collection se positionne donc ni plus ni moins que comme un remplaçant.

La FAQ répondra à bon nombre de questions que l’on peut se poser sur cette API notamment sur les raisons qui ont poussé Google à créer sa propre API plutôt que de contribuer à Commons Collections.

Enfin on notera que Google Collections sera intégré à Guava sous peu pour constituer la librairie d’extension du JDK de Google.

De par la nature de ces APIs, Google Collections et Guava peuvent également constituer un premier pas vers la programmation un peu plus orientée fonctionnelle. A ce sujet, il est aussi possible de regarder du côté de lambdaj, une API de parcours de collections sans boucle explicite. Et pour ceux qui souhaitent aller encore plus loin, rendez-vous sur functional.java ou  tournez vous vers la préparation des closures dans Java.

Spring Roo en 1.0.0 pour terminer l’année

Encore une release pour Spring pour clôturer en beauté l’année 2009. Bravo!
Spring Roo, 8 mois après sa première version alpha, vient de sortir en 1.0.0. Roo, en quelques mots, permet de développer des applications plus rapidement en générant et maintenant, tout au long des développements, une partie importante du code source (du POJO à la JSP).
Un effort a été mis sur la documentation qui a intégré un tutoriel et les commandes. La seule partie encore en travaux est le chapitre 3, celle qui concerne le fonctionnement interne de ROO. Cette partie permet entre autres d’avoir les bases pour développer des extensions.
En standard, Roo propose déjà des extensions, comme par exemple les fonctionnalités de sécurité, basées sur Spring Security et des flows avec Spring Webflow.

Spring Roo présente un formidable intérêt pédagogique, car il s’appuie systématiquement sur les toutes dernières versions des jars de Spring et d’Hibernate.
On peut par contre trouver peu commode son mécanisme interne qui se base sur la technologie AspectJ. Son principe est de générer les méthodes de classe en se basant sur des fichiers d’aspects. Jusqu’à présent, notre expérience avec Spring Roo a montré que cela ne fonctionnait pas de manière complètement transparente pour le développeur, même avec l’Eclipse de SpringSource (STS). Cette limitation pourra donc dissuader certaines équipes de partir sur un projet avec ROO tout au long des développements.

Voici sur Slideshare, les deux présentations mises en ligne par le leader du projet, Ben Alex:

• Introduction To Spring Roo 1.0.0
• Spring Roo 1.0.0 Technical Deep Dive

Actualité éditeurs / SSII

• Le meilleur de The Server Side

Le coin de la technique

• Spring Security seulement un alignement sur Spring 3.0 ?
• Tour d’horizon de JBoss Infinispan
• JGroups à l’heure du Cloud Computing

Actualité éditeurs / SSII

Le meilleur de The Server Side

Avec les fêtes vient le temps des rétrospectives. Et c’est TheServerSide qui ouvre le bal, avec son hit parade des neuf fils de discussion les plus vus en 2009. Sans surprise, on retrouve quelques stars de l’année, dont la popularité ne devrait pas faiblir en 2010 : JavaEE 6 et Glassfish 3, la persistance (JPA, les caches d’Hibernate, la démarcation transactionnelle avec Spring)… Mais aussi les buzz de l’année : Google App Engine, les langages next-gen… On trouve ensuite un grand article communautaire, sur ce que doit savoir un architecte applicatif.
Enfin, et nous devons bien avouer qu’à la vue des évènements passés, cela prête à sourire, un très beau fil de prospective : IBM parle de racheter Sun.

Cette première rétrospective reflète pour nous bien les tendances de l’année passée : pas mal de grandes manœuvres chez les éditeurs, des concurrents à Java de plus en plus présent, un nouvelle spécification très attendue, et des frameworks incontournables qui continuent à mener la danse.

Le coin de la technique

Spring Security seulement un alignement sur Spring 3.0 ?

Dans la foulée de la sortie de la version 3 de Spring Framework, c’est au tour de Spring Security de faire son annonce. Le point le plus marquant de cette version est l’utilisation du Spring Expression Language pour décrire les règles de contrôle d’accès qui simplifieront des vérifications simples comme @PreAuthorize("#contact.name == principal.name)") et surtout, couplé à des classes java transverses de sécurité, permettra d’effectuer élégamment des contrôles déclaratifs sophistiqués tels que :

@PreAuthorize("isPhysician(#patientFile.patient)")
public void create(PatientFile patientFile);

Bien sûr, il faudra programmer la méthode isPhysician(), Spring Security ne se substituera pas au code métier de votre application, il sera juste une aide précieuse .
Nous noterons au passage que l’Expression Language apporte à l’Aspect Oriented Programming le haut niveau d’abstraction qui permet de programmer des fonctionnalités métiers transverses sans être un spécialiste de la plomberie ProceedingJoinPoint et autres joyeusetés. L’AOP devient alors beaucoup plus accessible pour les développeurs d’informatique de gestion.

Les autres nouveautés que nous garderons en tête : des contrôles pré et post traitement (@PreAuthorize et @PostAuthorize), la restructuration des jars similaire à celle que Spring 2.5 a connu, et une clarification des règles de redirection post authentification.

Tour d’horizon de JBoss Infinispan

Le projet Infinispan a été initié en milieu d’année 2009 chez JBoss. Il s’agit d’une évolution de JBoss Cache d’un simple cache vers un DataGrid.

Dans le dernier épisode en date de JBoss Asylum, le podcast dédié à la communauté JBoss maintenu par Emmanuel Bernard et Max R Andersen, Mark Surtani, leader du projet Infinispan, était invité pour parler de son projet. Il a pu faire un tour d’horizon global en commençant par le lien entre JBoss Cache et Infinispan :

• Contrairement à JBoss Cache qui utilisait une organisation arborescente, Infinispan se base uniquement sur une structure clé-valeur à plat.
• Tout comme le faisait JBoss Cache, Inifinispan utilise JGroups pour assurer la découverte de ses instances.
• Une API d’adaptation permettra d’assurer la transition entre JBoss Cache et Infinispan, notamment en offrant une arborescence au dessus de la structure de base d’Infinispan. Des outils seront fournis afin de migrer les fichiers de configuration.

Manik Surtani a également abordé les fonctionnalités à venir, après la finalisation de la première version, dévoilant ainsi les ambitions de positionnement de ce produit :

• Utilisation de Lucene pour offrir une API de requêtes puissante permettant des recherches dans le DataGrid. Plusieurs possibilités d’architecture ont été évoquées telles que la réplication d’un index complet sur l’ensemble des noeuds ou la distribution de shards de l’index complet sur les noeuds via l’utilisation d’un InfinispanDirectory pour Lucene, actuellement en cours de développement.
• Intégration éventuelle avec Hibernate Search. Infinispan se substituerait à Hibernate Core et Hibernate Search lui apporterait alors la fonctionnalité de recherche.
• Possibilité d’effectuer des continuous requests pour que les résultats d’une requête s’enrichissent au fur et a mesure de l’arrivée de données sur la grille.
• API de MapReduce permettant de soumettre un Callable et un ensemble de clés d’objets sur lesquels doivent s’appliquer le traitement pour obtenir un Future représentant le résultat, à venir, après opération de réduction.

La plupart des fonctionnalités évoquées sont présentes dans les produits commerciaux que sont Oracle Coherence ou IBM eXtreme Scale. Toutefois, de telles possibilités seraient inédites dans un produit Open Source ce qui devrait faire d’Inifinispan un produit très intéressant à suivre en 2010…

JGroups à l’heure du Cloud Computing

JGroups est un framework permettant la communication au sein d’un groupe de serveurs. Actuellement développé au sein de JBoss, il est à la base de nombreux middlewares et frameworks d’entreprise permettant un fonctionnement distribué tels que JBoss Cache ou plus récemment Infinispan.

Après un an sans mise à jour majeure, Bela Ban, leader du projet, annonce la version 2.8. Outre de nombreuses évolutions améliorant la flexibilité de JGroups, un apport notable s’est glissé dans la liste : le support d’Amazon EC2. Il s’agit là d’une nouveauté emblématique de cette année 2009 qui va se conclure ; la majorité des frameworks cherche à afficher une compatibilité voire une synergie avec les environnements de Cloud Computing courant.
En pratique, cette intégration de JGroups à EC2 se fait par l’ajout d’un nouveau protocole de découverte de voisinage nommé S3_PING. Comme son nom l’indique, il utilise un stockage S3 commun dans lequel tous les membres d’un groupe écrivent leurs coordonnées. Ce mécanisme est particulièrement bien adapté à EC2 qui, de part la topologie réseau qu’il offre, ne permet pas le multicasting et n’est guère adapté aux autres protocoles de découvertes qui existaient jusqu’alors dans JGroups.

Notons tout de même que la principale nouveauté de cette version 2.8 est l’ajout du concept d’adresse logique que Bela Ban présentait il y a quelques mois. Une adresse logique permet de découpler l’identité d’un nœud JGroups de son adresse réseau ; l’association entre adresse logique et physique est résolue lors de la découverte des nœuds. Outre le découplage offert par ce concept, ces adresses permettent également de simplifier la gestion des pertes de messages lors de la ré-incarnation d’un nœud suite a son indisponibilité temporaire.

10 ans après sa création, JGroups continue donc de se maintenir à jour et, dans la mesure où il remplit toujours parfaitement son rôle, il devrait rester présent encore des années dans plusieurs middlewares et frameworks majeurs.

Actualité éditeurs / SSII

• JEE 6 commence à apparaître chez JBoss

Le coin de la technique

• Sortie de TeamCity 5
• Apache Camel continue d’évoluer

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

• Suite et fin, traduction de la deuxième partie de DDD Quickly

Actualité éditeurs / SSII

JEE 6 commence à apparaître chez JBoss

Quelques jours avant la finalisation de Glassfish V3, l’implémentation de référence de la nouvelle spécification JEE, JBoss met à disposition une première milestone de JBoss AS 6.0, le serveur d’application que l’éditeur destine à implémenter JEE 6.

Ce premier jet apporte seulement 3 des composants propres à JEE 6 :

• Weld, un conteneur CDI implémentant la JSR-299 (Contexts and Dependency Injection).
• Un moteur de validation implémentant la JSR-303 (Bean Validation). L’implémentation utilisée est Hibernate Validator 4.0.
• Une implémentation de JSF 2. Il s’agit de l’implémentation de référence de Sun.

Pourquoi ces composants en particulier ? Parce qu’il s’agit soit des composants pour lesquels JBoss est responsable de l’implémentation de référence, soit, dans le cas de JSF 2, d’une implémentation de référence empruntée à Sun. Or, ces composants sont forcément finalisés puisqu’ils seront intégrés à l’implémentation de référence de l’ensemble de la spécification JEE 6 qu’est Glassfish V3, qui sera disponible dans quelques jours (peu après la finalisation de la spécification le 10 décembre).

JBoss AS 6.0 M1 embarque Hibernate 3.5.0 beta 2, or Steve Ebersole, un des membres de l’équipe Hibernate, expliquait que le support de JPA 2 dans cette version était encore partiel. Aucune indication n’est par contre donnée quant au statut de l’autre composant majeur de JEE 6 qu’est EJB 3.1.

Aucune roadmap n’est annoncée, mais il semble raisonnable de penser à une finalisation pour fin 2010. Si l’on regarde la vitesse de déploiement des serveurs Java EE 5, rares seront donc les privilégiés qui pourront utiliser Java EE 6 avant 2011 voire 2012…

Le coin de la technique

Sortie de TeamCity 5

Fin de semaine dernière est sortie la nouvelle version du serveur d’intégration continue de JetBrains à savoir TeamCity (via JavaLobby). Cette version 5 apporte son lot de nouveautés et elles sont assez alléchantes, jugez par vous-même :

• support d’Amazon EC2 avec un agent de build sur le Cloud permettant de faire du build distribué,
• meilleur support de maven,
• templates de build (préférences partagées),
• intégration avec les gestionnaires de bugs YouTrack, Jira et Bugzilla,
• archivage de projets,
• command line tool (build sans plugin intégré à l’IDE),
• back-up and restore pour simplifier la maintenance de TeamCity,
• ainsi que plusieurs nouvelles fonctionnalités et corrections de bugs dont le support de Git et la compatibilité du plugin TeamCity avec IntelliJ IDEA CE.

Les licences ne changent pas, laissez-vous tenter !

Apache Camel continue d’évoluer

Claus Ibsen, un membre de l’équipe Apache Camel, annonce une nouvelle version 2.1 du moteur de médiation d’Apache.

Il liste les principales nouveautés parmi lesquelles on notera un effort particulier pour apporter une gestion plus robuste des routes :

• Amélioration des messages d’erreur fournit au démarrage en cas de mauvaise définition d’une route.
• Il est désormais possible de définir un ordre de démarrage pour les routes.
• Il est également possible d’indiquer si une route doit être auto-démarrée.

Poursuivant dans cette voie, Claus Ibsen explique son intention d’apporter un graceful shutdown à Camel pour la version 2.2, ce qui permettrait un arrêt de l’ESB sans perdre de messages. Cet arrêt sans perte est dors et déjà possible avec la version 2.1 mais nécessite plusieurs manipulations via JMX (arrêt des routes, puis arrêt du moteur lorsque plus aucun message n’est en cours de traitement).

James Strachan, créateur du projet, expliquait lors de Devoxx 2009 que la majorité de ses clients déployaient Camel sur Tomcat, Jetty ou ServiceMix pour bénéficier d’un environnement de monitoring plus riche et d’une structure plus familière pour l’administration. Ces pratiques montrent les besoins de robustesse des entreprises quant aux déploiements Camel. Ces améliorations, répondant à des problématiques réelles lors de l’utilisation de Camel pour la médiation, devraient donc être accueillies avec joie par les équipes utilisant ce framework.

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

Suite et fin, traduction de la deuxième partie de DDD Quickly

Dans la revue de presse du 10 octobre 2009, nous avons relayé l’information de la traduction de la première partie de DDD Quickly.

La traduction de la deuxième et dernière partie est terminée. Ce livre est disponible sur le portail DDD France.

Dans cette deuxième partie : On y retrouve des techniques pour mettre en oeuvre DDD sur de gros projets impliquant plusieurs équipes, mais aussi pour refactorer un domaine et gérer sa croissance, notamment à travers la distillation et l’identification d’un Coeur de Domaine. (source sur le blog de Guillaume)

Félicitations à Guillaume Lebur pour ce gros travail, et bonne lecture de DDD Vite fait au pied de votre arbre de Noël !

Actualité éditeurs / SSII

• SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Le coin de la technique

• Lucene passe à Java 5
• Mark Reinhold justifie l’introduction des closures
• Patterns NoSQL

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

• Devoxx 2009 : le bilan

Actualité éditeurs / SSII

SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Adrian Colyer, SpringSource, a annoncé la création d’un nouveau projet au sein de la fondation Eclipse : Gemini. Il s’agit d’un sous-projet d’Eclipse Runtime qui a pour but de réunir l’ensemble des implémentations de référence des spécifications OSGi liées au monde de l’entreprise. Il s’agit d’un effort commun de SpringSource et d’Oracle.

Deux composants fondamentaux sont apportés par SpringSource :

• Gemini Web Container : il permet le fonctionnement d’un conteneur de Servlets dans un environnement OSGi. Cette implémentation est actuellement utilisée dans SpringSource dm Server et est donc prévue pour fonctionner sur Tomcat. Mike Keith, Oracle, assure que l’adaptation pour Jetty arrivera par la suite grâce à une collaboration avec l’équipe de ce projet.
• Gemini Blueprint Service : il s’agit de Spring Dynamic Modules. Ce projet, qui a fortement inspiré la spécification du Blueprint Service intégré à OSGi 4.2, devient logiquement son implémentation de référence.

Il est important de noter qu’Adryan Colyer explique que SpringSource continuera désormais le développement de ces deux projets directement au sein de la fondation Eclipse et non plus en interne.

Oracle, pour sa part, apporte plusieurs implémentations de référence pour des RFC supplémentaires non intégrées à la spécification OSGi 4.2 : RFC 98 (transactions), RFC 122 (database access), RFC 139 (JMX integration), RFC 142 (JNDI integration), RFC 143 (JPA integration), RFC 146 (JCA integration).
Mike Keith indique qu’EclipseLink est à même de fonctionner correctement avec OSGi depuis longtemps, mais qu’il n’implémentait pas JPA lorsque cette intégration a été mise en œuvre au sein du projet. Par conséquent, une adaptation est nécessaire pour passer à la RFC 143, afin d’assurer une intégration JPA standard.

Alors que la spécification 4.2 a été finalisée il y a 2 mois, les implémentations de référence étaient toujours attendues. Cette réunification des implémentations liées a l’OSGi d’entreprise au sein d’un même projet Eclipse est une excellente nouvelle : elle met en avant la standardisation dont on pourra désormais bénéficier pour les développements intégrant OSGi dans les applications JEE. Mais cela suffira-t-il à démocratiser OSGi en entreprise ?!

Le coin de la technique

Lucene passe à Java 5

L’équipe du projet Lucene annonce la sortie de Lucene 3.0. Comme nous l’expliquions précedemment, cette version marque une évolution majeure puisqu’elle est la première a nécessiter Java 5.0 au minimum.

L’API bénéficie donc désormais de l’ensemble des améliorations du langage de Java 5.0 dont les generics, le varargs, les enums et l’autoboxing.

Tempérons cette annonce : l’API Lucene n’a pas été refondue, il ne s’agit que de quelques améliorations visant à la rendre type-safe. Citons par exemple :

• Apparition d’enums BooleanClause.Occur, Field.Index, Field.Store et Field.TermVector ; ces concepts étaient jusqu’alors représentées sous forme de constantes type-safe.
• La méthode getFields() de la classe Document retourne désormais une List<Fieldable> alors qu’elle retournait une simple List jusqu’alors.
• La classe Term implémente désormais Comparable<Term> et non plus simplement Comparable.

Ces changements légers décevront peut-être certains utilisateurs lassés par l’API vieillissante de Lucene, mais on appréciera toutefois la facilité de migration, puisqu’il s’agira la plupart du temps de supprimer quelques casts (l’équipe Lucene cite quelques cas à surveiller lors de la migration).

Cette nouvelle version, qui apporte par ailleurs quelques modifications mineures, conclut donc un cycle d’évolutions importantes sur le projet Lucene.

Mark Reinhold justifie l’introduction des closures

C’était l’Annonce de cette édition de Devoxx, l’apparition des closures en Java 7. Mark Reinhold revient, sur son blog, sur les raisons à l’origine de cette petite bombe.
Il justifie cette évolution majeure du langage par la nécessité pour Java de tirer partie des nouvelles générations de processeurs, multi-cœurs.
Jusqu’ici, pour exploiter cette puissance, il fallait utiliser des Parallel Array et tout le code inutile nécessaire à leur fonctionnement. Les closures permettent de supprimer ce code, et il est temps de les introduire en Java.
Java doit se concentrer sur deux fonctionnalités clés : la syntaxe littérale, et les fonctions typées. L’arrivée des closures requiert deux autres évolutions de Java : les conversions, et l’extensibilité des méthodes.
Il est temps pour Mark Reinhold d’oublier les querelles. Sun spécifiera et implémentera un premier jet des closures pour le JDK 7. Cela permettra une expérimentation à grande échelle, et si tout se passe bien, cela conduira à une JSR de modification du langage, qui pourra être incluse dans Java SE 7.
La tâche est immense et Mark Reinhold appelle bien évidement toutes les bonnes volontés à contribuer.

Bien au-delà de la manipulation du multi-threading, les closures pourraient permettre une simplification des APIs courantes. Cette perspective semble essentielle à Mark Reinhold qui ne pouvait attendre le JDK 8 pour une nouvelle tentative, dans 3 à 4 ans…

Patterns NoSQL

Nous vous parlions récemment dans une revue de presse et un article du mouvement NoSQL, qui se caractérise par « une absence de requête et par un relâchement des caractéristiques ACID propres aux RDBMS ». Ricky Ho, architecte chez Adobe, revient sur son blog sur les caractéristiques communes de plusieurs technologies permettant de « faire du NoSQL », et extrait quelques patterns récurrents. Ne vous arrêtez pas à la mise en page étriquée de l’article, car la description est très complète. Ricky Ho y explore successivement:

• Les types de noeud possibles (physiques et virtuels) ainsi que leur fonctionnement.
• Le partitionnement des données.
• La réplication de ces données, ainsi que le maintien de leur consistance.
• La gestion des pannes.

On notera quand même que l’une des solutions retenue pour le stockage des données reste… une base de donnée relationnelle ! Humour mis à part, une telle formalisation de patterns est vraiment bienvenue dans un environnement aussi émergeant.

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

Devoxx 2009 : le bilan

Nous concluons aujourd’hui notre série de billets sur Devoxx 2009. Ces 5 jours passés à Anvers furent riches en informations et en rencontres et nous souhaitions vous les faire partager.

A l’heure du bilan, voici ce que nous retiendrons de cette édition :

• Les annonces concernant JDK 7, JEE 6 et Maven 3.0.
• Le succès de JEE 6 : toutes les sessions sur le sujet ont fait salle comble.
• La place réservée à la nouvelle plateforme Flash d’Adobe, présente au keynote et dans de nombreuses sessions ; il est intéressant de noter que cette place correspond exactement à celle occupée par JavaFX lors de la précédente édition.
• L’omniprésence de Scala ; au-delà des sessions qui lui étaient consacrées, il était cité dans beaucoup d’autres présentations lorsqu’il était question de DSL par exemple.
• L’intérêt persistant de la communauté pour le Cloud Computing. Ce nouveau concept a rencontré un large succès à Devoxx.

Pour rentrer plus en détails dans les enseignements de cette conférence, vous pouvez désormais retrouver l’intégralité de nos billets Devoxx :

• Devoxx – Jour 1 – Adobe University
• Devoxx – Jour 1 – Applications robustes avec Amazon EC2
• Devoxx – Jour 1 – Kanban in action
• Devoxx – Jour 1 – JSF 2
• Devoxx – Jour 1 – NoSQL avec HBase
• Devoxx – Jour 2 – Google App Engine
• Devoxx – Jour 2 – Les effets avec Flex 4
• Devoxx – Jour 2 – Hibernate Search
• Devoxx – Jour 2 – Java FX The developer guide
• Devoxx – Jour 2 – SOA en pratique
• Devoxx – Jour 2 – Scala Actors
• Devoxx – Jour 3 – Spring Actionscript
• Devoxx – Jour 3 – ScalaTest
• Devoxx – Jour 3 – La keynote
• Devoxx – Jour 3 – JEE6
• Devoxx – Jour 4 – Maven Reloaded
• Devoxx – Jour 4 – Java Performance Tuning
• Devoxx – Jour 4 – Intégration pour le Web avec iBeans
• Devoxx – Jour 5 – Projet Lombok

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

Introduction

Tout d’abord quelques chiffres autour de JEE6 :

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

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

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

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

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

Web Profile

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

EJB Lite

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

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

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

Managed Beans

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

• Injection (@Resource …)
• Life-Cycle (@PostConstruct, @PreDestroy)
• Interceptor (@Interceptor, @AroundInvoke)

@javax.annotation.ManagedBean
public class MyPojo {
   @Resource
   private DataSource dataSource ;
   @PostConstruct
   private void init() {
      // ...
   }
   @Interceptor(LoggingInterceptor.class)
   public void perform() {
       // ...
   }
}

Bean Validation

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

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

JAX-RS

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

@Path("/users/{userId}")
@Stateless
public class UserResource {
   @GET @Produces("image/jpeg")
   public byte[] getPhoto() {
      // ...
   }
   @GET @Produces("text/xml")
   public String getUser(@PathParam("userId") String id) {
      // ...
   }
}

@Inject et CDI (Context and Dependency Injection)

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

Mais aussi…

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

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

Conclusion

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

• 2500 participants,
• 737 compagnies représentées comme Xebia par exemple ,
• 132 sessions,
• 120 speakers,
• 56 JUGs (dont 10 en France),
• 36 pays,
• et 19 partenaires ce qui est moins que d’habitude.

La nouvelle version de Parleys.com

Stephen Janseen débute en nous expliquant ce que fournira la nouvelle version de Parleys.com. Gratuites et disponibles, le nombre de vidéos augmente sur les serveurs, ce qui est très coûteux. Pour pallier ce problème, il a décidé de publier le plus tôt possible les conférences de Devoxx (ce week end même d’ailleurs ). Et avec un abonnement de 49€ pour 6 mois, un utilisateur pourra soit télécharger toutes les vidéos qu’il souhaite sur le site soit les regarder directement en streaming. Pour les plus patients, la video sera rendue publique en streaming pour tous au bout d’un an.
Dans cette nouvelle version, il sera possible :

• De définir des channels privés ou publiques selon les besoins du publieur,
• De choisir son look’n'feel,
• D’ajouter des commentaires sur la piste video.

Ces nouveautés sont actuellement disponibles sur http://beta.parleys.com.

La keynote de Java EE 6

Cette année à Devoxx, la star est clairement JEE6 avec pas moins de 7 sessions autour de ce sujet :

• Une keynote.
• Une université et un BOF JEE6.
• Une université et un BOF JSF 2.0.
• Une conférence JEE6.
• Une conférence JEE6 et Glassfish V3.

La keynote met en avant les spécifications les plus hypes de JEE6 avec entre autres :

• EJB 3.1,
• DI 1.0 (@Inject),
• CDI 1.0 (Context and Dependency Injection),
• JSF 2.0 (événement que nous avons couvert),
• Bean Validation 1.0,
• Servlet 3.0,
• et JAX-RS 1.1.

Un article plus complet décrivant JEE6 arrivera très prochainement, l’information principale de cette keynote étant la date de sortie de JEE6 qui est prévue pour le 10 décembre 2009 (Cf. notre précédente revue de presse).

La keynote d’Adobe avec en guest-star Flash Catalyst

Adobe fut à l’honneur cette année à l’instar de JavaFX. La keynote fut l’occasion pour l’éditeur de tenter une opération séduction de la communauté Java avec des annonces autour de Flex, Air, Flash Player Lite et Flash Catalyst.

Pour commencer, Flash Player 10.1 fut présenté. Cette version a surtout été travaillée pour fonctionner sur téléphone mobile :

• Réduction de la mémoire utilisée.
• Limitation de la consommation de batterie.
• Gestion du multi-touch et de l’accéléromètre.

Serge Jespers a présenté un Flash Player déployé sur mobile : oui, il est enfin possible d’accéder à Parleys depuis son mobile !

La liste des partenariats entre Adobe et les fabricants de smartphone et d’OS a considérablement augmenté depuis l’année dernière. Avec, entre autres, le petit dernier : RIM, l’OS de BlackBerry. Actuellement, Apple ne fait toujours pas partie de cette liste. Aucun accord n’a été trouvé pour le moment. Il n’est donc pas possible de lire une application Flex par exemple depuis le navigateur de son iPhone. En revanche, il est possible de déployer une application Flex sur l’AppStore et de l’utiliser. En effet, Adobe a mis en place un moyen permettant de convertir un swf en code natif pour l’iPhone. Des jeux Flash sont d’ailleurs déjà disponibles sur l’AppStore.

Autre annonce, la sortie depuis quelques jours de la béta de Adobe Air 2.0. Cette version fournit les nouveautés suivantes :

• Le support de l’usb.
• Le support du multi-touch.
• De nouvelles APIs permettant de récupérer la sortie du microphone.
• Une sécurité améliorée pour mieux répondre aux standards des entreprises et gouvernements.

Nos deux speakers ont ensuite impressionné la salle en réalisant rapidement à partir d’un dessin issu d’Illustrator une application Flex comportant des effets, gérant un évènement click sur un bouton, et le plus impressionnant de tous, la gestion d’une scrollbar provenant d’un dessin. Cette génération fut ensuite exportée dans Flash Builder 4 en tant que projet Flex. La salle semblait séduite par la démo. Attendons maintenant 2010, pour voir si cette plateforme tiendra ses promesses et si la communauté continuera à suivre.

Actualité éditeurs / SSII

• Terracotta a faim d’Open Source : acquisition de Quartz
• JDK 7, JEE 6, et Maven 3.0 : les annonces de Devoxx

RIA

• GWT version 2.0 RC1

Le coin de la technique

• OWASP Security Top Ten, la cuvée 2010 est arrivée
• Que devient Spring Rich Client ?

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

• Devoxx 2009

Actualité éditeurs / SSII

Terracotta a faim d’Open Source : acquisition de Quartz

Terracotta a annoncé cette semaine l’acquisition de Quartz, le scheduler open source le plus connu est le mieux intégré du marché. Cette acquisition est l’exacte copie de celle opérée cet été avec Ehcache. Tout comme ehCache, Quartz est un projet open source, largement utilisé et bien intégré avec la plupart des solutions stars de leur secteur … et porté par un seul homme (James House). Cible idéale pour Terracotta ? Probablement. Mais il se pose toujours la question suivante : comment Terracotta compte t’il rentabiliser cette acquisition, quand on sait a quel point la monétisation d’un projet open source est difficile. Quoi qu’il arrive, d’ici la prochaine acquisition, Terracotta touche, par ce biais, une communauté de plus en plus large. Cela sera-t-il suffisant pour séduire un éventuel racheteur ?

D’autre part, comme le signale Alex Miller, Quartz c’est :

• Un nouveau site web.
• Un nouveau gestionnaire de sources.
• Un nouveau gestionnaire d’anomalies.
• Un nouveau forum.
• Mais toujours la même licence, Apache 2.

JDK 7, JEE 6, et Maven 3.0 : les annonces de Devoxx

La conférence Devoxx ayant eu lieu la semaine dernière a été l’occasion de plusieurs annonces importantes qui ont rapidement fait le tour de la blogosphère.

JDK 7 avec les closures, mais retardé à nouveau

C’est surement l’annonce qui à fait le plus de bruit. Elle s’est répandue comme une trainée de poudre tant elle était inattendue. Lors d’une présentation en apparence sans surprise sur les nouveautés du JDK 7, Mark Reinhold explique que le temps est venu pour Java de supporter les closures. Afin de permettre leur implémentation, la finalisation du JDK 7 est repoussée à septembre 2010. Trois nouveaux milestones sont donc ajoutés au calendrier initial avec une finalisation des fonctionnalités (features complete) prévue pour Juin 2010. Ce nouveau délai permet donc à l’équipe du JDK de travailler sereinement sur la finalisation de Jigsaw, d’implémenter les closures, et devrait vraisemblablement permettre également l’inclusion du multi-catch pour les exceptions.

En fait ce délai semble laisser la possibilité à de nombreuses autres fonctionnalités et spécifications qui avaient été mises de coté de prétendre de nouveau intégrer le JDK 7. On peut ainsi imaginer :

• JMX 2, qui avait été repoussé au JDK 8
• La JSR-310 (Date and Time API) qui avait connu des difficultés par manque de contributions et n’avait finalement pas été incluse à la liste finale des fonctionnalités du JDK 7
• La JSR-296 (Swing Application Framework) dont le retrait du JDK 7 avait été annoncé cet été
• Le support des propriétés

Questionné à Devoxx sur l’étendue des fonctionnalités pouvant être concernées par une potentielle inclusion, Mark Reinhold ne ferme la porte à aucune hypothèse. Il explique ainsi qu’il n’a pas eu l’occasion de voir de proposal pour les propriétés qui lui semblait satisfaisante jusqu’à présent mais n’exclue pas une telle possibilité d’ici la finalisation des fonctionnalités du JDK 7.

JEE 6 finalisé en décembre

Lors du keynote du premier jour des conférences, Roberto Chinnici (Spec lead JEE 6) a annoncé la finalisation de l’ensemble des spécifications JEE 6 ainsi que de l’implémentation de référence associée (Glassfish V3) pour le 10 décembre 2009.

Cette nouvelle intervient alors que JEE 6 a été très bien accueilli par le public à Devoxx comme il l’a été maintes fois répété dans le dernier épisode des Cast Codeurs.

Maven 3.0 finalisé en Janvier

Cette annonce est passée plus inaperçue parmi l’actualité de Sun. Pourtant Jason van Zyl, lors de sa présentation des nouveautés de Maven 3.0, a annoncé une finalisation de la nouvelle version de son outil de build pour la fin janvier 2010.

Cette nouvelle version apportera le support des builds multithreadés ainsi qu’un environnement de base pour les extensions très intéressantes que sont Polyglot Maven et Maven Shell.

Nous publierons rapidement un article plus détaillé sur l’ensemble des nouveautés à venir sur Maven 3.x.

RIA

GWT version 2.0 RC1

Une nouvelle version majeure du RIA de Google, GWT, sort en version 2.0 RC 1. Cependant, aucune date de sortie n’est encore annoncée.
Cette version s’accompagne d’un plugin pour Eclipse, nommé Google Plugin for Eclipse 1.2 RC1, dont l’on recommande vivement la mise à jour.
Parmi les nouveautés, on peut citer:

• Utilisation du Development Mode (anciennement appelé Hosted Mode) dans le navigateur de votre choix via un plugin.
• Possibilité de fragmenter le code JavaScript généré en plusieurs morceaux en utilisant GWT.runAsync() va permettre d’accélérer considérablement les temps de chargement.
• Story Of Your Compile (SOYC) génère un rapport sur le processus de compilation et permet d’avoir une meilleure vision du code généré.
• Facilitation de la création d’IHM par déclaration avec Ui Binder.
• Apparition d’un ClientBundle, similaire au ImageBundle, qui permet la généralisation du sprinting à d’autres formats les fichiers textes, css, etc.
• Utilisation de HtmlUnit pour les tests unitaires, qui permet maintenant de débugger directement dans le débuggeur Java.

Les nouveautés sont donc nombreuses et apportent un réel gain de productivité.
Le combat auquel se livrent actuellement les RIA est loin d’être terminé…

Le coin de la technique

OWASP Security Top Ten, la cuvée 2010 est arrivée

Après le Beaujolais Nouveau et le calendrier des pompiers, c’est au tour de l’OWASP de faire son annonce avec la mouture 2010 de son « Security Top Ten ». En attendant de rédiger un billet complet sur ces failles et leur prévention en Java, voici un lien vers une présentation que nous avions fait pour une formation interne et la liste 2010 avec une présentation très succincte des parades dont nous disposons en Java :

A1 – Injection : injection sql, hibernate ql, jpa ql, http, etc.
Utiliser des prepared statements, les paramètres de commons http, etc.

A2 – Cross Site Scripting (XSS)
Utiliser JSR 303 Bean Validation pour valider les données entrantes et escaper les données sortantes avec JSTL ou un équivalent.

A3 – Failles d’Authentification et de gestion de Gestion de Session
Utiliser Spring Security ou les mécanismes du moteur de servlet.

A4 – Référence Directe Non Sécurisée aux Objets de données
Revalider tous les ID provenants des requêtes HTTP ou utiliser un aliasing par random (cf. org.owasp.esapi.AccessReferenceMap).

A5 – Cross Site Request Forgery (CSRF)

Protéger les invocations d’URL par le contrôle d’un nombre aléatoire généré côté serveur. En cas de risque majeur, utiliser un framework Web de description de flow (Spring Web Flow, JBoss Seam, etc).

A6 – Mauvaise configuration de sécurité (Nouveau)
Utiliser les installation standard des systèmes d’exploitation et des middlewares, restreindre les droits des utilisateurs unix, etc.

A7 – Mauvaise protection des URL

Utiliser des mécanismes de sécurité déclarative par URL ou par annotation sur les beans controlleurs et de service.

A8 – Utilisation de redirects et forwards non controlés (nouveau)

Ne pas construire l’url de redirection ou de forward avec des données saisies par l’internaute. Figer les valeurs possibles de redirection dans le code ou dans des fichiers de configuration.

A9 – Failles des systèmes de stockages encryptés

Ne jamais stocker un mot de passe en clair, éviter de stocker des informations sensibles comme les numéros de carte bleue, . Si c’est finalement nécessaire, mettre en place un système de stockage dédié avec une gestion très attentive.
Documenter dans les configurations de logging (e.g. log4j.properties) les loggers à ne pas activer si des informations sensibles ne doivent pas sortir dans les logs (e.g. couche de binding des frameworks web).

A10 – Protection insuffisante des canaux de communication

Ne pas réinventer de canal de transport sécurisé, utiliser SSL quand c’est possible ; sinon, regarder WS-Security même s’il est très couteux à mettre en œuvre (debugging, etc).

Que devient Spring Rich Client ?

Spring Rich Client est un framework applicatif basé sur Spring. Il permet de créer des applications clients lourds plus facilement qu’en utilisant l’environnement Swing de base.

La promesse est séduisante, toutefois le projet initié en 2004 ne s’est vu finalisé que 4 ans plus tard, en mars 2008. Dès lors certains doutes planent quant à la santé de cette communauté.

Lieven Doclo, leader du projet, en a présenté les fonctionnalités lors d’un BOF à Devoxx. Ce fut également l’occasion d’un certain nombre de questions quant à la santé et au positionnement de ce projet méconnu :

• Bien qu’il soit directement référencé au sein du portfolio de SpringSource, l’éditeur n’investit pas dans ce projet. On notera d’ailleurs que Lieven Doclo n’est pas employé par SpringSource mais consultant Java externe.
• Le projet souhaite se positionner face à Eclipse RCP et NetBeans RCP en mettant en avant l’obligation d’utiliser SWT pour le premier et le manque de perspectives pour le second du fait des récentes déclarations d’Oracle.
• Les évolutions lentes du projet s’expliquent par la taille réduite de l’équipe. Lieven Doclo appelle d’ailleurs les volontaires à le rejoindre.

Si l’utilisation du framework Spring pour l’assemblage des composants des applications Spring RC est attirante car elle permet de reproduire les paradigmes de programmation utilisés pour le développement d’applications Web, Spring Rich Client peine encore à convaincre face aux poids lourds que sont les solutions d’Eclipse et de Netbeans. Il pourra toutefois intéresser les équipes souhaitant réutiliser des composants Spring existants.

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

Devoxx 2009

La semaine dernière se tenait l’édition 2009 de Devoxx à Anvers. Retrouvez nos premiers billets sur cette semaine de conférence :

• Devoxx – Jour 1 – Adobe University
• Devoxx – Jour 1 – Applications robustes avec Amazon EC2
• Devoxx – Jour 1 – Kanban in action
• Devoxx – Jour 1 – JSF 2
• Devoxx – Jour 1 – NoSQL avec HBase
• Devoxx – Jour 2 – Google App Engine
• Devoxx – Jour 2 – Les effets avec Flex 4
• Devoxx – Jour 2 – Hibernate Search
• Devoxx – Jour 2 – Java FX The developer guide
• Devoxx – Jour 2 – SOA en pratique
• Devoxx – Jour 2 – Scala Actors

Actualité éditeurs / SSII

• Innovation permanente chez Google
• Java SE 5 en fin de vie, JDK 7 en approche

SOA

• 10 mythes au sujet des SOA

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

• Soirée Google au LyonJUG

Actualité éditeurs / SSII

Innovation permanente chez Google

Google est encore une fois au cœur de l’actualité cette semaine avec la mise à disposition d’un nouveau langage de programmation et d’un protocole destiné à remplacer HTTP.

Le langage Go est à la croisée de C, Java et Pascal et est annoncé comme ayant des performances proches du C. Go se distingue par le fait que son compilateur produise directement du code natif, et qu’il ne requiert donc pas de machine virtuelle. Il apporte toutefois un ramasse-miette et un ensemble d’abstractions permettant de simplifier la programmation parallèle.

Très rapidement, plusieurs opinions et résultats d’expérimentations sont apparus. Ainsi, Tim Yang montre les performances obtenues par une application serveur développée en Java (en utilisant Mina), C (avec Nginx) et Go. Les résultats qu’il obtient montre que Go est en retrait par rapport aux deux autres solutions. Ces résultats doivent toutefois être relativisés par la maturité acquise par le système d’entrée / sortie de la JVM, le design très performant offert par Mina, la réputation de performance de Nginx et enfin, bien sûr, par le stade embryonnaire de Go.

Google a également diffusé les spécifications de SPDY (prononcer Speedy), un protocole visant à remplacer HTTP. On le sait, HTTP n’est pas adapté au Web moderne. En particulier il n’est pas optimisé pour obtenir une latence minimale. SPDY ne redéfinit pas tout, il se base sur HTTP et y ajoute un ensemble de possibilités supplémentaires telles que la compression d’en-têtes, le multiplexage de flux ou encore la priorisation de requêtes.

Des tests sur le transport du contenu des sites Web les plus populaires, permettent à Google d’annoncer un gain moyen de 55%.

L’entreprise américaine continue donc d’impressionner par son innovation permanente, n’hésitant pas à remettre en cause régulièrement des technologies considérées comme incontournables.

Java SE 5 en fin de vie, JDK 7 en approche

Sur la page dédiée à J2SE 5.0, Sun notifie depuis début novembre les utilisateurs de l’arrivée en fin de vie (End of Service Life) de cette version de Java.

Arrivé il y a 5 ans, Java 5 avait constitué la mise à jour la plus importante de la plate-forme et de son langage depuis sa création. Son adoption en entreprise fut longue, mais s’est concrétisée au fil du temps. Ainsi aujourd’hui, on ne compte plus qu’une minorité de projets fonctionnant encore exclusivement avec la version 1.4 ou inférieure de Java.

Il en est tout autrement pour Java 6.0. En effet, contrairement à la version 5.0 dont l’adoption était indispensable pour profiter des technologies d’entreprise les plus récentes, les principales motivations pour passer à la version 6.0 concernent la JVM elle-même et les améliorations qu’elle a connue.

L’arrivée en EOSL pourrait accélérer les choses dans certaines entreprises, tandis que d’autres préfèreront se tourner vers l’offre Java for Business de Sun qui permet de continuer de bénéficier du support de l’éditeur.

Une autre possibilité pourrait se trouver dans l’arrivée de JDK 7. En effet, la roadmap du projet promet un début de phase Release Candidate débutant à la fin du premier trimestre 2010 pour une durée d’un à deux mois, ce qui permettrait donc l’arrivée d’une version finale dans 6 mois. Si la confiance dans les dates de finalisation annoncées de JDK 7 s’est évaporée au fil des reports successifs, la situation semble maintenant se stabiliser : Mark Reinhold vient d’annoncer la disponibilité de la M5 de JDK 7, en accord avec le calendrier prévisionnel de la roadmap. Quatre des fameuses évolutions du langage apportées par le projet Coin y sont implémentées et peuvent donc être d’ores et déjà testées.

SOA

10 mythes au sujet des SOA

Yefim Natis, de Gartner, a exposé durant l’évènement SOA in Action, dix mythes communs (et la réponse qu’il faut leur apporter) sur la mise en place d’une SOA.
Là où l’article porte à sourire, c’est que, pour une fois, la faute est partagée : cinq de ces mythes sont propagés par les fanatiques de la SOA, et sont mis en regard de cinq autres portés par les allergiques.

Pour les fanatiques, nous avons :

• Les services sont portés par l’IT et propagés vers les acteurs fonctionnels.
  Pour Yefim Natis, une SOA est un moyen pour l’IT de mieux comprendre et appréhender les problématiques métier.
• Les plate formes orientées services reposent sur des briques pré-fabriquées.
  Les SOA ne reposent pas uniquement sur des applications ‘services’, mais aussi sur des batchs et des applications héritées.
• Partager et réutiliser sont les principaux apports d’une SOA.
  C’est en effet un des bénéfices attendus, mais c’est loin d’être le seul. On peut citer : meilleure exploitation, meilleure montée en charge …
• Mettre en place une SOA permet de s’abstenir de réaliser une phase d’intégration.
  Même si la SOA permet d’introduire une stabilité dans les interactions entre services, elle ne dispense pas de réaliser de vrais tests d’intégration, bien au contraire.
• Une SOA réduit les coûts du SI.
  Sur le long terme, peut être … Mais dans un premier temps, une SOA peut s’avérer couteuse : nouvelle façon de penser, nouveaux outils, formations à prévoir…

Pour les allergiques, la liste est la suivante :

• Une SOA introduit une grande complexité et de nouveaux problèmes.
  La plupart des problèmes liés à la mise en place d’une SOA sont des problèmes existants partout ailleurs dans le monde de l’informatique distribuée. La mise en œuvre d’une SOA ne fait souvent que mettre en exergue des problèmes existants.
• SOA n’est pas nouveau, c’est juste un effet de mode.
  Il faut voir au delà de l’aspect technique : certes SOA repose sur les principes de l’informatique distribué, mais c’est l’ensemble de la démarche qui est nouvelle et qui a au moins l’avantage de crystaliser certaines bonnes pratiques.
• Une SOA est vouée à l’échec, parce que les Web Services sont un standard trop instable.
  SOA et SOAP sont deux choses complètement différentes. Les Web Services sont ‘juste’ un moyen d’exposer des services.
• Il est difficile de vendre une SOA, car les acteurs fonctionnels n’en voient pas les bénéfices.
  Certains bénéfices sont apparents de manières quasi instantanée (on pense aux indicateurs BAM), et les acteurs fonctionnels gagnent rapidement une nouvelle compréhension de leur environnement IT.
• SOA est déjà dépassé, il faut passer à la suite.
  Le challenge d’une SOA basique est en effet dépassé. Mais il reste de nombreux enjeux à adresser, notamment dans les architectures les plus complexes.

via InfoQ

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

Soirée Google au LyonJUG

Lundi 23 Novembre, le LyonJUG organise une soirée dédiée aux technologies Google. L’occasion de découvrir, démonstration à l’appui, Google Web Toolkit, Google App Engine, Android et le dernier né Google Wave. L’objectif est aussi de présenter l’architecture globale de ces produits pour mieux en saisir le fonctionnement et le but.
Pour faciliter l’organisation de la soirée dans les locaux d’EPITECH, vous devez vous inscrire ici.

Pour ceux qui ne le connaissent pas, Kirk Pepperdine dispose de plus de 15 ans d’expérience dans les technologies orientées objets et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java. Il est le DSI de Kodewerk Ltd et le principal contributeur de javaperformancetuning.com.

Cette formation approfondie de 4 jours permettra aux stagiaires d’obtenir les compétences nécessaires pour optimiser la performance de leurs applications Java/J2EE. Vous aborderez pendant cette formation tous les aspects de la performance :

• L’outillage nécessaire.
• Les méthodologies à appliquer.
• Les concepts d’architecture sous jacents à la performance.
• Les meilleures pratiques.
• Le benchmarking.
• La gestion de mémoire.

Si cette formation vous intéresse, n’hésitez pas à contacter Roderic Pratt au 06.09.69.05.49.

Actualité éditeurs / SSII

• Amazon lance Relational Database Service
• Oracle tente de rassurer la communauté Sun
• Keynote de Rod Johnson à SpringOne/2GX 2009

Le coin de la technique

• Optimisez vos requêtes SQL
• Apache POI 3.5
• Interminables débats sur la mort de Java
• Une version de tcServer pour les développeurs

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

• Flex 4 chez les Tontons Flexeurs

Actualité éditeurs / SSII

Amazon lance Relational Database Service

Quelques mois après la disponibilité d’Amazon Elastic MapReduce, le libraire américain continue d’enrichir sa gamme de services de Cloud Computing en lançant Amazon Relational Database Service (RDS).

RDS offre une base de données MySQL sur une plate-forme dynamiquement provisionnable. Suivant la logique initiée avec ses autres services, la facturation est fonction de la consommation réelle, la gestion des instances se fait à l’aide d’un Web Service spécifique à RDS et leur monitoring est possible par CloudWatch.

Outre ces caractéristiques communes aux services d’Amazon, on retiendra principalement de RDS :

• Utilisation de MySQL 5.1 avec InnoDB,
• Offre de réplication prévue pour assurer la haute disponibilité, mais non disponible à ce jour,
• Système de gestion des backups.

Par ce service, Amazon déleste ses clients des principales tâches liées à l’administration d’une base de données relationnelle. Répondant ainsi à un besoin réel, on peut s’attendre à ce que ce service, s’inscrivant dans l’offre homogène d’Amazon, rencontre un succès commercial.

Plusieurs réactions et commentaires ont suivi cette annonce, on retiendra particulièrement l’observation de Krishnan Subramanian, sur le coup dur que constitue ce nouveau service pour FathomDB, une entreprise qui proposait un service d’hébergement MySQL sur EC2. Il remarque alors qu’il est délicat pour des startups de parier sur de tels services propriétaires.

Oracle tente de rassurer la communauté Sun

Depuis l’acquisition de Sun par Oracle en avril dernier, le futur de la stack Sun a fait l’objet de peu de communiqués. Quelques rumeurs ici ou là sur le futur de MySQL ont fait surface, après la disparition du lien permettant de télécharger les premières briques de MySQL 6. C’est peut-être pour couper court à ce genre de bruits de couloir qu’Oracle présente ses intentions sur la stack Sun via la mise à jour de sa FAQ . En résumé « on garde tout, et on en fait toujours plus » :

• Oracle dit vouloir passer plus de temps sur Solaris et Sparc que Sun ne l’a fait par le passé. La collaboration d’ingénieurs base de données Oracle et Sun ouvre d’ailleurs de nouvelles perspectives.
• Côté virtualisation, tous les produits Sun ‘devraient’ continuer à être développés : VDI, Secure Global Desktop, Sun Ray, and VirtualBox.
• Un alignement entre Oracle Weblogic Server et Glassfish Enterprise Server va être effectué. Glassfish reste l’implémentation de référence open source pour Java EE 6.
• Netbeans restera une solution alternative open source à Oracle JDeveloper et Oracle Enterprise Pack pour Eclipse.
• MySQL devrait être ajouté à la liste des bases de données de la suite Oracle au même titre que Berkeley DB, une base de données open source.

Comme vous pouvez le constater, rien de très précis, tout est au conditionnel. Le but est avant tout de ne surtout pas se mettre à dos les différentes communautés.

Keynote de Rod Johnson à SpringOne/2GX 2009

SpringSource est actuellement un des plus grands agitateurs de notre écosystème. Et donc quand Rod Johnson, le papa de Spring, vient donner un keynote en ouverture du plus gros évènements annuel de l’éditeur, on écoute avec attention. Grâce à InfoQ, il est possible de retrouver cette intervention en différé.
En résumé, pas grand chose de nouveau, mais Rod Johnson enfonce le clou sur les sujets que Spring met en avant depuis quelques mois déjà :

• Spring 3.0 : les nouvelles fonctionnalités, et les scénarios d’upgrade.
• Les languages dynamiques : Groovy et Grails, une fois encore à l’honneur
• Les outils destinés aux developpeurs: tcServer (voir par ailleurs), Spring Insight, SpringSource Tool Suite
• Les grandes manœuvre de l’éditeur : aquisition par VMWare (pas grand chose à se mettre sous la dent de ce coté là)
• Le futur de SpringSource : CloudFoundry et les Cloud d’entreprise en Java

En bref, un très bon résumé (pour ceux qui reviendraient de longues vacances) des changements qui nous attendent dans les mois à venir, impulsés par l’un des éditeurs les plus dynamiques du monde JEE.

Le coin de la technique

Optimisez vos requêtes SQL

Nous sommes tombés sur ce post qui nous propose 15 moyens pour optimiser vos requêtes SQL. Si quelques-unes d’entre elles vous paraitront être issues du bon sens commun, d’autres méritent le détour :

• Prenez le plus grand soin de vos index : Le contenu des index primaires se doit d’être le plus petit possible, les index uniques sont en règle générale plus performants.
• Recherchez par wildcard avec certaines précautions : Privilégiez l’utilisation de wildcard à l’utilisation de SUBSTR. Les wildcards postfixés sont plus performants que les wildcards préfixés. Dans la mesure du possible n’hésitez pas à n’indexer qu’une sous partie d’une chaîne de caractères plutôt que la chaîne dans son ensemble. En général utilisez les types de données les plus petits possibles.
• Simplifiez vos requêtes : Privilégiez l’utilisation de l’opérateur EXIST à une utilisation de COUNT. Limitez le nombre de lignes à retourner pour éviter la récupération complète d’une table. Utilisez des valeurs par défaut dans vos colonnes pour simplifier vos requêtes.
• Évitez les scans inutiles : Remplacer l’opérateur NOT d’une expression complexe par son inverse permet de ne pas évaluer l’intégralité de celle-ci. Transformez une sous-requête dans un IN par une sous-requête dans un FROM (et simulez ainsi une table virtuelle). Les UNION sont en principe plus efficaces que les OR car ils permettent d’optimiser l’utilisation des index.

Le tuning de requêtes SQL n’est pas simple, les commentaires sur le billet original en témoignent. Il dépend grandement de la base de données et de sa configuration. La base de données repose sur des statistiques pour savoir quand utiliser ses index. De ce fait, l’amélioration de la performance de vos requêtes commence le plus souvent par une analyse du plan d’exécution de celles-ci. Celui-ci vous permettra de trouver comment poser vos index. Enfin, certaines bases de données comme Oracle vous permettent d’agir directement sur son plan d’exécution à partir de votre requête, par l’intermédiaire de SQL HINT. A n’utiliser qu’en dernier recours

Apache POI 3.5

Du nouveau sur le support des documents Office 2007 en Java (sujet déjà abordé il y a un an) avec Apache POI qui est sorti il y a un mois en version finale 3.5 (via InfoQ). Parmi les nombreuses nouveautés, on retiendra surtout le support des fichiers .docx et .xlsx et plus globalement des documents Office 2007 (mais il aura fallu attendre un an entre la beta 3 et la version finale !).

Plusieurs librairies nous offrent déjà la possibilité de gérer nos fichiers Office 97-2003 (format Microsoft OLE2). Peu d’entre elles proposent la gestion des fichiers Office 2007 (format Microsoft Office Open XML ou OOXML) : par exemple Aspose.Word gère uniquement les fichiers Word 2007. Avec Apache POI 3.5, c’est toute la gamme de produits Office 2007 qui se trouve ainsi supportée.

Quelques modifications seront toutefois nécessaires dans votre code pour supporter ce nouveau format. En effet, le modèle org.apache.poi.hssf.usermodel.HSSF actuel reste compatible OLE2 mais ne supportera pas OOXML. Il faudra ainsi passer par le nouveau modèle org.apache.poi.ss.usermodel.HSSF pour bénéficier de ce support. Ce nouveau modèle s’appuyant fortement sur l’ancien, l’équipe précise que le switch ne devrait pas être trop ardu.

Le téléchargement se passe comme d’habitude sur les miroirs d’Apache.

Interminables débats sur la mort de Java

A chaque année ses raisons d’annoncer la mort de Java ; le débat n’est pas nouveau et les arguments se renouvellent depuis le début des années 2000 :

• Lourdeur de J2EE
• Complexité et densité de l’écosystème Java
• Manque d’intégration des solutions et les faiblesses du langage face au rival Microsoft .Net
• Inadaptation à la création d’interfaces pour le Web et pour les clients lourds
• Manque de productivité face aux nouveaux langages : Python, Ruby, …

En 2009 l’argumentaire se tourne maintenant vers les langages alternatifs pour la JVM – principalement Groovy et Scala – et vers l’incertitude liée à la gouvernance de Java. Ainsi il y a quelque semaines, Stephen Colebourne postait un inquiétant graphique montrant l’évolution décroissante du nombre de JSR créées auprès du JCP au cours des années. Il se demandait alors si cela pouvait être pris comme une perte de vitesse ou comme un signe de maturité mais remarquait que l’innovation était maintenant principalement portée par les communautés Open Source.

Stephan Schmidt apportait, en septembre dernier, une analyse intéressante du débat sur la mort de Java. Il commençait par dissocier les 3 composantes de Java que sont le langage, la JVM et le JDK, chacun ayant une pérennité distincte. Il exposait alors différents points :

• La quantité d’offres d’emploi en Java reste constante comme le montre le graphe Indeed (devenant un classique en argumentaire).
• Avant la mort de Java, un successeur doit se distinguer. Or Ruby et Python ont peiné à faire leur place dans le monde de l’entreprise. Il reconnaît en revanche le positionnement appréciable de Groovy suite à sa prise de contrôle par SpringSource puis par VMWare et l’innovation intéressante portée par Scala.
• Java est toujours à même d’apporter les caractéristiques qui ont amené son succès : pas de pointeurs, gestion de la mémoire, orientation vers l’entreprise et Internet, gestion simple du parallélisme.
• C’est le monde de l’entreprise qui permet le succès d’un langage, or Java répond toujours à ses besoins même si le langage présente des défauts nuisant à la productivité.
• Java a perdu il y a bien longtemps le hype qui l’entourait, mais cela ne signifie pas pour autant sa mort.

A travers l’évolution du débat, un aspect majeur ressort : les critiques portent maintenant principalement sur le langage Java, la JVM étant reconnu pour ses qualités et la capitalisation qui s’est faite autour d’elle. Dès lors, la JVM se présente comme une plate-forme standard pour les développements, non sans rappeler le statut acquis par l’environnement x86 d’Intel des années auparavant.

La mort annoncée du langage Java au profit de langages alternatifs pour la JVM doit, quant à elle, probablement être modérée. En effet Java, fort de ce que Sun décrit comme la plus grosse communauté de développeurs au monde, n’est actuellement clairement pas menacé.

Une version de tcServer pour les développeurs

SpringSource vient d’annoncer la sortie prochaine (pour l’instant, une preview est téléchargeable) de tcServer Developer Edition. Que trouve t’on dans ce joli package ?

Côté serveur d’application, rien de nouveau, c’est toujours du 100% Tomcat.
C’est une fois de plus dans les à-côtés que tcServer se distingue, avec l’arrivée de Spring Insight. Spring Insight, c’est une console qui va vous permettre de surveiller ce qui se passe au cœur de votre application, à la fois en prenant un point de vue global, mais aussi en zoomant très précisément sur une requête HTTP donnée.

Et quoi de nouveau me direz vous ? Et bien, à vrai dire, pas de rupture technologique (plusieurs outils permettaient de réaliser des mesures comparables) mais une facilité d’intégration à votre application, sujet si cher à Spring. Tout se passe en AOP (rien à faire donc dans votre code), toutes les informations sont stockées en mémoire (pas de base de données, mais en contrepartie, une augmentation de la mémoire consommée par votre application) et les principaux frameworks du marché peuvent être scrutés en utilisant un mécanisme de plugin.
En revanche, Spring est très clair : il s’agit d’un outil de développement : son utilisation en production exposerait vos applications d’un point de vue sécurité.
Une fois de plus, SpringSource joue la carte du tout intégré et de la simplicité, et risque de séduire à la fois des développeurs et des Q&A un tant soit peu sensibles à la qualité intrinsèque d’une application.

Nous avons aimé :

• L’expressivité des métriques qui identifient les URL d’invocation, les principaux composants (actions Spring MVC, composants métier, etc), les transactions et les accès SGBD avec les requêtes SQL.
• La granularité macro qui est souvent plus facile à comprendre que les mesures ultra-détaillées que nous proposent les profilers java.

Notre souhait : l’intégration à l’environnement de développement et au code source de l’application en cliquant sur les graphes de Spring Insight.

Le screencast et la preview de tcServer Dev. se trouvent sur le blog de SpringSource.

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

Flex 4 chez les Tontons Flexeurs

Les tontons flexeurs, le rendez-vous incontournable des flexeurs et des autres, nous propose une nouvelle présentation qui portera sur les nouveautés de Flex 4.
Christophe Coenraets, évangéliste senior chez Adobe, nous présentera ainsi les nouveautés de LiveCycle Data Services 3, le Model-Driven Developpement avec FlashBuilder 4 et l’intégration de Flex avec Spring.
La présentation se déroulera le mardi 10 novembre de 14h à 16h. Les inscriptions se font comme d’habitude sur l’evenbrite.

Actualité éditeurs / SSII

• SpringOne G2X : c’est parti pour Spring 3 !

RIA

• GWT 2.0 Milestone 1

Le coin de la technique

• memcached vs. DataGrid, serveur stupide vs. serveur astucieux ?
• Finalisation de l’implémentation de référence de Beans Validation
• Le noyau de dm Server disponible séparément, pourquoi ?
• Un nouveau moteur de stockage pour ActiveMQ 5.3 : KahaDB

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

• Traduction de la première partie de DDD Quickly

Actualité éditeurs / SSII

SpringOne G2X : c’est parti pour Spring 3 !

L’édition américaine de cette conférence dédiée aux produits SpringSource commence aujourd’hui à la Nouvelle Orléans et durera 4 jours. Elle est donc plus longue que les années précédentes en raison de l’intégration de nombreuses présentations dédiées à Groovy, mais également plus dense puisqu’on compte pas moins de 8 sessions en parallèle. La lecture du planning permet de noter la présence fortement marquée de Spring 3.0 et Spring Roo. Par ailleurs SpringSource offre de nombreuses sessions à Groovy / Grails, avec des sujets rarement évoqués tels que Grails and the JVM Memory Management ou OSGi and Groovy.

En accord avec les préceptes du Conference Driven Development, évoqués par Guillaume Laforge dans un podcast , SpringOne G2X est l’occasion d’un certain nombre d’annonces. Ainsi SpringSource vient d’annoncer dans un communiqué la finalisation du très attendu Spring 3.0, qui était jusqu’alors en statut release candidate.

Cette version est la première mise à jour majeure de Spring depuis la version 2.5 sortie il y a maintenant 2 ans et qui avait notamment apporté la configuration massive par annotations. Les principaux apports de la version 3.0 sont :

• Support de REST dans Spring MVC
• Transition de l’ensemble du code du framework vers Java 5, tirant ainsi partie des generics
• Support de Spring Expression Language (SpEL) dans les annotations comme dans la configuration XML
• Intégration de certains des mécanismes de configuration de Spring JavaConfig
• Intégration d’OXM, l’abstraction de mapping Objet / XML jusqu’alors incluse dans Spring WS
• Support initial de la JSR-330 (Dependency Injection)

Ces nouveautés étaient très attendues par la communauté et le succès à venir de Spring 3.0 semble acquis. Si cette projection est évidente, il est par contre plus délicat de dire qui aura la préférence dans les projets entre JAX-RS et le support de REST intégré à Spring MVC ou encore entre le nouveau standard qu’est la JSR-330 face à l’API propriétaire de Spring…

RIA

GWT 2.0 Milestone 1

GWT 2.0 arrive à grands pas ! Un petit avant goût nous est proposé depuis quelques jours avec la Milestone 1 de ce nouveau cru GWT (via InfoQ).

Des nouveautés, il y en a ! Du changement de terminologie en passant par de nouveaux composants, GWT 2.0 apporte son lots de gros changements :

• nouvelle terminologie : le hosted mode devient le developpement mode et le web mode devient le production mode ;
• distribution unique avec, vous le verrez sur la page de téléchargement, un JAR unique et non plus un JAR par environnement (Windows, Mac et Linux) ;
• developpement mode directement dans le navigateur (GWT utilise pour cela un plugin de lecture de code natif), les fenêtres du mode hosté disparaissent ;
• ajout du code splitting qui découpera le code en plusieurs fragments : l’idée ici est que l’on pourra commencer à utiliser une application web GWT alors que certains fragments (non nécessaires au démarrage de la webapp) n’auront pas été chargés, ce qui permettra entre autres un démarrage plus rapide de l’application (chargement différé) ;
• UIBinder qui offrira la possibilité de déclarer nos écrans dans un fichier XML (swing-like ou flex-like, à vous de choisir ) ;
• ClientBundle qui optimisera et combinera des ressources telles que les fichiers texte, les CSS ou les XML, ce qui permettra de réduire le trafic réseau et les temps de latence ;
• utilisation d’HtmlUnit pour les tests unitaires ;
• suppression des APIs GWT dépréciées jusqu’à la version 1.6.

Les défauts que l’on remarquait sur les premières versions se corrigent donc petit à petit et GWT 2.0 affiche le souhait d’aider / simplifier la vie du développeur. Google confirme ainsi qu’il faut toujours compter sur GWT dans la course effréné au meilleur RIA du marché. Il est vrai que des applications comme Google Wave montrent clairement le potentiel technique de GWT (robustesse, rapidité…).

Concernant l’upgrade vers cette nouvelle mouture, l’équipe se veut rassurante et précise qu’une montée de version entre la 1.7 et la 2.0 ne devrait pas demander beaucoup d’efforts.
Le JAR se récupère à cette adresse.

Le coin de la technique

memcached vs. DataGrid, serveur stupide vs. serveur astucieux ?

Billy Newport, Websphere eXtreme Scale, est juge et partie dans son billet memcached versus DataGrid, dumb server versus smart server… dans lequel il compare le très à la mode memcached avec les sophistiquées DataGrid (IBM Websphere eXtreme Scale, Gigaspaces XAP, Oracle Coherence).
Le point d’attention de Billy Newport est la rusticité de memcached qui amène souvent les utilisateurs à inventer au dessus un ensemble de rustines qui rendent la solution finalement complexe et sous optimale. Le principal défi est la gestion de la haute disponibilité et la faiblesse du failover. En effet, l’intelligence de memcached se limite à être un gros entrepôt de clés-valeurs ; un serveur memcached n’est pas conscient qu’il est utilisé en mode partitionné et clusterisé avec d’autres serveurs, ce sont les clients memcached qui connaissent la topologie et ont une intelligence de routage des plus rudimentaire avec un modulo sur le hash de la clef à stocker.
De ce fait, les mécanismes de failover en cas d’arrêt d’un serveur sont très limités ; une extension de consistent hashing améliore la situation en évitant un transfert brutal de toutes les données que causerait la perte d’un nœud (tous les modulos changent). Ce ne sont que les débuts des difficultés, les ingénieurs de Facebook, gros consommateurs de memcached, détaillent dans Designing the Facebook username land rush les défis de fiabilité qu’ils ont rencontrés.
A cette rusticité de memcached, Billy Newport oppose la sophistication des DataGrids qui assurent en standard la fiabilité des données qu’elles gèrent, en consommant souvent moins de ressources mémoire, CPU et réseau.

Mesquinerie d’un éditeur qui cherche à tacler un concurrent ?

On peut en douter, l’argumentaire de Billy Newport est parfaitement cohérent. Memcached a été initialement créé pour mettre en cache des fragments html pour le site web LiveJournal, des données en lecture seule qui ne nécessitent de fiabilité, alors que les DataGrids ont été dès leur conception destinées au monde de la finance qui a besoin d’une fiabilité sans faille.

Alors que vaut-il mieux, un serveur rudimentaire étoffé par des gens astucieux ou des DataGrids astucieuses directement utilisables par des équipes qui n’ont pas le temps ou les compétences pour inventer un cache distribué fiable ?

Sans négliger le coût des DataGrids, rappelons nous l’adage « There is a fine line between clever and stupid », tout le monde n’est pas ingénieur clustering chez Facebook

Finalisation de l’implémentation de référence de Beans Validation

Emmanuel Bernard annonce la disponibilité de la version 4.0 finale d’Hibernate Validator. Cette version est la première à implémenter la JSR-303 (Beans Validation) qui devrait se voir également finalisée dans le même temps.

En pratique, Validator 4.0 apporte principalement :

• La composition de contraintes : il est ainsi possible de créer des contraintes qui réutilisent des contraintes existantes afin d’éviter la duplication de code.
• La notion de groupe : en catégorisant les contraintes dans des groupes, il est possible de ne valider qu’une partie des contraintes, ce qui trouvera son intérêt dans de nombreux cas d’utilisation.
• Les contraintes type-safe : la compatibilité entre le type supporté par une contrainte et celui de la valeur qu’elle valide est maintenant vérifié par Validator.
• Une API de création de contraintes : il est désormais possible de définir des contraintes par programmation et non plus uniquement par Annotation.
• La définition de contraintes par XML : alors que la version précédente ne permettait la définition de contraintes que par annotations, il est désormais possible de les définir également dans un fichier XML.

Les utilisateurs d’Hibernate Validator reconnaitront dans ces nouveautés des manques qu’ils avaient pu constater dans les versions précédentes. Toutefois, c’est probablement dans le support de la JSR-303 que réside la vraie révolution, puisqu’il s’agit d’unifier les très nombreux frameworks de validation qui se sont multipliés dans le monde Java depuis des années afin que nos applications ne dépendent plus que de javax.validation.

Le noyau de dm Server disponible séparément, pourquoi ?

Steve Powell, SpringSource, annonce la disponibilité d’une version autonome du noyau de dm Server : dm Kernel. Il s’agit d’une abstraction autour d’OSGi qui offre un environnement plus élaboré pour la construction de modules indépendants.

Par cette annonce SpringSource s’aligne sur un certain nombre d’autres middlewares qui mettaient déjà à disposition leur noyau assurant leur modularité tel que HK2 pour Glassfish, MicroContainer pour JBoss AS ou encore Karaf pour Apache ServiceMix. Une question vient alors naturellement en tête, pourquoi une telle séparation entre un middleware et son noyau en deux projets distincts ? On trouve des éléments de réponse en revenant sur le contexte entourant la sortie de chacun des noyaux concernés :

• Guillaume Nodet expliquait la création d’un projet à part pour le noyau de ServiceMix par le souhait exprimé par plusieurs projets Apache de se baser sur celui-ci.
• Steve Powell dans son annonce de dm Kernel met surtout en avant le fait qu’il ait pu être extrait de dm Server sans modification, prouvant ainsi le design propre et modulaire du serveur d’application de SpringSource.
• Glassfish HK2 et JBoss MicroContainer ont quant à eux été l’occasion de mettre en avant la légèreté du serveur d’application auquel ils sont liés.

Si la raison d’être de ces projets de noyaux modulaires se situe quelque part entre design, partage, et marketing, la communauté Java s’en trouve dans tous les cas enrichie puisqu’ils permettent à des projets naissant de bénéficier immédiatement d’une architecture flexible et d’un socle robuste.

Un nouveau moteur de stockage pour ActiveMQ 5.3 : KahaDB

Rob Davies annonce la disponibilité d’ActiveMQ 5.3. Cette nouvelle version apporte son lot de nouveautés et d’améliorations à ce Message Oriented Middleware très populaire dans le monde Open Source.

Parmi les nouveautés, c’est la finalisation du nouveau moteur de persistance de messages KahaDB qui retient l’attention. Annoncé il y a un an sur la mailing list du projet, et en gestation depuis, le but de KahaDB est d’apporter la vélocité de Kaha Message Store et la fiabilité de AMQ Message Store. Ce nouveau moteur de persistance offre ainsi :

• Journal transactionnel assurant la consistance des données
• Réplication des données très performante
• Support de plusieurs nœuds slaves
• Aucun point central d’échec, le noeud master peut être reconstruit sur un slave suite à une défaillance

KahaDB se base sur ZooKeeper pour assurer l’élection d’un nouveau nœud master.

Ce nouveau moteur de persistance s’annonce très novateur et devrait assurer l’attractivité de cette nouvelle version d’ActiveMQ. Les lecteurs intéressés par ActiveMQ noteront par ailleurs qu’un ouvrage lui étant entièrement consacré paraitra courant 2010 chez Manning.

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

Traduction de la première partie de DDD Quickly

Pour rappel, DDD = Domain Driven Design

Guillaume Lebur est à l’initiative d’un travail intéressant et difficile : la traduction en anglais du livre DDD Quickly. Ce livre propose une approche plus rapide du DDD afin d’en cerner les problématiques, contrairement au livre d’Eric Evans qui se veut plus exhaustif et précis sur le sujet.

Son travail est disponible sur le site DDD France, communauté libre qui ne parle que du DDD en français. En bon français cela donne DDD vite fait et surtout beaucoup de travail. La première partie est d’ores et déjà traduite, donc félicitations Guillaume et bon courage pour la suite !

Actualité éditeurs / SSII

• La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0
• Sonar 1.11

RIA

• Air ‘Athena’
• DHTMLX 2.5
• Tips and Tricks Maven 2

Le coin de la technique

• Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas
• Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Actualité éditeurs / SSII

La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0

La fondation Eclipse nous livre une nouvelle version de Jetty estampillée 7.0. Côté nouveauté, pas grand chose à vrai dire. Il y a évidemment l’habituelle série de corrections de bugs et d’améliorations de performance. Cette nouvelle version marque surtout le début de la route vers l’implémentation des servlets 3.0 prévue pour Jetty 8.0. C’est aussi l’occasion pour Eclipse d’assimiler un peu plus le projet en changeant principalement le package ancêtre de org.mortbay vers org.eclipse, gare au refactoring donc. A noter tout de même, Jetty est maintenant livré sous une forme modulaire pleinement compatible OSGI. Webtide en profite pour livrer la même version de Jetty, en y intégrant des modules additionnels:

• JSP de glassfish
• JTA d’atomikos
• plugin maven
• integration d’ant
• configuration Spring

Jetty 6 sera encore maintenu pendant quelques temps (aucune précision de la part d’Eclipse), tous les nouveaux développements seront faits sur Jetty 7, et la branche 8 sera en pré-release dans les prochains mois et supportera l’API Servlet 3.0.

• L’annonce sur la ML
• La news d’InfoQ
• La page Jetty chez Eclipse
• La page Jetty chez Codehaus

Sonar 1.11

SonarSource nous gratifie d’une version 1.11 du désormais célèbre outil de suivi de qualité Sonar. Comme souvent, de nombreux de bugs ont été corrigés. Parmi les améliorations, on peut noter les passages à Hibernate 3.3 et GWT 1.7. Au chapitre des nouvelles fonctionnalités, la possibilité de réutiliser les fichiers de configuration PMD et CheckStyle définis dans le pom permettra de plus aisément éviter les doublons.

SonarSource tente de faciliter la vie des développeurs de plugins avec l’apparition d’un archétype Maven pour créer des plugins Sonar. D’autres nouveautés d’API, comme le filtrage de widgets suivant différents critères (comme le rôle utilisateur ou la langue choisie), ajoutent de la flexibilité.

• L’annonce sur le blog Sonar avec plein de jolies images.
• La release note.

RIA

Air ‘Athena’

Non, ce n’est pas une nouvelle marque de baskets, mais, comme les flexeurs le savent depuis le Flash Camp de mai, le nom de code de la future version de Adobe Air, la version 2.0. Comme on s’y attendait, celle-ci fonctionnera avec Flash 10 et Flex 4. Même si aucune date officielle n’a été avancée, Adobe dévoile peu à peu les principales évolutions de sa plate-forme, nouveautés répertoriées par Elad Elrom sur InsideRIA.
Commençons par celle qui nous semble vitale dans l’adoption de AIR / Flex à grande échelle, à savoir une amélioration drastique des performances. Les équipes d’Adobe ont mis l’accent sur la réduction des ressources (CPU et mémoire) consommées par le runtime AIR. Les tests effectués sur une mini application montrent en effet une diminution des ressources utilisées (en regard de la version 1.5). Reste à tester ces optimisations sur une application gourmande… Toujours au chapitre performance, Adobe promet une optimisation de Webkit (le browser open source embarqué par AIR) et une installation Linux native.
Au menu des nouveautés, nous avons :

• Une meilleure connaissance de la plate-forme matérielle, avec la gestion des devices multi-touch et la gestion des périphériques de stockage USB ou réseau ‘à chaud’.
• Un enrichissement des fonctionnalités des APIs existantes : points de sauvegarde dans les transactions, support IPv6, augmentation de la taille maximale de la fenêtre AIR, manipulation des données de l’API Microphone, time-out d’inactivité…
• De nouvelles fonctionnalités via de nouvelles API, dont la plus étonnante est l’API File promises. Celle-ci permet de télécharger en local, depuis une application AIR, un ensemble de fichiers par simple Drag & Drop. D’autres API font également leur apparition, en particulier au niveau du support réseau et de l’adhérence de AIR à l’OS (les fichiers peuvent maintenant être ouverts par des processus natifs de l’OS, par exemple Notepad pour un .txt sous Windows).

Une évolution assez naturelle donc (correction des gros points de blocage des versions précédentes), mais quelques promesses de fonctionnalités intéressantes, en particulier via l’adhérence à l’OS.

DHTMLX 2.5

Des nouvelles de DTHMLX (la 11ème librairie de notre revue de presse de fin janvier dernier) qui est sorti il y a quelques semaines en version 2.5.

Cette release apporte plusieurs corrections et améliorations sur tous les composants de la suite. On retiendra plus particulièrement :

• Une API orientée objet (l’API fonctionnelle est toujours disponible) ,
• Nouvelle skin par défaut avec d’ici peu (mais non présent dans cette release) un Skin Customizer qui permettra de modifier facilement les couleurs principales du thème standard,
• Nouveau moteur de rendu qui améliore la performance d’affichage des composants Layout, Windows, Accordion et Tabbar,
• Une API de conteneurs unifiée (toujours pour les Layout, Windows, Accordion et Tabbar),
• Améliorations générales pour les composants Grid, Tree et TreeGrid,
• Révision complète du DocsExplorer.

Puisque nous sommes sur DHTMLX, notons aussi le composant Scheduler v.2.0, sorti en juillet dernier, qui n’est pas inclus dans la suite mais qui vaut tout de même le détour si vous avez besoin d’un composant calendrier haut niveau.

Les téléchargements se passent par ici et comme d’habitude vous aurez le choix entre le téléchargement composant par composant ou le téléchargement de la suite complète.
Chaque composant existe en édition standard ou professionnelle. Pour résumer la version standard contient moins de fonctionnalités et est sous licence GPL alors que la professionnelle contient toutes les fonctionnalités, un support prioritaire en cas de bugs/questions sur le forum et plusieurs centaines d’exemples de fonctionnalités avancées.
Pour le détail des licences et des différents prix proposés pour les composants et pour la suite complète, cela se passe sur cette page.

Tips and Tricks Maven 2

Sonatype nous présente ici quelques nouveautés intéressantes de maven disponibles depuis la version 2.1 concernant les projets multi-modules. Cela se traduit par de nouvelles commandes disponibles telles que:

• -rf, -resume-from: permet de spécifier au maven reactor le projet à partir duquel on veut reprendre le build
• -pl, -projects: permet de sélectionner une liste de modules d’un projet multi-modules
• -am, -also-make: combinée avec l’option -pl, elle permet de construire tous les modules dépendants du module passé à l’option pl
• -amd, -also-make-dependents: combinée avec l’option -pl, elle permet de construire tous les modules qui ont une dépendance vers le module passé à l’option pl

Très bonne nouvelle donc pour les développeurs dont le build prenait beaucoup de temps à cause de la reconstruction de modules non modifiés (et non impactés) par leurs nouveaux développements.

Le coin de la technique

Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas

Le Denim Group continue sa série 13 Things a Web Applications Attacker Won’t Tell You que nous avions traitée la semaine dernière avec 5 nouvelles failles de sécurité de nos applications web :

• Ce n’est pas parce que vous utilisez un framework de sécurité que votre application est sécurisée.
• Je n’utilise pas un browser pour attaquer votre application web.
• J’adore quand votre site me permet d’uploader des fichiers dans l’arborescence des répertoires servis par l’application web.
• Je peux intercepter et voler toutes les informations qui passent sur HTTP si elles ne sont pas protégées par SSL ou un mécanisme équivalent.
• Une sécurité obscurantiste n’en est pas une (ne pas savoir faire ou se dire que ca n’arrivera pas ne protège pas).

Si le dernier point est un débat éternel chez les experts de la sécurité les premiers sont en revanche communément admis.

Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Rémi Forax, un contributeur sur OpenJDK et sur la JSR-292, a fait part de son étonnement en constatant un gain significatif de performance entre deux builds successifs de l’OpenJDK 7 actuellement en cours de développement. C’est ainsi qu’il a pu se rendre compte que deux optimisations majeures du compilateur JIT de la JVM étaient activées par défaut depuis le build 72 du projet : l’escape analysis et la compression de pointeurs. Celles-ci étaient apparues dans le JDK 6u14 mais n’y étaient pas activées par défaut.

Pour rappel l’escape analysis consiste en l’analyse du bytecode d’une méthode pour découvrir les références vers les objets qui ne « s’échappent » pas du contexte de la méthode. Grâce à cette analyse, la JVM peut alors décider d’allouer ces objets directement sur la stack plutôt qu’en heap comme c’est normalement le cas. Il en résulte un gain de performance évident puisque le coût d’allocation et de libération de mémoire est alors supprimé pour ces objets.

La compression de pointeurs, quant à elle, concerne uniquement les JVM 64 bits. En effet le passage d’un adressage de 32 à 64 bits entraîne une consommation plus élevée de la mémoire du fait de l’augmentation de la taille des pointeurs, induisant elle-même des temps de chargement plus longs et une surconsommation du cache du processeur. Pour palier ce problème, la compression de pointeurs se base sur le fait que la JVM aligne l’adresse des objets sur 64 bits (ceci afin de simplifier et donc d’accélérer leur accès en mémoire), pour procéder à un scaling des pointeurs. Ainsi, en limitant l’espace mémoire adressable à 32 Go, il est possible de contenir un pointeur dans 32 bits et donc de revenir à une consommation mémoire proche de celle d’une JVM 32 bits.

L’activation par défaut de ces deux optimisations sur le JDK 7 montre que l’équipe du projet estime désormais qu’elles ne sont plus expérimentales et qu’elles conviennent dans la majorité des cas. Ismael Juma précise par ailleurs qu’il est possible que ces activations par défaut soient reportées également au JDK 6 courant 2010.

Actualité éditeurs / SSII

• Google essuie les plâtres et met à jour l’Android NDK
• MIDP 3 et MSA 2 pour sauver J2ME ?

Agilité

• Départs de la Scrum Alliance : bruits de couloirs

RIA

• Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le coin de la technique

• Les roadmaps des implémentations de JPA 2.0
• Web Beans est mort ! Longue vie a Weld !

Actualité éditeurs / SSII

Google essuie les plâtres et met à jour l’Android NDK

Pour rappel, le NDK est un environnement de développement complémentaire au SDK qui permet d’utiliser des langages autres que Java pour développer sur Android. Ce NDK est principalement dédié au développement C et C++. Parmi les nouveautés de la version 1.6, vous trouverez :

• Les librairies OpenGL ES 1.1 qui rapprochent encore un peu Android de l’IphoneOS.
• Ciblage de version Android pour garantir le fonctionnement de votre application.
• Possibilité de mélanger les sources Java et le code natif dans un même projet.

Mais la semaine passée fût aussi l’occasion d’une joute entre Google et certains développeurs Android. Sujet de la discorde, le CyanogenMod une version libre, modifiée, d’Android. Google n’a pas apprécié le fait que son développeur ait la riche idée de distribuer avec son mod, les applications propriétaires qui lui sont chères. Citons par exemple : GMail, YouTube, Maps et Market. Nul besoin de dire que le système perd de son intérêt quand il est privé de ces outils estampillés Google…

Le spécialiste de la recherche a donc demandé l’interruption de toute distribution de ce mod, en attendant que le développeur trouve un moyen de livrer de l’Android sans aucune des G-Apps. C’est un baptême du feu pour ce système que Google a voulu ouvert. D’aucun disent que Google avait la possibilité de créer une alternative libre au jardin d’Eden d’Apple entouré de hauts remparts, à la place ce sera un autre jardin avec des murs un peu plus bas.

MIDP 3 et MSA 2 pour sauver J2ME ?

Mobile Information Device Profile (MIDP), associé à Connected Limited Device Configuration (CLDC) constitue l’API de base de J2ME, c’est cette architecture qui constitue le parc de 2 milliards de devices revendiqués par SUN.

La JSR-248 (Mobile Service Architecture), quant à elle, définit un ensemble d’APIs additionnelles pour les environnements MIDP J2ME apportant chacune un service particulier permettant souvent d’accéder à des fonctionnalités matérielles sous-jacentes (Bluetooth, GPS, Camera, …).

Ces deux piliers de J2ME sont en train d’évoluer avec la finalisation de MIDP 3 et MSA 2. Tandis que le premier apportera un rafraichissement de l’API de base de J2ME, le second poussera plus loin les possibilités d’intégration des applications mobiles J2ME.

Alors que les valeurs montantes du moment dans le monde du développement mobile sont clairement les plates-formes Android et iPhone, le rafraîchissement des APIs J2ME vieillissantes est le bienvenue et viendra épauler JavaFX Mobile dans son hypothétique ascension. On peut toutefois douter que cela suffira à inverser la tendance même si J2ME, fort de son parc colossal, n’est clairement pas menacé à court terme.

Agilité

Départs de la Scrum Alliance : bruits de couloirs

Vous le savez surement, la fin de l’été a marqué un tournant au sein de la Scrum Alliance.
Le 15 Septembre, dans un communiqué laconique (et très américain – nous remercions … blablabla pour son excellent travail … blabla), il nous était annoncé le départ de deux éminents membres de la Scrum Alliance, Ken Schwaber (son CEO) et Jim Cundiff (son Managing Director).
Après une enquête acharnée et au détour de quelques indiscrétions de sources (que nous ne citerons pas), il s’avère que Ken a eu un grave accident de vélo et que Jim a été démissionné compte tenu de ses manquements dans la refonte du processus de certification dont il était en charge.

RIA

Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le Denim Group regroupe dans 13 Things a Web Applications Attacker Won’t Tell You les principales failles de sécurité de nos applications web :

1. Transformer une requête GET en POST ne cachera pas les paramètres même s’ils n’apparaissent plus dans la barre d’adresse du navigateur (vérifiez avec Charles Proxy ou Fiddler si vous en doutez).
2. Utiliser un champ de formulaire hidden ne permet ni de cacher une information ni d’empêcher sa modification.
3. Idem pour les cookies (voir #1).
4. Contrôler les données coté client avec du javascript ne m’empêchera pas de modifier leur valeur.
5. J’aime vous entendre dire « Cela n’arrivera jamais en production ».
6. Et j’adore quand vous dites « Un pirate ne ferait jamais ça ».
7. Je déteste les validations strictes cote serveur.
8. Cette page d’erreur avec le message détaillé me facilite tellement la vie.
9. La plupart des bannières « Sécurité Garantie ! » ne me servent qu’a voir que vous n’avez pas compris les bases de la sécurité.
10. Ce scanneur d’application web que vous avez lancé, il n’a rien trouvé. Il n’a même pas effleuré les failles de votre application.
11. Ce scanneur réseau que vous avez lancé, il n’a même pas commencé a tester la sécurité de votre application.
12. Je connais AJAX (et toutes les nouvelles technologies a la mode) mieux que vous et mieux que vous ne pouvez imaginer.
13. Le plus astucieux vous vous croyiez, le mieux je me sens.

Moralité, soyons humble et rigoureux, nous ne pourrons pas dire que nous ne savions pas, ces conseils sont répétés par la plupart des tutoriaux de frameworks web .

Le coin de la technique

Les roadmaps des implémentations de JPA 2.0

Alors que la JSR-317 (Java Persistence API 2.0) vient de diffuser une Proposed Final Draft 2 et que sa finalisation approche, nous souhaitions faire un tour d’horizon des principales implémentations en préparation. Comme c’est souvent le cas avec les JSRs, les développeurs n’attendent pas la finalisation des spécifications pour commencer à les implémenter. Ainsi, on se souvient que JPA 1.0, intégré à la JSR-220 (Enterprise JavaBeans 3.0) avait fait l’objet d’implémentations alpha chez JBoss dès la diffusion des early drafts, ce qui avait permis la stabilisation du conteneur peu après la finalisation de la JSR.

• Hibernate : l’équipe de développement Hibernate a annoncé fin aout la disponibilité d’une version 3.5 beta 1 qui implémentait la majorité des nouveautés de JPA 2.0. Aucune indication n’était alors donnée sur la date de finalisation, mais le bon avancement permet de supposer qu’elle arrivera rapidement. A noter toutefois que certaines optimisations importantes telles que la compilation des requêtes criteria n’arriveront que dans une version ultérieure.
• EclipseLink : la fondation Eclipse avait annoncé fièrement en début d’année 2008 qu’EclipseLink serait l’implémentation JPA 2.0 de référence. Une roadmap mise à jour en avril dernier fait état d’une version 2.0 d’EclipseLink implémentant JPA 2.0 pour l’automne 2009.
• Apache OpenJPA : le projet OpenJPA maintient une roadmap très rigoureuse tablant sur un démarrage de phase release candidate pour la fin de l’année. Il s’agira de la version 2.0 d’OpenJPA, elle est actuellement développée sur le trunk du projet.

La première version de la spécification JPA a été un succès puisque de nombreux développeurs ont reconnu sa légitimité et l’ont adopté dans leurs projets plutôt que de se reposer sur l’API propre à leur framework de persistance. Toutefois, pour certaines fonctionnalités telles que les requêtes criteria ou des options de mapping évoluées, il était jusqu’alors nécessaire de contourner JPA. Dès lors, on imagine aisément que JPA 2.0, comblant les manques de son ainée, bénéficiera d’une large adoption. La disponibilité des moteurs JPA 2.0 qui seront utilisés par JBoss AS, Glassfish et WebSphere autour de la fin de l’année devrait par ailleurs accélérer l’omniprésence de cette nouvelle API.

Web Beans est mort ! Longue vie a Weld !

Apres les bruits de couloir de la Scrum Alliance, nous continuons la rubrique people avec une fois encore Web Beans. Après le changement de nom de la JSR 299 en Java Contexts and Dependency Injection, voici que la Reference Implementation se rebaptise Weld.
Pendant ce temps, la JSR 330: Dependency Injection for Java continue son chemin avec son implémentation partielle dans Spring Framework 3.0 RC1 et son intégration dans Google Guice.

Actualité éditeurs / SSII

• Condamnation pour non respect de licence

RIA

• Chrome dans IE avec Google Chrome Frame

Le coin de la technique

• Guide utilisateur de Tellurium
• Lucene évolue et prépare l’avenir
• JBoss Microcontainer et son Virtual File System
• Injection de dépendances en Javascript …

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

• Devoxx 2009 : le planning des sessions est maintenant connu
• Asylum, un nouveau podcast dédié à JBoss

Actualité éditeurs / SSII

Condamnation pour non respect de licence

Qu’arrive-t-il lorsque l’on réutilise du code open source sans se soucier de sa licence ? On se fait taper sur les doigts. C’est en effet la mésaventure qui est arrivé à la société Edu4, comme le présente l’article de la Free Software Foundation France sur l’affaire.
Ayant fourni en 2000 à l’AFPA (un organisme de formation professionnelle) un logiciel basé sur VNC, Edu4 a reçu une requête de cet organisme demandant le code source du logiciel, conformément à ce qu’autorise la licence GPL.
Edu4, dans un premier temps, a refusé de fournir les sources de VNC modifiées par ses soins. Puis, à la suite d’une décision de justice de 2002, a fourni des sources ne correspondant pas à la version livrée et dans lesquelles le texte de la licence GPL de VNC avait été retiré.
Cette semaine, la cour d’Appel de Paris a reconnu Edu4 coupable.
Nous savons tous comment se passent les projets sur lesquels il y a une certaine pression et certains enjeux qui poussent à sortir des produits le plus vite possible sans mesurer toutes les conséquences. Nous ne jetterons donc pas la pierre à Edu4. Mais cette histoire permet de préciser que (1) la licence GNU GPL a bien valeur légale en France et que (2) n’importe quel utilisateur de logiciel basé sur la licence GNU GPL est en droit de réclamer les sources, et pas seulement les auteurs du code original (dans le cas présent, les auteurs de VNC n’ont pas participé au procès).

Il faut donc être bien conscient des conséquences que peut avoir la réutilisation de code open-source. Selon la licence (article de Wikipedia sur les licences du logiciel libre), il y a des obligations et des contraintes. Mais c’est bien là la moindre des choses pour pouvoir profiter de code déjà testé, éprouvé et amélioré par nombre de contributeurs. Cette prise de conscience est d’autant plus nécessaire que les composants open-source sont de plus en plus présents dans les SI des entreprises françaises. Pour un autre éclairage sur ces questions, on peut citer l’interview de Matt Light par ITRManager.

RIA

Chrome dans IE avec Google Chrome Frame

Une des sensations de la semaine dernière est l’annonce de Google Chrome Frame ou comment transformer Internet Explorer en Google Chrome.
On ne compte plus les sites ayant relayé l’information : cela passe par InfoQ, Ajaxian, Inside RIA ou encore TechCrunch.
Google Chrome Frame se présente sous la forme d’un plug-in pour Internet Explorer (6, 7 et 8). Le plug-in se lancera sur la balise suivante (ce qui implique donc que tous nos header HTML doivent être changés) :

<meta http-equiv="X-UA-Compatible" content="chrome=1">

À partir de là, 2 possibilités :

• Le plug-in est installé : il détecte le tag et lance le moteur de rendu de Chrome (WebKit) dans IE
• Le plug-in n’est pas installé : la page s’affiche normalement dans IE mais il est possible de rediriger l’utilisateur vers une page d’installation

Les avantages sont multiples : on retiendra de nombreuses optimisations de performances Javascript, un chargement de page plus rapide mais aussi l’utilisation de HTML 5 avec le offline et les canvas.
Il sera alors possible, comme le rappelle InfoQ, pour Google Wave d’offrir une expérience utilisateur complète à tous les utilisateurs d’Internet Explorer (en effet, celui-ci utilisera de nombreuses fonctionnalités de HTML 5).
Le support d’IE continuera comme le rappelle Lars Rasmussen (Team manager de Google Wave) qui insiste aussi sur le fait que les différentes versions d’IEs ralentissent l’élaboration d’applications web dîtes riches (avec des quick fixes à n’en plus finir pour obtenir des résultats présents out of the box chez les autres navigateurs).

Plusieurs réactions ont suivi cette annonce. On pourra retenir celle de Robert Nyman (par Ajaxian) qui rappelle fort justement que les utilisateurs restant sur de vielles versions d’IEs sont (pour résumer grossièrement) :

• soit des utilisateurs qui ne savent pas ce qu’est un navigateur (et donc n’installeront jamais ce plug-in)
• soit (malheureusement pour ceux qui y sont confrontés) des sociétés qui bloquent les mises à jours logicielles (il sera donc peu probable que le plug-in soit autorisé à être installé)

Dion Almaer se pose la question de l’inversion des rôles quant à l’expérience utilisateur : est-ce au développeur de choisir (forcer ?) le renderer/navigateur à utiliser ?
En tous cas, on ne peut que saluer le travail effectué et espérer que cela aidera, ne serait-ce qu’un peu, à réduire les IE 6 de ce monde

Le coin de la technique

Guide utilisateur de Tellurium

Tellurium nous annonce la sortie de son guide utilisateur version 0.6.0.
En 5 chapitres, celui-ci parcourt :

• Les concepts et fonctionnalités principaux de l’outil
• Un Getting Started
• Les sous-projets de Tellurium (archetype Maven, TrUMP…)
• L’architecture de Tellurium
• Ses APIs (DSLs, data access…)

Le PDF se récupère à cette url.
Et pour un petit aperçu du projet, je vous renvoie vers notre article sur comment améliorer l’écriture de vos tests selenium.

Lucene évolue et prépare l’avenir

Le projet Apache Lucene annonce la disponibilité de la version 2.9 du célèbre framework de recherche d’information. La liste des changements est conséquente.

Shalin Shekhar Mangar, committer sur Apache Solr, faisait part il y a quelques mois d’une activité très dense sur le projet Lucene pour préparer cette nouvelle version. Il expliquait alors que la majorité du travail était imputable au near real-time search, amélioration permettant de refléter très rapidement les modifications des données dans les résultats des requêtes alors que celles-ci sont habituellement rendues visibles seulement après le commit des changements dans l’index.

Outre cette nouvelle possibilité de recherche en temps réel, les principaux apports de Lucene 2.9 :

• Optimisations portant sur la mise en cache de segments inchangés de l’index, apportant un gain significatif de performance
• Gestion plus efficace des champs numériques avec l’ajout des classes NumericField et NumericRangeQuery. Il en résulte un gain de performance sur les requêtes par intervalles
• Support des requêtes géo-spaciales (module contrib/spatial)
• Nouveaux analyzers (PersianAnalyzer, ArabicAnalyzer, et SmartChineseAnalyser)
• Diverses améliorations d’API notamment sur le Collector / Scorer et le QueryParser

Par ailleurs, Lucid Imagination, une société américaine d’expertise Lucene, propose un webinar sur les nouveautés de cette version. On y retrouve également les plans pour la version 3.0 : les changements seront majeurs puisqu’il est prévu de passer l’API à Java 5 et de supprimer les éléments précédemment dépréciés.

La documentation du projet évolue également mais reste moins fournie qu’on ne le souhaiterait et les développements avec Lucene doivent souvent être accompagnés de l’ouvrage Lucene In Action paru chez Manning. Ce livre paraîtra dans une seconde édition, mise à jour pour la version 3.0 du framework, en mars 2010.

Cette activité dense de l’équipe Lucene est en rapport avec l’importance que prend ce projet dans la mise en œuvre des nombreux cas d’utilisations issus du Web moderne, tels que les recherches intelligentes et rapides, les systèmes de suggestions, et les analyses de contenu.

JBoss Microcontainer et son Virtual File System

Le projet Microcontainer de JBoss est le noyau de la version 5.0 du serveur d’application de l’éditeur sortie en fin d’année dernière. Il remplace le Microkernel JMX qui était utilisé jusqu’alors dans les version 4.x de JBoss AS. Le choix d’un tel noyau développé en interne avait fait l’objet de quelques remarques lors de son développement puisqu’il offre des fonctionnalités très classiques telles que la gestion du cycle de vie de ses composants, l’injection de dépendances et de propriétés, et des fonctionnalités d’AOP.

Ce Microcontainer s’illustre malgré tout par son système de déploiement reposant sur une abstraction très flexible encapsulant le chargement de ressources qu’elles soient sous forme de Jar, de fichiers, ou de répertoires : le Virtual File System. Cette fonctionnalité très puissante est malheureusement très peu documentée dans le manuel utilisateur du projet. Sa bonne maîtrise est pourtant souhaitable pour bien comprendre le comportement et les possibilités du déploiement d’applications dans JBoss AS 5.0 ou encore (scénario certes beaucoup moins courant) pour utiliser directement le Microcontainer dans un projet.

Ce manque de documentation est maintenant partiellement comblé grâce à Ales Justin, travaillant chez JBoss sur leur serveur d’application, qui a mis en ligne un article sur VFS. Cet article fait suite à deux articles précédents sur le modèle de composants et l’injection de dépendances dans JBoss Microcontainer.

Il y présente l’architecture de VFS et les abstractions et APIs mises en œuvre. On découvre alors des interfaces très claires et on se rend compte qu’il est envisageable de développer son propre protocole pour VFS afin de permettre le chargement de ressources depuis n’importe quelle source de stockage (réseau, base de données, repository, …).

Au-delà de la compréhension de cette architecture et de son comportement standard, on retiendra donc cette possibilité d’adapter le déploiement des applications sur JBoss AS 5.x à l’infrastructure mise en place dans l’entreprise, et ce, pour un coût raisonnable.

A noter que l’auteur annonce que le prochain article portera sur le système de classloading du Microcontainer. A suivre donc …

Injection de dépendances en Javascript …

Dans la série pourquoi faire simple quand on peut faire compliqué, à l’heure où Spring vient d’annoncer la sortie de la version 3-RC1 de son framework, à l’heure où Google sort son nouveau framework web sitebricks basé sur Google Guice, son framework d’injection de dépendances, pourquoi ne pas abandonner tout cela et gérer vous-même l’injection des dépendances de votre application Java en … Javascript ! C’est ce que nous propose l’auteur de cet article.

S’il est clair que vous n’allez pas jeter votre framework préféré dés la lecture de ce billet, cette solution
a tout de même le mérite, en plus d’être originale, d’utiliser uniquement les fonctions du JDK : Scripting API + proxy dynamique.

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

Devoxx 2009 : le planning des sessions est maintenant connu

Devoxx (anciennement JavaPolis) est la première conférence Java au niveau européen et la seconde au niveau mondial, après JavaOne. L’édition 2009 se déroulera du 16 au 20 novembre et devrait, cette année encore, réunir plus de 3000 personnes.

Le planning des sessions est maintenant connu, ce qui permet d’observer les tendances du moment. On dégage ainsi une présence marquée du Cloud Computing, de JDK 7 et des langages alternatifs pour la JVM, notamment Scala.

On peut également noter quelques sessions particulièrement alléchantes telles que :

• Le keynote de Steven Harris (Oracle, Product Development & Server Technologies)
• Le keynote d’Ivar Jacobson
• Distributed Programming the Google Way par Gregor Hohpe (l’auteur de Enterprise Integration Patterns), qui présentera les technologies mises au point par Google (MapReduce, GFS, Sawzall, Chubby, Protocol Buffers, …) pour rendre leurs applications distribuées optimales et surtout réalisables
• The Modular Java Platform & Project Jigsaw par Mark Reinold, qui permettra de faire le point sur cette technologie clé du JDK 7 qui est encore peu documentée.
• Maven 3 par Jason van Zyl (créateur de Maven)

En outre, pour ceux qui n’auraient pu assister à la présentation de JEE 6 par Antonio Goncalves au ParisJUG en début d’année, ou qui souhaiteraient être au fait des dernières évolutions, il présentera de nouveau une session sur ce sujet à Devoxx.

L’édition 2009 s’annonce donc aussi riche que les précédentes, ce qui laisse présager que, comme les années passées, les places seront toutes vendues 1 ou 2 semaines avant le début de la conférence, alors ne tardez pas à vous inscrire si vous êtes intéressés !

Asylum, un nouveau podcast dédié à JBoss

JBoss Community Asylum est un nouveau podcast créé par Max R. Andersen (JBoss Tools), Emmanuel Bernard (Hibernate), et Michael Neale (Drools) dont le contenu sera entièrement centré sur l’actualité et les informations relatives à la communauté JBoss.

Le premier épisode est en ligne et revient sur la conférence JBoss World et les nouveautés qui y ont été présentées, notamment :

• Infinispan, une évolution majeure de JBoss Cache
• REST-*, un ensemble de spécifications de services pour REST
• GateIn, le nouveau portail issu du partenariat entre JBoss et eXo
• TorqueBox, un conteneur d’applications Ruby On Rails pour JBoss AS
• HornetQ, la nouvelle version de JBoss Messaging
• Shrinkwrap, une API d’assemblage d’archives applicatives Java

Pour rappel, Emmanuel Bernard participe également à un podcast en français, les Cast Codeurs, dont le dernier épisode en date est disponible depuis hier.

Une reconnaissance méritée
C’est une très belle opportunité pour Jetty qui était jusqu’à présent beaucoup plus embarqué que Tomcat par des grands projets de Cloud Computing (Google App Engine, Hadoop, Gigaspace XAP, etc) mais n’avait pas constitué sa propre offre.

Sur les pas d’Amazon ?
Le mariage d’Intalio avec Webtide est assez différent de celui de SpringSource avec VMWare et Cloud Foundry. Alors que la deuxième union concerne des spécialistes de l’infrastructure, Intalio est lui issu de l’univers des applications CRM et s’étend vers les infrastructures de Cloud Computing comme l’a fait Amazon auparavant.

Des serveurs J2EE lourds absents
Nous remarquerons à l’occasion que les serveurs J2EE heavyweight se font très discrets dans cette période d’avalanche d’annonces sur Java Platform as a Service, on peut s’attendre à ce qu’ils répondent sur cette tendance qui va bouleverser les modes de fonctionnement dans les data centers et menacer leurs parts de marché.

Ils en parlent

• L’annonce officielle par Intalio
• L’annonce par Greg Wilkins, co-fondateur de Webtide
• InfoQ : Intalio acquires Webtide

Architecture

• Gartner adopte le pragmatisme avec l’Architecture Émergente

Actualité éditeurs / SSII

• JBoss HornetQ

RIA

• BlazeMonster

Le coin de la technique

• Liste finale des évolutions du langage Java apportées par le JDK 7
• Fin d’Eclipse RCP, place à…
• TestSwarm

Architecture

Gartner adopte le pragmatisme avec l’Architecture Émergente

Gartner nous livre un plaidoyer pour la pragmatisme avec Emergent Architecture. La formulation est parfois compliquée mais on se réjouira de trouver la responsabilisation des équipes sur le terrain et des Architectes d’Entreprise évangélistes de lignes directrices. Pour reprendre une expression chère au Lean Manufacturing, « Empower the People » :

1. Non déterminisme – Dans le passé, les architectes d’entreprise prenaient des décisions centralisées qui s’appliquaient à tous. Dans une architecture émergente, ces architectes d’entreprise doivent au contraire décentraliser la prise de décisions pour permettre l’innovation.
2. Acteurs autonomes – Les architectes d’entreprise ne peuvent plus contrôler tous les aspects de l’architecture comme ils le faisaient auparavant ; ils doivent désormais reconnaître l’étendue et la variété du SI ; ils doivent déléguer le contrôle aux équipes sur le terrain.
3. Limiter les contraintes aux lignes directrices – Jusqu’à présent, les architectes d’entreprise ont fourni des spécifications détaillées de tous les aspects de l’architecture ; ils doivent désormais limiter leurs prescriptions aux lignes directrices et de permettre le choix.
4. Acteurs orientés objectif – Auparavant, les seuls objectifs qui comptaient étaient les objectifs de l’entreprise mais cela s’est maintenant déplacé et chaque acteur agit dans ses propres intérêt. Il ne faut pas pour autant oublier les lignes directrices.
5. Influences locales: Les acteurs sont influencés par des interactions locales et des informations limitées. Les feedbacks au sein de leur sphère de communication modifie leur comportement. Aucun acteur individuel ne possède la vision globale d’un système émergent. Les architectes d’entreprise doivent intensifier leur travail coordonner et de transmission de l’information.
6. Systèmes dynamiques et adaptatifs: le système (les différents acteurs et leur environnement) changent avec le temps. Les architectes d’entreprise doivent définir les pourtours des systèmes émergents et ajuster en fonction des changements.
7. Environnement aux ressources limitées: L’abondance, les budgets illimités, ne permet pas de créer une architecture émergente ; c’est au contraire la rareté des moyens qui permet une architecture émergente.

Actualité éditeurs / SSII

JBoss HornetQ

Après 2 ans de développement, le projet JBoss Messaging 2.0 sort enfin dans les bacs sous le nom HornetQ. Ce Message Oriented Middleware n’est pas une évolution de son prédécesseur qui continue d’exister dans sa version 1.0, mais belle et bien une réécriture (presque) intégrale. Redhat nous le vend comme un MoM opensource, multi-protocol, embarquable, haute performance, réparti, et asynchrone.
HornetQ peut-être utilisé en standalone ou bien embarqué dans un serveur d’application JBoss AS par exemple. Chose appréciable, HornetQ est léger, il dépend uniquement du JDK (5 minimum) pour être complètement fonctionnel.
Dans sa présentation, Redhat nous annonce que le projet est facile d’utilisation avec une documentation déjà très complète et la bagatelle de 65 exemples de codes sources. Il est même possible de démarrer en moins de 5 minutes.
HornetQ bénéficie d’une conception orientée Pojo qui lui permet d’être utilisé directement dans Spring ou Guice. La performance a fait l’objet d’une attention importante, avec un journal haute performance et JBoss Netty pour la scalabilité.
JBoss nous livre une liste sans fin des fonctionnalités embarquées parmi lesquels on retiendra:

• JMS 1.1
• JTA
• Adaptateur JCA

Enfin, l’editeur annonce orienter ses développements vers le support d’API RestFull qu’il voit comme le futur du cloud computing. Redhat souhaite donc pousser la porte des clouds privé en tentant de s’imposer comme le provider de message incontournable dans le nuage.

• Site du projet
• Wiki

RIA

BlazeMonster

BlazeMonster vient de sortir dans sa deuxième version. Pour rappel cet outil, basée sur la technologie AIR, permet le support et l’aide à la génération de code pour consommer/exposer des services Java en tant que service Remote pour BlazeDS ou LCDS (LiveCycle Data Services).
Parmi les supports, nous avons entre autre :

• Génération des fichiers de configurations : déclarations des services, channels..
• Génération du code appelant le service Remote
• Génération des beans ActionScript (Value Object)
• Visualisation des réponses des services Remote

Dans cette deuxième version, BlazeMonster intègre le support de Spring BlazeDS, permettant la génération de services Remote en utilisant cette librairie. Je vous invite à jeter un coup d’œil sur les autres corrections et évolutions apportées à ce projet ici.
Facile d’utilisation, ce projet permet de copier/coller des morceaux de code dans votre application, facilitant le développement.
Enfin, à travers ce projet nous voyons, une fois de plus, l’engouement que les technologies Flex et BlazeDS remportent. Peut être pouvons nous espérer l’intégration de ce type d’outil dans le Flash Builder 4. Alors messieurs d’Adobe, qu’attendez vous ?

Le coin de la technique

Liste finale des évolutions du langage Java apportées par le JDK 7

En début d’année, Sun a initié le Project Coin, un sous-projet d’OpenJDK visant à recueillir les propositions d’évolutions du langage Java pour le JDK 7 prévu pour début 2010. Les soumissions ont été nombreuses et Joseph D. Darcy, leader du projet, informait régulièrement la communauté sur l’avancement du processus de sélection. C’est maintenant la liste finale des évolutions qu’il annonce. Sauf problème de planning, il s’agit donc là de ce que le langage Java sera dans JDK 7 :

• Clause switch utilisable sur les String.
• Gestion automatique des resources. Cette évolution vise à simplifier la gestion de la fermeture des flux ou autre ressources par l’utilisation d’une clause try spécifique pour les objets implémentant l’interface Disposable introduite dans le JDK pour l’occasion.
• Inférence de type améliorée pour la création d’objets génériques grâce à une syntaxe du type List<String> list = new ArrayList<>().
• Evolution de la gestion des warnings pour l’utilisation des generics dans des varargs.
• Autorisation de la notation binaire pour les entiers comme en C/C++ et possibilité de placer des underscores dans les nombres pour en simplifier la relecture tel que long creditCardNumber = 1234_5678_9012_3456L
• Accès en lecture et écriture aux valeurs des collections Java par la notation utilisé jusqu’alors uniquement pour les tableaux.

On est loin de la liste d’évolutions très audacieuses initialement prévue pour JDK 7, mais les évolutions finalement retenues ont l’avantage d’être réalistes en terme de temps d’implémentation, tout en apportant un confort supplémentaire au quotidien pour les développeurs Java.

Rémi Forax, très au fait des développements sur l’OpenJDK, propose d’ailleurs son analyse des tâches restant à accomplir et de leur complexité pour chacune des évolutions.

Fin d’Eclipse RCP, place à…

Après Java Rebel, c’est Eclipse RCP qui se trouve sur la voie du changement de nom.
Cette fois-ci, ce n’est pas pour une raison de marque déposée mais tout simplement, dixit l’auteur, parce que ce nom est horrible .
Un vote est organisé avec tous les noms remontés par la communauté Eclipse depuis 3 mois.
Alors, Aurora, Montage ou Tangram, c’est à vous de voter ! Et ça se passe sur cette page.

TestSwarm

John Resig, créateur de jQuery, nous annonce que Test Swarm est maintenant ouvert au public (par ajaxian).

Test Swarm permet de tester le code Javascript sur différents navigateurs de différentes plateformes de manières continues. A l’origine utilisé pour jQuery, il est désormais possible de tester son propre code Javascript, moyennant 8 steps d’installation paragraphe Setting Up Your Own Swarm. Les tests (jobs) peuvent être lancés à chaque commits (SVN ou Git) ou bien en appelant une URL spécifique. Les résultats des tests sont résumés dans un tableau avec une colonne pour chaque navigateur/plateforme. Il est possible de rester au niveau projet mais on peut affiner l’affichage au niveau commit voir au niveau de chaque fichier js de tests. Côté couleur, les tests vert se sont bien passés, les rouges contiennent au moins une erreur, les noirs ont au moins une erreur critiques et les gris sous en cours/en attente. Des logs sont disponibles pour chaque run de tests et permettent de voir ceux qui ne seraient pas passés.

Les frameworks de tests unitaires Javascript gérés (bien d’autres suivront) sont pour l’instant :

• QUnit (jQuery)
• UnitTestJS (Prototype)
• JSSpec (MooTools)
• JSUnit
• Selenium
• Dojo Objective Harness

Une vidéo de type quick tour nous donne un bon aperçu du site. Plusieurs directions sont possible concernant la roadmap du produit dont l’intégration à l’IDE, tests sur encore plus de browser… Un produit à suivre.

Erreurs humaines, interventions « pompier », manque de prédictibilité, complexité des guides et procédures de mise en production, manque d’évolutivité des scripts, frictions entre les départements Etudes et Production, mises à jour des middleware et des applicatifs coûteuses sont autant de maux que rencontrent les utilisateurs des technologies Java/J2EE.

Fort de nos 8 ans d’expérience dans la conception, la mise en place et la gestion d’applications et d’infrastructures basées sur Java/J2EE chez plus de 200 clients en Europe, Xebia a créé DeployIT, une offre logicielle, exclusivement dédiée aux déploiements Java/J2EE.

DeployIT permet de sécuriser et de réduire les coûts des déploiements des applications et des infrastructures Java/J2EE, jugés de plus en plus périlleux, coûteux et aléatoires.

Xebia Labs propose donc une plateforme logicielle incluant les spécificités des applications et infrastructures Java/J2EE, adossée à une approche méthodologique éprouvée, offrant les avantages suivants :

• Réduction des risques d’échecs des déploiements liés aux trop nombreuses interventions humaines.
• Réduction des coûts liés au développement et à la maintenance de scripts coûteux et hétérogènes.
• Suppression des interventions « pompier » des équipes de développement pour aider les cellules d’exploitation à mettre en production.
• Réduction du Time to Market des nouvelles applications ainsi que de leurs évolutions fonctionnelles.
• Standardisation autour d’un outil commun des départements Etudes et Production.
• Garantie des SLA par une professionnalisation de la filière de déploiement.

Pour avoir plus d’informations sur cette solution, n’hésitez pas à contacter Luc Legardeur au 01 42 91 27 93 ou par mail : llegardeur@xebia.fr.

Actualité éditeurs / SSII

• SpringSource lance CloudFoundry

SOA

• David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

Le coin de la technique

• Acquisition d’Ehcache par Terracotta, nécessaire et suffisant ?
• ChromeDevTools
• Pas de Swing Application Framework dans le JDK 7

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

• Hadoop World 2009
• Sortie le 30 septembre de Google Wave Preview

Actualité éditeurs / SSII

SpringSource lance CloudFoundry

Rod Johnson l’annonçait jeudi dernier sur son blog, l’éditeur fait ses premiers pas dans le monde du cloud computing. Il s’agit en effet d’une interface web qui ne manque pas de rappeller Google App Engine permettant d’installer des applications Java sur le nuage. Dans cette première version, on nous propose de déployer des applications hébergées sur le fameux Spring Tc Server, avec out of the box, la supervision Hyperic, la possibilité d’utiliser une base de données MySQL, et évidemment le support de Grail, si cher à Rod.

Au menu, bien évidemment le support et la répartition automatique de la montée en charge. Pour le moment, le tout est déployé sur Amazon EC2, mais Rod espère bien le voir déployé prochainement sur vSphere (la solution de cloud computing de VMWare). Nous souhaitons longue vie à ce nouveau produit de SpringSource qui confirme une fois encore sa montée en puissance. Notez, tout de même pour information que c’est Chris Richardson et son équipe qui s’est chargé de la réalisation de CloudFoundry.

L’article de Cyrille Le Clerc sur SpringSource et Java Platform As A Service vous permettra d’y voir un peu plus clair sur la stratégie poursuivie par SpringSource.

SOA

David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

David Chappell a retrouvé une discussion qu’il a eu avec Ted Neward en 2008 sur SOA.

Au-delà de l’évocation des liens entre Service Oriented Architecture (SOA), Software as a Service (SaaS) et Cloud computing, nous retiendrons de cet échange : SOA a échoué à tenir sa double promesse « Réutilisation et agilité ».
L’agilité est une forme de réutilisation puisqu’elle permet de créer de nouveaux services en assemblant facilement des services existant. La réutilisation des services métiers a échoué, et par effet de bord, l’agilité n’a pas été obtenue. La réutilisation des services métiers est analogue à la réutilisation des objets métiers à la fin des années 90.
La cause de cet échec, pour SOA comme pour les objets métier, n’est pas technique mais principalement humaine. Les organisations n’ont pas créé les conditions pour inciter les équipes à partager leur travail ni à réutiliser le travail des autres (Cf. « Le syndrome Not Invented Here » et « Propriété des composants et Financement au projet« ).

En revanche, la réutilisation des objets techniques a réussi, les frameworks .Net et Java EE en sont des exemples. De plus, l’orienté objet a convaincu comme paradigme de programmation. Pour SOA, la réutilisation de services techniques comme la gestion de l’identité ou la couche d’accès aux données basiques fonctionne.

Il s’agit donc d’un échec du SOA tel qu’on nous l’a promis mais en revanche d’un succès de l’approche par service.

Pour ce qui est des ESB, il s’agit principalement d’un coup marketing des éditeurs de solutions d’intégrations mais aussi d’une évolution des paradigmes d’intégration : l’intégration par services à succédé à l’intégration par base de données.

Alors SOA est un échec ? Oui si l’on regarde les promesses initiales qui n’ont pas été tenues ; non si l’on voit les transformations orientées service qu’elle apporte.

Le coin de la technique

Acquisition d’Ehcache par Terracotta, nécessaire et suffisant ?

Le teaser largement propagé via Twitter et les différents blogs des acteurs de Terracotta est tombé. Terracotta a fait l’acquisition d’un des frameworks open-source les plus populaires du marché : Ehcache. Drôle de teasing, sous la forme d’un hash md5, pour une drôle d’annonce. Ce mariage ressemble plus à un arrangement entre amis qu’a un véritable rachat :

• Ehcache et Terracotta fonctionnent conjointement depuis bien longtemps.
• Ehcache est porté par une seule personne : Greg Luck.
• La vente de support Ehcache ne fonctionne pas vraiment, dixit Greg Luck.
• Le code source de Ehcache est très léger, et sa partie la plus complexe, le cache distribué, concurrence avec une grande simplicité Terracotta.

Alors, pourquoi avoir racheté Ehcache ?

Selon certains analystes, après le rachat de SpringSource, VMWare a la volonté d’élargir son portefeuille d’outils et de middleware Java, et Terracotta serait pressenti. C’est en tout cas l’hypothèse mise en avant par quelques gaillards de Terracotta (encore une fois, merci Twitter). Notre sentiment, trop de bruit pour que cela soit d’actualité. Par contre, il nous semble clair que Terracotta désire se faire racheter. Et pour cela, plusieurs problèmes doivent être réglés :

• Malgré les différentes versions, Terracotta suscite des résistances, en cause son approche bas niveau (JVM / Bytecode) qui freine bon nombre d’utilisateurs. D’ailleurs, Terracotta ne fonctionne pas avec toutes les JVM.
• L’utilisation de ce framework n’est pas transparente, quoi qu’en disent les documentations. Il est facile de se tromper sur le choix des objets à partager et les poses de lock. Tout cela fait qu’à l’utilisation, la mise en place de celui-ci est tout sauf triviale.

Et c’est là qu’Ehcache intervient !

• Mis en lumière par le cache L2 d’hibernate, Ehcache fonctionne également avec d’autres produits star comme Spring, Alfresco et Liferay. Il est devenu l’une des apis de cache les plus utilisées par les développeurs. On parle de plusieurs centaines de milliers de projets utilisant celui-ci. Avec ce rachat, Terracotta espère se rapprocher davantage de cette communauté en s’appuyant sur la bonne image d’Ehcache pour rassurer les développeurs.
• D’autre part, Terracotta gonfle sa stack logiciel et propose dans son portefeuille un mécanisme de cache distribué alternatif plus haut niveau.

Au final, petite annonce ? Pas si sûr ! Terracotta signe ici un joli coup de communication et se met dans les meilleures conditions en vue d’un éventuel prochain rachat.

ChromeDevTools

Pour ceux qui ne sont pas à l’aise avec le débogage Javascript par l’interface de Firebug ou tout simplement ceux qui souhaitent débugger intégralement leur application dans Eclipse, y compris le Javascript client, voici un petit outil (développé par Google) qui vous le permettra : le Google Chrome Dev Tools (par l’Eclipse Zone).

Le projet se compose du Chrome Dev Tools SDK, API Java permettant à une application en mode debug de communiquer avec le navigateur Google Chrome (localhost en TCP/IP) , et de l’Eclipse Debugger, le plugin Eclipse qui vous permettra de débugger votre application.

Ce dernier propose entre autres :

• Breackpoints
• Watches
• Step in / over / into
• Évaluation d’une sélection de texte
• Évaluation sur mouse hover
• Exceptions reportées dans la vue Error Log

Côté mise en place, il vous faudra au minimum, comme vous pouvez vous en doutez, un navigateur Google Chrome en version 3.0.189.0 (actuellement en beta) et un Eclipse 3.4.2. L’installation du plugin se fera par l’Update Site avec cette URL.
Il vous faudra ensuite lancer votre Chrome avec le paramètre --remote-shell-port=9222 (ou le port de votre choix) et définir, dans le menu Debug Configurations d’Eclipse, une nouvelle Chromium Javascript configuration avec le port spécifié pour Chrome. Et à partir de là, à vous les breakpoints et le debug de votre application dans Eclipse !

Pas de Swing Application Framework dans le JDK 7

Il y a quelques mois nous vous parlions de la disponibilité d’une roadmap détaillée pour le JDK 7. Elle incluait entre autre la JSR-296 (Swing Application Framework), une spécification destinée à simplifier le développement d’applications Swing grâce à :

• Des annotations @Action pour déclarer les actions Swing plus facilement qu’en sous-classant AbstractAction puis en redéfinissant la méthode actionPerformed()
• Gestion de l’enregistrement de l’état des fenêtres à la fermeture de l’application
• Simplification de la gestion des ressources
• Gestion du cycle de vie de l’application

Les apports sont intéressants car répondent bien aux réalités des projets Swing courants, mais n’y répondent que partiellement. En effet il aurait été interessant de voir se créer une synergie avec la JSR-330 (Dependency Injection for Java) afin d’apporter l’injection de dépendance aux applications client lourds. De plus, ce framework ne simplifie pas la définition des interfaces en Swing, opération se révélant souvent assez laborieuse en raison d’APIs vieillissantes et probablement trop bas niveau.

Alexander Potochkin nous apprend maintenant que cette JSR ne sera pas prête dans les temps pour la roadmap prévue et qu’en conséquence son intégration au JDK 7 est annulée. Dans ces conditions, les apports du JDK 7 à Swing seront quasi nuls, ce qui constituera une réponse bien peu satisfaisante aux débats ayant animé cette communauté il y a quelques mois.

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

Hadoop World 2009

La société Cloudera, spécialisée dans le support aux utilisateurs de Hadoop, a annoncé la première conférence mondiale consacré à Hadoop : Hadoop World. Cette conférence se tiendra à New-York City en octobre de cette année. Elle est soutenue par des sponsors de taille comme IBM, Intel et Yahoo.

Le nombre de candidat à la prise de parole est tellement important que l’agenda n’est pas encore fixé. Le thème sera « Hadoop is everywhere », on aura donc droit à des sujets aussi bien sur des applications utilisant déjà Hadoop, que sur les implications coté administration de parc.

Les inscriptions sont ouvertes …

Sortie le 30 septembre de Google Wave Preview

Présenté il y a quelques mois comme une évolution majeure de notre façon de communiquer en ligne, Google Wave sera bientôt disponible au public. 100 000 utilisateurs sont attendus une fois le service ouvert.

A l’heure actuelle, les développeurs qui ont pu testés ont eu de gros problèmes de disponibilité de la plateforme. Sur InfoQ, on apprend que pour le 30 septembre, l’objectif du responsable technique de Wave API, Douwe Osinga, est bien sûr d’améliorer la stabilité du système mais aussi d’ajouter des fonctionnalités à l’API. Par conséquent, il ne leur restait que peu de temps pour stabiliser le bac à sable.

Dans les nouvelles fonctionnalités, l’accent a été mis sur l’API liée aux robots qui est à présent ouverte. Grâce aux robots, on peut répondre de manière applicative à des évènement sur la wave, ce qui permet d’interagir avec les autres participants, ou d’échanger des informations avec des systèmes extérieurs.

Si vous souhaitez être averti de l’ouverture du service, inscrivez-vous. Vous pouvez même écrire un message d’encouragement à l’équipe de Google Wave. Ils en auront certainement besoin pendant le moins prochain…

Actualité éditeurs / SSII

• VMWare – SpringSource, pourquoi ?
• Les acteurs du marché du Complex Event Processing

Le coin de la technique

• iBatis suit les dernières tendances Java
• Apache HTTP Client 4.0 finalisé
• Tour d’horizon de CouchDB

Actualité éditeurs / SSII

VMWare – SpringSource, pourquoi ?

Pourquoi VMWare a racheté SpringSource dont le métier et la culture sont si différents ? Pourquoi un tel prix ?

Cyrille Le Clerc (Xebia) propose son analyse du rachat de SpringSource par VMWare : « Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud« .

Les acteurs du marché du Complex Event Processing

Paul Vincent, Tibco, a diffusé un récapitulatif des différents acteurs du marché du Complex Event Processing listant l’ensemble des éditeurs proposant des solutions classés par date d’arrivée sur ce marché.
Il y fait bien la distinction entre les produits se basant sur un système de requêtes temps réelles et ceux basés sur un système de règles.

Il est ainsi possible de visualiser l’arrivée successive des nombreux acteurs sur ce marché en pleine croissance. Par ailleurs on remarque qu’Esper est le seul moteur de requêtes CEP Open Source du marché tandis que Drools, grâce à sa récente version 5 est devenu l’unique moteur de règles CEP qui soit Open Source. Ces nouveaux entrants viennent ainsi perturber StreamBase, Coral8 et Progress sur leurs positions investies il y a plusieurs années.

Le coin de la technique

iBatis suit les dernières tendances Java

iBatis est un framework Apache souvent positionné face aux solutions ORM telles qu’Hibernate. En effet il adopte une stratégie différente puisqu’il ne cherche pas à créer un modèle objet au dessus du modèle relationnel, mais plutôt à faire un mapping objet des données d’entrée et de sortie des requêtes SQL. Traditionnellement ce mapping se décrivait par un lot de fichiers XML de configuration.

Début 2007, l’équipe des développeurs d’iBatis a créé une page Wiki pour recueillir les propositions pour une version 3.0 qui profiterait des nouveautés de Java 5 pour améliorer l’ergonomie de leur framework.

Après de longs débats, et développements, une série de 2 versions bêta a été diffusé. Une première version de documentation est également disponible, permettant de faire le tour des nouveautés les plus intéressantes :

• Ajout d’un SelectBuilder permettant de construire dynamiquement des requêtes SQL, remplissant ainsi un rôle similaire aux Criterias d’Hibernate. Ce builder offre aux développeurs un DSL interne très élégant basé sur une clause import static Java.
• Configuration du mapping par annotations. On dispose ainsi d’annotations @Insert, @Update, @Delete, @Select et @Result à placer sur les Pojos. L’équipe iBatis reconnaît par contre la possible lourdeur de ce modèle de configuration lorsque des mapping très complexes doivent être définis.
• Possibilité de créer des DAOs utilisant des generics en type de retour. Typiquement une méthode listAllEmployees() retournera un type List<Employee> et non plus un type List.

iBatis répond à un besoin réel, car il propose une solution de persistance dont le niveau d’abstraction est intermédiaire entre JDBC et JPA. On ne peut donc que se réjouir de ce rafraichissement de l’API, l’alignant ainsi sur les tendances du moment dans le monde Java que sont les annotations, les DSLs, et autres interfaces simplifiés, qui permettent d’améliorer la productivité du développement.

Apache HTTP Client 4.0 finalisé

La refonte du client HTTP d’Apache a été initiée il y a deux ans avec l’arrivée d’une première version alpha. Un an après arrivait une première version bêta. Apache annonce maintenant la disponibilité d’une version finalisée du projet.

Au fil des années un nombre croissant de projets se sont basés sur HTTP Client lui concédant ainsi une certaine omniprésence. Son intérêt par rapport au client HTTP standard de Java est d’offrir une plus grande richesse de fonctionnalités liées à une meilleure flexibilité d’utilisation.

Cette nouvelle version majeure est une réécriture totale du projet, expliquant donc son temps de gestation particulièrement long. L’architecture y est repensée pour offrir une meilleure modularité et des possibilités d’extensions supplémentaires. Le client est ainsi désormais constitué de deux modules :

• HttpCore apporte les fonctionnalités fondamentales du protocole HTTP et offre le choix entre un modèle d’I/O bloquant ou non bloquant en s’appuyant sur NIO.
• HttpClient se base sur HttpCore pour offrir des fonctionnalités supplémentaires de HTTP telles que la gestion des cookies et l’authentification.

Une documentation très complète est déjà disponible pour HttpCore comme pour HttpClient.

Tour d’horizon de CouchDB

Une présentation de CouchDB par Jan Lehnardt, développeur sur le projet, lors du QCon de novembre 2008 vient d’être mise à disposition. Elle offre un aperçu global de CouchDB qui permettra de saisir l’ensemble de ses intérêts. Ainsi les principales caractéristiques de cette base de données mises en avant sont :

• Base de données orientée documents : les informations sont groupées par documents qui sont stockés de manière versionnée.
• Optimistic locking : CouchDB se base sur un numéro de version stocké au sein du document.
• API Restful : les fonctions d’ajout, lecture, modification et suppression (CRUD) sont accessibles par une API Resful permettant ainsi une intégration triviale avec n’importe quel langage et plate-forme.
• Views : CouchDB n’offre pas de mécanisme de requête tel qu’on en trouve habituellement sur les bases de données relationnelles. Ici tout n’est que vue des documents générée dynamiquement par MapReduce.
• Réplication et résistance aux crashs : CouchDB supporte un mécanisme de réplication peer to peer lui permettant d’offrir une haute disponibilité des données sans effort supplémentaire.

Jan Lehnardt rappelle en outre que CouchDB est distribué sous licence Apache et que le projet est soutenu par IBM. Les lecteurs intéressés par CouchDB pourront également se tourner vers la documentation du projet ou encore vers le livre qui lui est consacré chez O’Reilly, prévu pour novembre, et d’ores et déjà librement accessible en ligne.

Mon analyse est que VMWare a racheté SpringSource parce que le cloud computing de forme Platform As A Service (PaaS) à la Google App Engine va bientôt mieux répondre que la virtualisation matérielle aux besoins d’optimisation des data centers Java. Selon l’adage « Si quelqu’un scie la branche sur laquelle je suis assis, mieux vaut que ce soit moi », VMWare s’est dotée de l’expertise de SpringSource sur Tomcat et Hyperic.
Je parlerai des applications Java légères (Servlets, JDBC, JPA et JMS) qui sont aujourd’hui largement majoritaires dans nos data centers Java. Billy Newport, IBM WebSphere, reconnait qu’elles représentent 80% des cas, SpringSource aurait sûrement des chiffres plus élevés.

• Optimiser la CPU des data centers
• Les atouts de la virtualisation matérielle
• Les limitations de la virtualisation matérielle pour Java
• Mutualisation en Java : De simples serveurs Linux-Tomcat suffisent
• Adaptation CPU et RAM en Java : Le modèle ‘scale out’
• Virtualisation matériel : Un marché plus concurrentiel et moins lucratif
• One size does not fit all : Concilier virtualisation matérielle et cloud pour optimiser l’utilisation des data centers

Optimiser la CPU des data centers

Les data centers débordent, l’électricité manque, les climatisations saturent, les planchers s’effondrent, les racks sont pleins et pourtant, les serveurs ne font rien, les CPU ne sont utilisées qu’à quelques pourcents !
La virtualisation matérielle, dont VMWare est un des leaders, propose d’adresser ce problème en introduisant une couche d’abstraction appelée hyperviseur entre le matériel et le système d’exploitation : plusieurs instances de système d’exploitation s’exécutent ainsi sur la même machine.
Considérons 10 serveurs qui consomment chacun en moyenne 5% de CPU, la virtualisation matérielle permet de les regrouper sur une seule machine physique qui atteindrait alors un taux d’utilisation de l’ordre de 50%. Malgré la chute du prix de la RAM, la mémoire vive de ce serveur mutualisé risque fort d’être insuffisante, l’hyperviseur règlera ce problème en recourant à la pagination de la mémoire (swap) comme un système d’exploitation le fait déjà à son niveau.
Et si par malheur ces serveurs venaient à être sollicités en même temps et à saturer la machine qui les héberge, les solutions de virtualisation parviennent maintenant à déplacer certaines instances sur d’autres serveurs physiques de façon transparente, sans même arrêter le service.

Les atouts de la virtualisation matérielle

Un atout essentiel de la virtualisation est le très faible coût d’adaptation des applications existantes puisqu’elles continuent à s’exécuter sur le même système d’exploitation avec le même voisinage. La virtualisation matérielle est transparente pour les applications, elle n’exige pas de changement de version du système d’exploitation, des librairies utilisées, des répertoires de travail ou des ports d’écoute.
Si une application est tellement exigeante qu’elle requiert une version de système d’exploitation dépassée ou qu’elle a été compilée avec la version très ancienne d’un driver de base de données, ce n’est pas grave. La virtualisation matérielle maintiendra cette application revêche isolée dans sa bulle et elle sera mutualisée comme les autres.
Un autre atout de la virtualisation est l’adaptation de la CPU et de la RAM allouée à chaque application selon ses besoins. De la même façon qu’un système d’exploitation sait allouer du temps CPU et de la RAM à une application qui a un pic d’utilisation, l’hyperviseur sait privilégier une instance parmi toutes celles qu’il exécute simultanément. Considérons 20 applications qui s’exécutent chacune sur un serveur bi-processeurs, la virtualisation matérielle permet de les regrouper sur un seul serveur quadri-processeurs et en cas de pic, allouer quatre processeurs à une seule application, le double de ce qu’offrait la solution non virtualisée.

Les limitations de la virtualisation matérielle pour Java

La première limitation de Java à la virtualisation matérielle est la gestion de la mémoire par les machines virtuelles. Les JVM assument que toute la mémoire qu’on leur alloue est en RAM, elles accèdent indifféremment à tout cet espace mémoire et le parcourent intégralement très souvent pour les garbage collections. De ce fait, la performance des applications Java s’effondre dès que leur mémoire est paginée. Pire encore, certains composants comme les timers des caches ou des gestionnaires de transactions échouent lorsque les temps de réponse sont anormalement longs et les applications tombent alors en erreur.
Ce problème est d’autant plus crucial pour la virtualisation matérielle que, du fait des techniques de garbage collection, les JVM libèrent peu de mémoire quand les applications sont moins utilisées.
Par ailleurs, l’adaptation à l’exécution de la CPU et de la RAM allouée à chaque application selon ses besoins est inadaptée en Java.
Le premier point bloquant est que l’espace mémoire utilisé par une JVM est défini au démarrage (Xmx) et ne peut changer lors de l’exécution. Ensuite, augmenter la puissance de traitement d’une application web Java nécessite non seulement d’allouer de la CPU et de la RAM, mais aussi de redimensionner les pools de threads http ou de connexions à la base de données ainsi que la taille de nombreux caches applicatifs (sessions http, objet venant de la base, etc).
Il faudrait donc que l’hyperviseur change les configurations Java, cela nécessite aujourd’hui d’interrompre le service pour redémarrer les applications. La promesse de transparence de la virtualisation matérielle devient caduque, le palliatif est d’avoir des middlewares qui interagissent avec la virtualisation matérielle.

Mutualisation en Java : De simples serveurs Linux-Tomcat suffisent

Si certaines applications sont revêches à la mutualisation, Java fait plutôt preuve de très bon voisinage.
Une application Java est quasiment agnostique du système d’exploitation et des libraires qui l’entourent, il lui suffit d’un répertoire pour ‘dezipper’ une JVM (<20 Mo), un moteur d'exécution (Tomcat < 5 Mo) et l'application.
Cette facilité d'installation est utilisée au quotidien. Nous développons sous Windows, MacOS ou Ubuntu pour déployer sur RHEL, AIX ou Solaris. Beaucoup d'équipes qui déploient en production sur un 'gros serveur' J2EE poussent même souvent plus loin cette portabilité en préférant utiliser pour le développement un serveur léger : Tomcat ou Jetty.
Pour ce qui est des problèmes de voisinage liés au port d'écoute ou aux répertoires utilisés, le monde Java, particulièrement sous Tomcat, a déjà banalisé ce partage en démarrant une instance de serveur par application web. De ce fait, il est fréquent de voir sur de simples serveurs bi-processeurs plus de quatre instances Tomcat démarrées.
Grâce à la faible adhérence d'une application Java à son environnement d'exécution et à l'habitude d'installer plusieurs serveurs « à la Tomcat », le niveau naturel de mutualisation des ressources CPU et RAM pour des applications Java est au dessus du système d’exploitation. La complexité et les coûts de la virtualisation matérielle sont très rarement justifiés avec Java. Une simple batterie de serveur Linux avec des serveurs Java ‘légers’ comme Tomcat, Jetty ou Glassfish V3 répond au besoin d’optimisation des data centers Java en conciliant simplicité et faible coût.

Adaptation CPU et RAM en Java : Le modèle ‘scale out’

A la différence du modèle ‘scale-up’ de la virtualisation matérielle qui augmente la CPU et la RAM d’une instance pour tenir la charge, Java utilise un modèle ‘scale-out’ qui consiste à augmenter le nombre d’instances de l’application. Pour garantir la haute disponibilité ou la tenue à la charge, nous déployons des clusters de 2, plutôt 3, voire plus, instances de nos applications Java.
Déployer un nouveau nœud se fait aujourd’hui en moins d’une heure pour une équipe entrainée et ce délai va sensiblement diminuer. La roadmap de SpringSource Tc Server permettra d’adapter les ressources CPU et RAM d’une application Java en moins de 5 minutes d’ici deux ans au plus par simple démarrage ou arrêt de nœuds d’un cluster.
Les tâches à accomplir sont limitées pour SpringSource, IBM le propose depuis des années sur son sophistiqués mais complexe WebSphere eXtended Deployment et Gigaspace vient de l’introduire sur sa grille XAP sur un socle Jetty, SpringSource doit principalement ajouter un mécanisme de déploiement de Tomcat à l’agent Hyperic/AMS et améliorer le scripting de la gestion de configuration Tomcat du serveur d’administration Hyperic/AMS.

Virtualisation matériel : Un marché plus concurrentiel et moins lucratif

En plus d’être remise en cause par la rupture technologique du cloud computing, la virtualisation matérielle est aujourd’hui confrontée à une baisse des marges. VMWare a connu des années très lucratives pendant lesquelles elle a été pionnière ‘pure player’. Certains disaient que « VMWare a porté sur architecture x86 la virtualisation des mainframes ».
Le marché de la virtualisation est aujourd’hui mature, les grands acteurs des systèmes d’exploitation se jettent dans la bataille et la concurrence s’annonce rude pour VMWare.
L’univers Windows est condamné à rétrécir mécaniquement pour VMWare avec l’arrivée en force de Microsoft. Les perspectives sont toutes aussi dures dans le monde Linux avec la montée en puissance des offres de RedHat ou de Sun. Nous avons vu par le passé que toutes les fonctionnalités clefs des gros Unix sont arrivées dans Linux ; les zones Solaris et les partitions AIX sont aujourd’hui banalisées, il n’y a pas de raison que ces technologies n’arrivent pas dans le système d’exploitation au pingouin.

One size does not fit all : Concilier virtualisation matérielle et cloud pour optimiser l’utilisation des data centers

A l’époque où les applications n’étaient pas friendly à la mutualisation, la virtualisation était la technologie de prédilection pour optimiser l’utilisation des ressources des data centers. Aujourd’hui, les applications java légères déployées sous forme de cloud Platform As A Service sont très friendly à la mutualisation et se passent de la virtualisation matérielle. VMWare a suivi cette redistribution des cartes en achetant la solution de cloud computing Hyperic-TcServer-Tomcat de SpringSource.
La virtualisation matérielle risque de ne pas être utilisée sur les applications légères (Java, .Net, PHP, etc) qui représentent aujourd’hui la tendance dominante mais garde sa position de leader pour optimiser l’utilisation des ressources CPU et RAM des autres types d’applications.

Ressources

• « SpringSource: Chapter Two » : L’annonce du rachat par Rod Johnson, fondateur de SpringSource.
• « VMWare to acquire SpringSource » : L’annonce par Steve Herrod, CTO de VMWare.
• « Why Java is important to VMware but may not matter long term » par Billy Newport, IBM WebSphere.
• « SpringSource racheté par VMware » par Le Touilleur Express.

Actualité éditeurs / SSII

• Fin officielle de la guerre des JSR d’injection de dépendances

Le coin de la technique

• SpringSource Tool Suite 2.1.0
• JBoss vous aide à manipuler vos annotations
• Eclipse 3.6 M1

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

• JavaCampParis en plein air !

Actualité éditeurs / SSII

Fin officielle de la guerre des JSR d’injection de dépendances

Nous en parlions dès la semaine dernière (grâce aux informations fournies par les Cast Codeurs), la rivalité JSR-299 / JSR-330, portant sur l’injection de dépendances, débouche sur une harmonisation des deux JSR.
Roberto Chinnici, leader de la spécification Java EE 6, l’annonce sur son blog. Les deux JSR seront intégrées à la spécification JEE 6.

• la JSR 299 (dite « Web Beans ») intègrera les annotations proposées par la JSR 330.
• la JSR 330 (dite « @Inject ») intègre, dès aujourd’hui en draft, les objectifs de la JSR 299

L’équipe en charge de la JSR 330 a fait d’importants efforts sur le planning pour que celle ci puisse être intégrée à JEE6 : early draft d’ores et déjà disponible, et navigation à travers les différentes étapes du processus du JCP accélérée.
Cela aura un impact mineur sur la finalisation de la spécification Java EE 6 (estimé entre 4 et 6 semaines). Celle ci devrait donc être disponible en version finale en novembre.

Le coin de la technique

SpringSource Tool Suite 2.1.0

Quelques mois après l’annonce de la gratuité de STS ou SpringSource Tool Suite, le produit sort fin de semaine dernière en version 2.1.0 GA.

Côté packaging, on a le choix entre une version d’eclipse 3.4 ou 3.5, les 2 étant disponibles sous Windows, Mac et Linux. La suite inclut les dernières versions de tc Server et dm Server ainsi que Roo. Une autre release contenant le plugin Groovy est aussi disponible (uniquement en 3.5).

Comme le signale Christian Dupuis, la liste des nouveautés est assez conséquente. On retiendra plus particulièrement :

• Support des milestones Spring 3.0 (@Configuration, @Bean, validation XML…)
• Support des milestones de SpringSource dm Server 2.0
• Déploiement sur les plateformes virtuels de type EC2 ou VMWare Lab Manager
• Amélioration des performances de l’IDE et réduction de l’empreinte mémoire
• Et plusieurs corrections de bugs (cf. la release notes du Jira)

L’équipe travaille déjà sur la prochaine version 2.2.0 avec dans les tuyaux :

• Intégration du support Spring 3.0 pour le développement d’application RESTful
• Support de Grails
• Support de dm Server 2.0

Téléchargement sur le site de SpringSource après avoir rempli le formulaire d’accord.

JBoss vous aide à manipuler vos annotations

Début 2008, Bill Burke (project lead de JBoss RestEasy) présentait une petite librairie Java très pratique nommée Scannotation permettant de scanner les annotations présentes dans les classes d’un package donné. Il expliquait alors le besoin réel pour un tel framework par le fait qu’en standard, cette découverte de classes annotées n’est possible que par un coûteux mécanisme d’introspection nécessitant le chargement dans la JVM de l’ensemble des classes scannées (induisant donc une consommation de mémoire PermGen excessive puisque toutes les classes concernées n’auraient pas forcément été chargées lors de l’exécution de l’application).

JBoss présente maintenant un framework remplissant le même rôle et nommé JBoss Annotations, prévu pour être intégré aux différents projets de l’éditeur. Il vous permettra ainsi de constituer une base de données des annotations présentes sur l’ensemble des classes que vous aurez sélectionnées pour analyse, que vous pourrez ainsi facilement interroger. La documentation et la javadoc de JBoss Annotations sont pour le moment uniquement disponibles dans l’archive de distribution du projet.

Eclipse 3.6 M1

Quelques semaines après la sortie fin juin d’eclipse 3.5 galileo, voici venir la première milestone de la prochaine version de l’IDE à savoir eclipse 3.6 helios (par le blog de keulkeul).

Au menu des nouveautés :

• Regroupement des licences dans le wizard d’installation
• Ajout d’un Footer customisable pour l’aide
• Content assist et Hover Pop-Up redimensionnable sous Linux
• Amélioration d’Extract Method au niveau de continue et de retours multiples
• Export All pour les Formatters
• Nouvelles entrées de menu (Remove Nodes dans Call Hierarchy, Open Implementation…)

Early adopters, c’est par ici que ça se passe !

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

JavaCampParis en plein air !

Fort du succès des précédentes rencontres, le JavaCamp Paris organise une nouvelle session le 27 août dans un format très original puisqu’elle se tiendra en plein air, au Jardin des Tuileries.

Pour rappel, le principe des JavaCamp repose sur la constitution de groupes de discussion improvisés échangeant des informations et des idées sur des sujets décidés en début de session.

Si cette expérience vous intéresse, n’hésitez pas à vous inscrire sur le wiki du JavaCamp Paris 5.