Allez soyons sérieux 30 secondes…

Après une introduction, sa présentation débute par un slide avec la définition d’un Mock.
Il pose la question : qu’est-ce qu’un mock ?
Sa réponse : « C’est un substitut d’un objet réel afin de faire des tests, en simulant les interactions« .

Comme personne ne pipe mot, il appuie sur espace et une… poupée gonflable apparaît alors : « vous voyez ? un mock permet de se passer de la vraie instance d’un objet, afin de pouvoir faire des tests tranquillement avec un substitut…« .
La salle est morte de rires, je crois que tout le monde se souviendra de la définition d’un Mock.

Il continue ensuite, et puis au 4ème slide il démarre Eclipse, afin de nous montrer un peu comment marche Mockito. Hop quelques lignes, on note au passage sa maîtrise des raccourcis d’Eclipse, parfois j’ai même eu envie de passer à Eclipse et de laisser tomber IDEA IntelliJ. Mais vu que visiblement ce bonhomme n’est pas humain, ou qu’il y a un truc, je suis donc resté à intelliJ.

Le voilà qui code une classe, un mock. Mais il utilise… EasyMock. Est-ce que quelqu’un va lui dire qu’il s’est planté ? Que nenni ! C’est fait exprès…. Aaaah d’accord. Là je vais pas pouvoir continuer à bloguer cher lecteur, car le bonhomme en question a ensuite passé 32 minutes à coder, comme une bête.

J’ai tout d’abord retenu une petite astuce toute simple à reprendre dans vos tests unitaires. Utilisez les expressions « given/when/then » pour exprimer vos tests.
Cela donne par exemple :

@Test
public void shouldIncrementMyValue() throws Exception {
    // given

    // when

    // then 

}

J’ai ensuite surtout vu la différence entre easyMock et Mockito. Respect à David Gageot qui nous l’a dit il y a 6 mois. Oui Mockito est mieux qu’easyMock. Maintenant il faut que je dise pourquoi. Ca c’est le plus dur, surtout sans notes. Durant sa présentation je n’ai pas eu le temps de prendre des notes. Ce bonhomme étant trop fort avec machin-eclipse, impossible de le suivre. Ensuite, sa présentation étant vraiment bien, et sans temps morts, j’ai pas pris de notes. Voilà désolé, hop là je sens un grand cri de frustration… allez je vais chercher des bouts de codes et je reviens. Mais je vous dis, sans notes, ça va être difficile.

Regardons tout d’abord Mockito, le code ci-dessous n’est pas du bon code mais simplement quelques lignes afin de vous montrer le fonctionnement de Mockito.

import static org.mockito.Mockito.*;

import java.util.LinkedList;

/**
 * Simple Mockito test.
 * @author Nicolas Martignole
 */
public class Test {
    @SuppressWarnings("unchecked")
    public static void main(String[] args) {

        // Creation d'un mock
        LinkedList mockedList = mock(LinkedList.class);

        mockedList.add("Test Touilleur 1");
        mockedList.clear();

        // Faire autre chose
        // ....

        // Verifier que l'on a ajoute un element
        verify(mockedList).add("Test Touilleur 1");
        // Verifier que l'on a vide la liste
        verify(mockedList).clear();

    }
}

La différence avec EasyMock : pas de replay à effectuer. Le premier appel à un verify bascule le mock automatiquement. On voit aussi que la syntaxe est facilement lisible : « verifier que mockedList point clear a ete appelé »

Mockito est aussi très intéressant lorsqu’un événement non attendu survient. Imaginons que je m’attende à ce que ma liste « mockée » soit manipulée, que l’on effectue un deuxième ajout. J’ajoute donc une étape de vérification qui va planter puisque je n’ai pas ajouté de deuxième élément à ma liste. Regardons comment le code réagit dans ce cas précis :

import static org.mockito.Mockito.*;

import java.util.LinkedList;

/**
 * Simple Mockito test.
 * @author Nicolas Martignole
 */
public class Test {
    @SuppressWarnings("unchecked")
    public static void main(String[] args) {

        // Creation d'un mock
        LinkedList mockedList = mock(LinkedList.class);

        mockedList.add("Test Touilleur 1");
        mockedList.clear();

        // Faire autre chose

        // Verifier que l'on a ajoute un element
        verify(mockedList).add("Test Touilleur 1");
        // Verifier que l'on a vide la liste
        verify(mockedList).clear();

        // Verifier que l'on a aussi ajouter un autre element
        // ce qui n'est pas le cas, Mockito va donc
        // nous le signaler
        verify(mockedList).add("not added");
    }
}

Voici ce que Mockito affiche lors de l’exécution :

Exception in thread "main" org.mockito.exceptions.verification.WantedButNotInvoked:
Wanted but not invoked:
linkedList.add("not added");
	at Test.main(Test.java:30)

En clair : vous avez demandé à vérifier que l’on ajoute la phrase « not added » mais ce n’est pas le cas. Mockito produit des exceptions très claires lorsqu’un cas non attendu survient. Il sépare clairement aussi la définition du stub de la partie vérification, très facilement.

Je vous encourage à tester Mockito si vous utilisez easyMock, ou si les Mocks ne vous disent rien. Mockito permet de mocker des classes concrètes, certain préfèrent mettre des interfaces partout, et mocker ces interfaces. A la limite, faites ce qui vous arrange, la pratique des interfaces venant d’un livre de Martin Fowler qui disait, je crois, qu’il faut mocker des rôles, donc des interfaces.

Quelques derniers mots sur les charmes de Mockito :
– possibilité d’utiliser une vérification avec un ordre : inOrder()
– atLeast(x), times(x), etc.
– verifyNoMoreInteractions()
– enchainement de commandes: thenReturn(x).thenThrow(y)
– possibilité de matcher avec des arguments comme: anyObject(), etc.
– utilise hamcrest comme jMock

J’espère que nous aurons l’occasion de rencontrer Szczepan à Paris, au Paris JUG. Si vous le voyez à Devoxx 2009, croyez-moi cela vaut le coup.

Références
- Blog de Szczepan
- http://mockito.org/
- L’api de Mockito

Retrouvez l’ensemble des mes articles sur Jazoon 2009 sur cette page

Si vous pensiez que j’étais une brute en écriture d’articles techniques, José Maria est une bête en écriture sur JavaFx et la création de jeu. Allez je vous dis regarder par exemple cet article mais revenez ensuite.

Sa présentation de 20 minutes vise à nous montrer comment écrire rapidement des jeux classiques. Voici ce que cela donne en vidéo :

Je me dis après quelques slides qu’il ne reste plus qu’à offrir le support de JavaFx sur les téléphones portables. Sinon je ne vois pas l’intérêt de JavaFx pour l’instant, face à Adobe Flex ou même HTML 5 demain. Par contre, lorsque l’on sait qu’un grand nombre de téléphone embarquent une JVM, ou même Google Android, j’espère qu’il sera possible de jouer à ces petits jeux demain sur mobile.

José Maria explique tout d’abord que le développement de jeu n’est pas facile. Le chargement des ressources, la gestion du réseau, des périphériques comme la manette de la Wii, tout ceci fait appel pour l’instant à des kits propriétaires de développement, ce qu’il regrette. JavaFx apporte une simplification de la gestion des ressources (images, vidéos, sons). Le support de l’accélération matériel est aussi un plus. Il cite le Java Store et il espère que demain, celui-ci sera le nouveau portail de Java pour trouver des applications sympathiques en JavaFx, et donc des jeux.

Voici par exemple comment charger une image en JavaFx:

Vous pouvez aussi charger une URL très facilement en JavaFx:

var bed = ImageView {
    image: Image {
        url: "http://example.com/bed.png"
    }
}

La suite de sa présentation nous montre comment animer des sprites, comment gérer la détection de collision, le chargement d’une carte (MapTiles) et le scrolling.

Il cite le projet « Project Darkstar« . Après enquête, il s’agit d’un projet de plate-forme ouverte de dévelopement pour réaliser des jeux vidéos. C’est un moteur pour des jeux en ligne massivement multi-joueur, supporté par SUN Microsystems. Il permet de gérer finement les ressources en cluster, afin de répartir la charge des joueurs sur les serveurs. Il peut servir à réaliser un jeu social comme « 2nd Life » par exemple. L’idée est de vous donner un moteur pour le chargement des zones de jeux, la gestion des joueurs, la sécurité et la gestion des problèmes de threads.

Voici une vidéo dans laquelle Owen Kellet en septembre 2008 présente le projet.

Conclusion
En conclusion c’est finalement sa présentation qui m’a le plus donné envie de regarder JavaFx pendant ces 3 jours. Le marché du casual games est énorme. Le nombre de téléphones mobiles aussi. La puissance et la simplicité de JavaFx me semblent plus adapté pour attaquer ce secteur, plutôt que le monde de la bonne vieille application de gestion.

Rendez-vous mardi 7 juillet 2009 au Paris Java User Group pour une présentation sur Adobe Flex puis JavaFx.

Hibernate Envers est un système simple qui permet d’ajouter de l’Audit et la gestion de Version à des Entités Hibernate. L’audit est l’enregistrement automatique en base de données des différentes versions d’une entité. Envers permet aussi de loguer les modifications faites à une Entité Hibernate dans une base de données, pour stocker l’heure et le nom de la personne qui a changé une Entité par exemple.

L’utilisation est simple. Pour cela, il suffit d’ajouter l’annotation @Audited et de déclarer des listeners dans le fichier persistence.xml. Pour chaque entité auditée, une nouvelle table est créée qui va conserver l’historique des changements, un peu comme Subversion si vous voulez. Cela permet aussi de retrouver facilement l’historique des différentes versions d’une entité. Imaginez une Facture, ce système vous permet d’enregistrer les différentes versions de la Facture, sans aucuns efforts.
Sur cette photo prise durant la présentation, on voit l’annotation et la déclaration dans la configuration Hibernate.

Que peut-on auditer?
Les types simples définis par JPA (String, Integer, Date), les composants et les relations entre les composants. Le support des Collections et des types spécifiques à Hibernate est aussi possible.

Voyons avec un peu de code comment cela fonctionne.
Si vous souhaitez auditer l’ensemble d’une Entité :

@Entity
@Audited // that's the important part 
public class Person {
    @Id
    @GeneratedValue
    private int id;

    private String name;

    private String surname;

    @ManyToOne
    private Address address;

    // add getters, setters, constructors, equals and hashCode here
}

La déclaration s’effectue de la façon suivante si vous ne souhaitez auditez que certaines propriétés :

@Entity
public class Person {
    @Id
    @GeneratedValue
    private int id;

    @Audited
    private String name;

    @Audited
    @ManyToOne
    private Address address;

    // we don't care about this in Audit
    private String twitterName;
    private Date dateOfBirth;

}

Le développeur sélectionne les entités qu’il souhaite faire auditer. Pour chaque entité, une nouvelle entité auditée est créée dynamiquement. Par exemple Address aura une entité Address_AUD pour l’Audit, et c’est bien cette deuxième entité qui est persisté en base… avec Hibernate.

Pour chaque inser, update ou delete, une nouvelle révision est créée. Une Transaction est égale à une révision, si plusieurs entités sont embarquées dans une transaction. Le numéro de version est global si vous auditez plusieurs entités, comme le numéro SVN de votre code. Imaginez qu’une entité est un fichier Java que vous commitez, c’est exactement pareil.

Imaginons une entité Person et une entité Address, toutes les 2 annotées:

Déclarons tout d’abord 2 addresses sur une personne John Doe :

// Revision 1
em.getTransaction().begin();
Address a1 = new Address(“West st.”, 10);
Address a2 = new Address(“East st.”, 15);

Person p = new Person(“John”, “Doe”);
p.setAddress(a1);
entityManager.persist(a1);
entityManager.persist(a2);
entityManager.persist(p);
em.getTransaction().commit();

Si je modifie maintenant le nom de la personne et que j’utilise la deuxième adresse :

// Revision 2
em.getTransaction().begin();
p = entityManager.find(Person.class, id);
p.setName(“Paul”);
p.setAddress(a2); // declared in the other code part

em.getTransaction().commit();

Comme vous pouvez le constater, l’utilisation d’Envers est transparente pour le développeur, aucun bout de code supplémentaire n’est ajouté.
Voyons maintenant comment retrouver nos données. Je recharge la révision 1 et je vérifie que le nom de la personne est bien John, puis ensuite comme on le voit, le chargement de l’arbre de relation vers Address fonctionne sans problèmes.

AuditReader ar = AuditReaderFactory.get(em);

// Reading the person at revision 1
old_p = ar.find(Person.class, id, 1);
assert “John”.equals(old_p.getName());
assert a1.equals(old_p.getAddress());

// Reading the addresses at revision 1
old_a1 = ar.find(Address.class, a1_id, 1);
assert old_a1.getPersons().size() == 1;
assert old_a1.getPersons().contains(p);
old_a2 = ar.find(Address.class, a2_id, 1);
assert old_a2.getPersons().size() == 0;

La recherche est aussi très puissante et les systèmes de requêtes d’Hibernate permettent de déclarer par exemple:

auditReader.createQuery()
                   .forRevisionsOfEntity(Person.class, false, true)
                   .addProjection(AuditEntity.revisionNumber.count())
                   .add(AuditEntity.id().eq(person.getId()))
                   .getSingleResult()

Il est important de se souvenir que l’audit est effectué par une autre Entité Hibernate, et que la table originale n’est jamais affectée.

Comment écouter les changements sur une entité ?
Envers permet aussi de déclarer un Listener qui sera notifié lorsque l’entité est persistée vers la base de données. Je reprends le code directement des slides de la présentation, ne croyez pas que j’ai réussi à refaire cet article sans avoir les slides de la présentation

Voyons tout d’abord une Entité de Révision. Elle est annotée avec @RevisionEntity, il faut aussi annoter un timestamp avec @RevisionTimeStamp et un numéro de révision, avec @RevisionNumber comme sur cet exemple:

@Entity
@RevisionEntity(ExampleListener.class)
public class ExampleRevEnt {
    @Id @GeneratedValue @RevisionNumber private Long id;
    @RevisionTimestamp private Long timestamp;

    @ManyToOne private User modifiedBy;

    // Getters, setters, equals, hashCode ...
}

Vous pouvez ensuite déclarer un RevisionListener qui sera activé lorsque l’entité décorée est persistée, afin par exemple d’ajouter le nom de l’utilisateur qui a changé une Entité dans votre interface Web. Cela permet de créer une fonction de Log rapidement, sans alourdir le reste de votre application.

public class ExampleListener implements RevisionListener {
    public void newRevision(Object revEntity) {
        ExampleRevEnt revEnt = (ExampleRevEnt) revEntity;
        User currentUser = (User) Component.getInstance("currentUser");

        revEnt.setModifiedBy(currentUser);
    }
}

Pour plus de détails sur cette fonctionnalité : voir la documentation d’Envers

En conclustion
Envers 1.2.1 GA est sorti il y a quelques semaines, c’est un projet qui fonctionne avec Hibernate 3.3 et donc Java 5. Je retiendrai la facilité de mise en place, la clareté de l’API. Pour peu que votre application nécessite de l’audit, il serait dommage de s’en passer.
Le site officiel : http://www.jboss.org/envers/

Crédit pour les extraits de code : Adam Warski de la société Level N Consulting ainsi que la documentation d’Envers.

La présentation est intitulée « Practitioners approach to generate object-relational persistence and services« . Elle est présentée par Patrick Steger et Marc Baechinger de Zühlke Engineering AG.

Tout d’abord, pourquoi générer du code, puis ensuite une présentation de leur solution, mise en oeuvre dans un projet.

Pourquoi générer du code ?

La génération de code permet de gagner du temps en générant rapidement le squelette de l’application, en s’attachant à générer avec une qualité constante la partie purement technique de l’application.
Patrick explique aussi que la génération permet de réduire le nombre de bugs. En générant le coeur de l’application, il dégage du temps pour ensuite se concentrer sur la partie métier de l’application. C’est un facteur de motivation pour l’équipe.

La solution présentée est basée tout d’abord sur l’utilisation d’un modeleur UML. Le schéma est exporté au format XMI.

Des feuilles de style XSLT permettent de générer du code Java à partir du fichier XMI.

La solution est donc réalisable avec un peu d’effort.
Parmi les améliorations proposées, les 2 présentateurs parlent de générer plus de code, hop attendez je vous retrouve le slide… voilà

Et c’est là que je me dis, mince quand même, si Jaxio était venu présenter SpringFuse… Parce que les petits gars d’en face, les DTOs, les Controllers, la vue, SpringFuse génère tout cela, avec une qualité tip top…

Je suis allé voir les 2 présentateurs en fin de présentation. Les justifications et les idées sur la génération de code étaient intéressantes. Je pense qu’une partie de nous refuse de voir la génération comme un gain de temps. Certains pensent que ce n’est adapté qu’au scaffolding(échafaudage), alors que l’idée est de générer le coeur de l’application, de montrer les bonnes pratiques aux développeurs juniors, de s’assurer de la qualité, et de ne pas se planter lorsque l’on manque de temps.

J’ai aussi changé le système de commentaires du Touilleur Express, il est possible de poster sans devoir s’inscrire au préalable. Cela devrait permettre à chacun de commenter plus facilement.

Bela Ban de JBoss/RedHat est d’origine Suisse. Après un PhD à Zurich, un post-doc à l’université de Cornell, il rejoint la Californie, et il démarre le projet JGroups, intègre JBoss RedHat par la suite, pour s’occuper du projet JBossCache et JGroups.

L’objectif de la présentation sera de nous présenter une implémentation de memcached réalisée en Java, des résultats sur les performances et une discussion sur les DataGrids. Bela Ban est un excellent orateur, sa présentation était très intéressante, animée par une démonstration en direct.

Pour commencer, une phrase afin de marquer les esprits:
« Memory is the new disk. disk is the new tape (Tim Bray) »

La mémoire est le nouvel espace de stockage, finalement le disque dur n’est-il pas devenu aujourd’hui l’équivalent des lecteurs à bande des années 80 ? La base de données est un point de contention, les allers-retours demandent des accès réseaux, ce qui dégrade les performances.

Cependant, il n’est pas possible de stocker toutes les données en mémoire sur un seul serveur. Tout d’abord pour des raisons de place, mais aussi parce que la mémoire ne résiste pas à un crash.

memcached est un serveur de cache écrit en C qui fournit un service de cache de type HashMap en mémoire. Le client du cache peut être écrit dans n’importe quel langage, puisque le protocole pour utiliser memcached est très simple. Il y a un Get, un Put, un Remove, c’est une simple HashMap. Des exemples d’applications Webs connues qui utilisent memcached : FaceBook par exemple. 800 serveurs, 28 TeraBytes de données, memcached est un cache massivement répliqué, qui évite des accès disques très couteux en architecture distributée. C’est donc une grille de données distribuées. (voir cet article de FaceBook)

Le protocole de memcached propose 6 opérations pour enregistrer ses données, 2 opérations pour retrouver une donnée unique ou un ensemble. Les échanges s’effectuent avec de l’Ascii par dessus du HTTP. Bela Ban explique que l’un des soucis de ce protocole est qu’il n’y a pas d’indicateur de la taille des buffers, ce qui fait qu’il est difficile avec Java NIO de préallouer efficacement des buffers.

Il n’y a pas de cache de niveau 1 du côté du client, cela n’étant pas dans l’objet de memcached, bien que certaines implémentations du côté client soient capables de conserver des données.
Les données sont stockées avec une date d’expiration, mais plusieurs serveurs memcached ne se connaissent pas entre eux, il n’y a pas de réplication entre les noeuds. Lorsqu’un serveur memcached (c’est un cache rappelons-le) s’arrête, ses données cachées disparaissent, et il faut alors prévoir un reash de l’ensemble de la grille pour redistribuer les données. Imaginez une partie de Poker, l’un des joueurs s’en va, il faut alors reprendre les jetons de chacun et les redistribuer de manière équitable. Cette maintenance et cette fragmentation du cache est coûteuse.

Implémentation d’un serveur memcached en Java
Bela Ban présente maintenant son implémentation d’un serveur compatible avec le protocole memcached, mais réalisée en Java. Tout d’abord dans son exemple de cache distributé, le client en Java dispose d’un cache L1 pour optimiser les performances. Du côté des grosses différences par rapport à l’implémentation en C, chacun des « ReplCaches » (son implémentation Java de memcached) utilise JGroups pour découvrir ses voisins. Les données sont donc automatiquement distribuées de manière efficace dans la grille, constituée par plusieurs serveurs « ReplCaches ».

Lorsqu’une donnée est placée dans le cache, selon la clé de hashage de cette donnée, la grille de données s’optimise automatiquement. Par ailleurs la réplication entre les serveurs memcached en Java se fait via un protocole binaire optimisé, ce qui permet de bien meilleurs performances avec la version Java que la version C.

Le protocole peut aussi être adapté, c’est le fonctionnement de JGroups. Si vous souhaitez ajouter de l’encryption, de la compression, il est possible de configurer la couche JGroups finement. Cela réduit l’usage du réseau. Bien entendu, TCP comme UDP sont supportés.

Démonstration
Le « ReplCache » est embarqué dans un conteneur de Servlet, dans le même espace d’adressage. Arrive maintenant le moment le plus intéressant je trouve de sa présentation. Il explique qu’il utilise ses « ReplCache » comme des disques durs physiques. Il est possible de sélectionner une stratégie de stockage pour chaque donnée, afin de faire… du RAID de données. Il est donc possible de définir si l’on souhaite qu’une donnée soit répliquée ou non plusieurs fois dans la grille.

Les données qui peuvent être relues rapidement de la base de données pourront être reglées avec un compteur de replication (repl-count) = 0
Les données critiques de travail de votre session (un panier d’achat) que vous ne devez pas perdre en cas de crashes, peuvent être répliquées dans toute la grille avec un compteur repl-count=-1. Sinon en général, l’usage est de ne stocker qu’une seule fois dans le cache cette donnée, la clé de hash permet de trouver rapidement quel serveur stocke la donnée. Il s’en sert comme d’un espace d’adressage, chaque client sait que par exemple les clés de A à H sont sur le serveur 1 et les clés de I à Z sont sur le serveur 2, ce qui permet vraiment d’optimiser les performances.

JBoss Infinispan
Bela Ban présente ensuite le projet Infinispan, une grille de données open-source basée sur l’implémentation en Java memcached, avec la possibilité de passer des objets de type Runnable, ce qui en fait aussi une grille de calcul.

JBoss Infinispan est une implémentation de la JSR-107, la distribution du contenu caché est effectué selon la clé de hachage, afin d’assurer une distribution fine de celle-ci. Il est possible de créer un espace de stockage immense. 100 noeuds avec 2 Gb de mémoire, configuré en copie représentent 100 Gb d’espace de mémoire adressable. La mémoire est le nouveau disque dur comme il le rappelle.

Infinispan est aussi compliant JTA et offre le support de JMX pour proposer une interface de gestion performante. Il est compatible avec le protocole ASCII classique de memcached, ce qui permet de brancher un serveur en PHP avec un cache Infinispan par exemple. Bien entendu le protocole binaire dont il a parlé est plus intéressant, et l’un des objectifs du projet sera de fournir rapidement des implémentations du côté client en C et en PHP.

Du côté Java, l’API offre aussi une gestion asynchrone pour par exemple stocker de manière asynchrone une donnée :

Future putAsync(K key, V value)

Perspectives
Bela Ban termine la présentation avec quelques idées pour la suite. Tout d’abord, réellement développer l’idée que la grille est un système de stockage de données, un file system. Pour cela, il imagine proposer une api type java.io pour utiliser la grille pour lire et écrire des données massivement répliquées. Encore une fois : Memory is the new disk, why can’t we implement JDBC on top of the grid ? use-it as a disk ? And what aboute Hibernate on a grid ?

La mémoire est le nouveau disque dur, celui-ci n’étant plus aujourd’hui que le vieux lecteur à bande destiné à faire une sauvegarde persistente.

Références
Démonstration Java WebStart de ReplCache : http://www.jgroups.org/jnlp/replcache.jnlp (lancez 2 ou 3 fois l’application en cliquant plusieurs fois sur le lien)
ReplCache Flash demo: http://www.jgroups.org/movies/ReplCache.swf
Infinispan : http://www.infinispan.org

Vincent Massol, de XWiki SAS, mais aussi l’un des CastCodeurs, nous propose ce matin une présentation des nouvelles fonctionnalités de l’application XWiki 2.0. Sa présentation commence par un rappel du concept de Wiki, qu’il appelle Wiki 1.0. Ensuite, l’approche qu’il va développer concernant XWiki 2.0, sera de nous montrer qu’il devient facile de créer des mini-applications hébergées dans un wiki. Il cite quelques exemples d’applications qui seraient faciles à développer avec la future version de XWiki :
– Gestion de projet
– Système de demande de congés
– Notes de réunion
– Factures ou notes de frais
– Annuaire de contacts
– Notes de frais

Bref l’idée est de prendre en compte un fait : le Wiki est maintenant bien implanté dans l’entreprise, l’étape suivante est d’ouvrir le moteur afin d’offrir aux utilisateurs des applications, des formulaires, en conservant la philosophie du Wiki. En effet, tout ce qui va suivre sera codé directement dans l’interface de XWiki.

Vincent Massol montre quelques exemples de sites comme « France 2025″ construit autour de XWiki. La frontière entre un portail et un wiki est très fine. Comme il l’explique, les Wikis 1.0 présentent des données peu structurées. Les blogs ajoutent une journalisation, ce qui structure les données. Les portails d’entreprises ensuite ont structuré l’information par domaine. Ce qu’il va présenter est donc la dernière étape, la structuration des données personnalisés, la possibilité de développer son application. Un outil de développement léger en quelques sortes.

L’idée des Wikis 2.0 est donc d’être l’Excel du Web. Un besoin simple ? Plutôt que de développer un gros projet, il explique que le moteur de Wiki doit fournir quelques services simples pour créer ses formulaires, et donc ajouter aux pages une application avec un coût de développement réduit.

Il débute la démonstration. L’objet de la démo sera de créer une petite application de demande de congés. Pour comprendre la suite, il présente 2 concepts de XWiki. Une classe est une page, un template. Un Object est une instance de cette classe. Tout d’abord il commence par créer les méta-données associées à la page. Pour cela, un script dans une textarea permet de déclarer les attributs. La syntaxe utilisée est Velocity. Le support de Groovy est aussi prévu déjà présent, le support de Jython et de JRub est en cours (cf commentaire ci-dessous).
Cette étape fait un petit peu peur au premier coup d’oeil, on pense à Microsoft Sharepoint qui permet de créer des applications. Si j’avais un bémol je dirai que j’ai eu un peu peur en regardant le code. Mais cependant la syntaxe est simple, et je pense qu’une fois l’outil maitrisé, cela ne pose pas de soucis. De toutes les façons, ce qui suit est plutôt destiné à des administrateurs de portails, mais je n’ai pas assez de connaissances sur ce sujet.

L’intérêt évident d’éditer en direct, c’est que le résultat est tout de suite disponible. Et en effet, je trouve le concept vraiment intéressant. Donc un template Velocity permet de décrire sa demande de congés, ce template est attaché à une page, il est temps ensuite de créer l’interface de saisie.

Dans un deuxième temps, Vincent crée une ClassSheet, une feuille de style pour habiller la class qu’il a créé. La demande de congés est constitué de champs simples, de champs de type Date, et d’une liste déroulante d’utilisateurs, automatiquement peuplées par XWiki.

Une fois la feuille de style prête, nous voyons alors la page de saisie s’afficher. Le tout en 10 minutes à peine. Le reste est bien de la syntaxe Wiki, vous pouvez alors intégrer des images, des feuilles de style, les méta-données sont stockées dans la version de la page (??).
Un langage de requêtage, le xwql, permet de créer des éléments dynamiques, une liste des personnes ayant effectué une demande de congés.

Vincent Massol explique ensuite que la version 2.0 de XWiki est polyglotte, elle supporte un nombre assez important de syntaxe Wiki. D’ailleurs comme il le fait remarquer, il est intéressant de remarquer que certains Wikis proposent par défaut un éditeur type Word, là où au départ le wiki a été créé pour qu’un langage simple de balisage soit utilisé !
La version 2.0 supportte aussi le « Roundtrip between XHTML and Wiki Syntax » et ce moteur est disponible comme librairie à part.

Parmi les questions posées en fin de présentation, quelqu’un demande si un moteur de Workflow (pour valider la demande de vacances) serait prévu ? Au delà de la question, on comprend que les Wikis 2.0 se rapprochent de la frontière des applications d’entreprise. Est-ce que les utilisateurs accepteront quelques limitations ? Est-il envisageable de développer plus de fonctionnalités tout en gardant la simplicité et la puissance d’un Wiki ?

Peut-être qu’un slide pour présenter les fonctionnalités des autres acteurs nous aurait aidé pour comprendre l’avantage d’utiliser XWiki. Bonne présentation qui montre en tous les cas que les Wikis sont devenus des outils incontournables dans les entreprises.

L’objectif est de nous présenter le fonctionnement d’Hibernate Search à travers des exemples de codes. Emmanuel assure la présentation avec un ordinateur de secours, son portable n’ayant pas supporté le voyage. Ouch ! Armé du package du bon speaker : un Mac + IDEA IntelliJ, il débute la présentation par une courte introduction afin de se présenter. Membre de l’équipe d’Hibernate, JCP Specification Leader de la JSR-303 « Bean Validation » et membre de l’expert group sur JPA 2.0. Il est l’auteur du livre « Hibernate Search In Action » chez Mannings. Enfin petite information, il revient vivre en France en octobre, ce qui permettra je l’espère de le voir lors des soirées des Java User Group en France.

Son objectif sera de nous expliquer en quoi consiste la recherche « full-text », ce qu’elle peut nous apporter, la magie des analyseurs, les différents algorithmes pour la recherche approximative, bref comment Hibernate Search fonctionne.

La recherche
Que ce soit un formulaire sur un site web ou autre, tôt ou tard une application souhaite offrir une fonction de recherche dans les entités d’une base de données. Hibernate Search vise à offrir une solution efficace et puissante, basée sur Lucene, afin de nous assister lors de l’écriture de cette fonctionnalité clé dans les applications.

Une recherche simple basée sur la syntaxe SQL est trop restrictive. Si vous tapez « car », comment extraire ce mot d’une colonne ? Certes il y a des requêtes comme « LIKE » mais celles-ci coûtent chères en terme de performance. Il explique que la base de données est le premier point de contention, qu’il est donc dommage de ne pas remonter cette fonction afin de la rendre plus puissante.

Par ailleurs, si vous tapez « car », est-ce que le moteur de recherche sera capable de vous montrer les entrées avec « vehicle » ? Et si vous faites une faute de frappe, est-ce que le moteur sera capable de vous monter un résultat ?

La sélection par SQL est donc très limitée.

Emmanuel enchaîne ensuite avec un argument : comment classer par pertinence les résultats ? De ces besoins est né l’idée d’Hibernate Search, offrir un moteur de recherche full-text à Hibernate.

Full Text Search
Pour répondre aux besoins exposés précédemment, la solution s’appelle « Full Text Search ». Elle est relativement simple et puissante. Le principe est de créer un Index des mots clés, en supprimant les mots de liaisons, afin d’identifier les occurences de chaque mot, et donc de créer de la pertinence. Ce principe est très performant puisque l’on ne fait pas d’accès à la base de données.

Il existe déjà différentes solutions, soit embarquées dans la base, soit dans des boîtiers externes sous la forme d’applicance, mais qui manquent de flexibilité, puisqu’en tant que développeur il sera difficile d’affiner la stratégie d’indexation.

Exemples de problèmes
Voici la mission d’Hibernate Search :
– Trouver le meilleur document, la meilleure entité selon son critère de choix.
– Classer par pertinence
– Utiliser un algorithme de similarité pour proposer à l’utilisateur des résultats similaires

Extraction
L’indexation s’effectue tout d’abord en découpant les phrases en mots, ce que l’on appelle l’extraction. A ce propos, la construction de l’index est gérée par Hibernate Search, elle s’effectue automatiquement.
L’extraction consiste tout d’abord à découper les phrases et à filtrer les mots communs pour ne garder que le sens.

Approximation
Ce système permet d’assister l’utilisateur en lui proposant des résultats très proches lorsqu’une recherche exacte ne retourne pas de résultat par exemple. Il est possible de dire à Hibernate Search que l’approximation est moins importante que la recherche exacte, de sorte que la liste des résultats ne soit pas polluée et reste pertinente. Ce poids lors de la recherche est configuré par le développeur, ce qui nous permet de régler finement le comportement du moteur. Les réponses exactes apparaissent en premier, puis les approximations.
La résolution d’approximation se fait avec des algos comme le calcul de distance Levenshtein. Tapez par exemple Hibrenate au lieu d’Hibernate, et vous verrez que le moteur détecte les résultats proches, en calculant la distance entre les lettres.

L’approche n-gram
Emmanuel présente ensuite une fonction plus avancée d’indexation, appelée n-gram. Le principe consiste à découper des mots en paquets de lettre. Par exemplte un tri-gram pour découper en paquet de 3 lettres un mot comme Hibernate donnerait : hib-ern-ate. Cela permet alors de créer des arbres d’indexation et de donner des plans de résultats encore plus pertinent.

Emmanuel montre un exemple où il tappe « poter ». les livres sur Harry Potter s’affichent, mais aussi un
« Capote » car le tri-gram « pot » a matché

Hibernate Search
je mettrai des photos en ligne un peu plus tard avec des exemples de code

Emmanuel prend ensuite l’exemple d’un Item pour nous présenter l’API.
On voit une annotation @Indexed placée sur un Entity, ce qui permet à Hibernate Search de savoir que cette entité doit être indexée. Par ailleurs il explique qu’Hibernate Search sait que lorsque l’objet est changé, il doit mettre à jour l’index Lucène. Il nous montre enfin comment configurer l’indexation afin de ne pas découper en n-gram par exemple certains champs, afin de conserver des codes ISIN.

La recherche s’effectue comme une requête HQL avec un entitymanager particulier, le FullTextEntityManager qui est une sous-classe de l’EntityManager d’Hibernate.

FullTextQuery q = entityManager.createFullTextQuery(luceneQuery, Item.class)

Pour construire sa requête Lucene, Hibernate Search laisse le soin au développeur de construire celle-ci, ce qui permet de régler finement le type de recherche. Il commence par faire une démonstration d’une recherche exacte, puis ensuite une démonstration d’une recherche avec un n-gram Analyzer.

Il est aussi possible de déclarer par exemple 2 stratégies d’indexation différentes, une indexation exacte et une indexation pour une recherche approximative. Vraiment intéressant de voir la possibilité de réglage d’Hibernate Search. La quantité d’annotations peut faire peur, mais le code est vraiment simple à lire. Quelqu’un demande d’ailleurs s’il serait possible de déclarer dans un fichier XML ce qui est déclaré ici sous forme d’Annotations.

Approximation phonetique
Il existe différents algos pour indexer de manière phonétique des mots:
- Soundex
- Metaphone (JRSKP)
- mostly for latin language
Emmanuel explique cependant que ce n’est pas le cas le plus courant dans la vraie vie.

La recherche par synonyme
L’ídée est de proposer à l’utilisateur des listes de résultats dont le domaine est proche sémantiquement, une voiture, une bagnole, un caisse si vous voulez. Pour cela il faut un dictionnaire, que l’on indexe. Cela crée de gros indexes, mais il est possible de construire des dictionnaires par référence. Dans tous les cas, il nous conseille de construire nous-mêmes nos bases de synonymes.

What’s the catch
Lucene étant relativement bas niveau, l’intégration avec un modèle, la création et la mise à jour de l’index sont donc des fonctions clés d’Hibernate Search. Celui-ci permet d’apporter facilement des fonctions de recherches très puissantes à une application. Et qui n’offrira pas finalement une fonctionnalité de recherche ?

Bonne présentation, détendue, claire, et intéressante. Et en plus avec un Mac et IDEA IntelliJ !

La spécification des Portlets 2.0 est sortie en juin 2008. Thomas nous donne un retour un an après de la conférence. Lui-même contributeur depuis 2004 sur JBoss Portal, une année sur JBoss Seam, il est aujourd’hui le responsable du projet JBoss Portal chez RedHat.

L’agenda de sa présentation sera :
- Quelles sont les nouvelles fonctionnalités de la version Portlet 2.0
- Adoption par les vendeurs
- La portabilité
- Portlets versus Gadgets

Dans un premier temps, retour sur la JSR-286 Portlet 2.0 sortie l’an passé. Tout d’abord l’une des innovations les plus importantes est ce qu’il appelle « Resource Serving ». L’objectif est de permettre l’envoi de données vers le navigateur qui ne font pas partie du portail, comme un fichier PDF ou Excel par exemple, tout en conservant les fonctionnalités d’une portlet. Cette spécification vise donc à offrir un accès au contexte afin d’assurer le support de la sécurité et de l’accès aux données par exemple.

Il montre ensuite l’interaction entre les portlets avec une RemoteCommandPortlet sur une démonstration fonctionnant avec JBoss Portal. Une fenêtre HTML détachée permet d’envoyer des commandes à une autre portlet, la gestion de l’asynchrone est très simple.
A ce propos, il explique que les améliorations du support d’Ajax dans la spécification Portlet 2.0 permettent à des frameworks comme ICEFaces ou RichFaces de fonctionner correctement dans des portlets.

Les Portlets 2.0 peuvent maintenant partager leurs paramètres avec d’autres produits ce qui permet de faire communiquer les portlets entre elles. Thomas Heute montre l’exemple d’une portlet Google Map et d’une portlet Weather qui recoivent toutes les deux en paramètre le code postal d’une ville américaine.

Une portlet peut aussi déclencher une événement, les autres portlets peuvent être notifiées et se mettre à jour. Il conseille de ne s’en servir que pour de la mise à jour de l’interface.

Sur le slide suivant il dresse un état de l’implémentation de la spécification par les différents acteurs du marché :

La JSR-286 Portlet 2.0 est en version finale depuis le 12 juin 2008.
- JBoss Portlet Container 2.0 est sorti le 13 juin 2008 puis inclus dans JBoss Portal 2.7.0 en octobre
- eXo Portlet Container 2.0 est sorti le 18 juin 2008, mis dans eXo Portal le 1er juillet 2008
- Liferay portal a sorti sa version le 17 juillet 2008
- Apache Jetspeed assez tardivement le 27 mai 2009 dernier
- IBM Websphere portal 6.1 a été disponible sept 2008
- Oracle Portal (BEA () + Oracle (2) + Sun(1)) ?

Concernant le support des frameworks WEB il existe 2 spécifications
JSF Support:
– JSR-301 specification addresses JSR-166
– JSR-329 addressing JSR-286 (JBoss Portlet bridge on the way)

De ce qu’il a pu voir sur les forums, les pages :
Wicket support -> mostly there with support for events
Sruts 2 plugin for JSR-286
Spring MVC also support JSR-286
WebWork

A propos de la portabilité : attention la spec ne dit pas comment on fait un portail mais une portlet.
La notion de page n’est pas définie.
La communication entre portlet:
– UI Level
– Le mécanisme événementiel n’est pas un remplacement par JMS, ne pas abuser de ce mécanisme.
– Doit-on se coordonner à travers les pages ?
– Portlets aren’t a template mechanism per se

Rester à une gestion des événements entre portlet qui sont sur la même page si vous ne voulez pas avoir de soucis.

Slide suivant qui m’a fait sourire : Portlet vs Widget vs Gadget (vs Toilet ?)
Thomas Heute explique tout d’abord en quoi consiste un Gadget, tel que l’on peut le voir sur Facebook. C’est un affichage déporté dans un autre site web d’une fonctionnalité hébergée sur un serveur primaire. Une portlet est plutôt la représentation locale d’un service distant, c’est une composition gérée par un portail, afin d’assurer des services communs (authentification, autorisation, communication, etc) dans un seul endroit.

Il cite différentes initiatives autour des Gadgets :
Google OpenSocial, OpenAjax Alliance (OBM, Google, Sun, Red Hat, Oracle, Microsoft) -> Widget proposal

L’avantage des Portlets par rapport à un Gadget/Widget:
-> Fait pour des applications plutôt complexes.
-> Vous pouvez utiliser votre framework en général,
-> L’état des portlets est gardé lorsque la page se rafraichie.
-> propagation de l’identité, de la sécurité, interaction avec un portail, visuel.

Les gadgets ont l’avantage d’être développable rapidement, comme pour consommer par exemple un flux RSS. Facile pour l’intégration du côté client, facile pour partager de l’information. On pense au Gadget Twitter que j’ai sur mon blog par exemple.

Il termine par un slide sur ses idées pour l’avenir
> We could use more annotations a la Servlet 3.0 or JSF 2.0 @Portlet (no portlet,xml)
> We could all benefit from a PORTAL specification
– more aware of the environment, communication with the portal itself
– Portal object management
– Federated search/index

Enfin il revient sur l’annonce du parternariat entre JBoss Portal et eXo Portal. Il résume cela par
« JBoss builds the platform, eXo Platform builds the solution, We are hiring ! »

Réflexions et conclusion
Présentation intéressante, je crois que les Portlets 1.0 ne doivent plus être utilisées. Je travaillerai cet été à l’étude de différents portails pour le client avec lequel je travaille, le sujet est donc d’actualité. Mon souci du moment : comment proposer l’étude d’alternative à la politique d’achat qui voudrait que l’on prenne Oracle Portal, sans savoir si celui-ci correspond à nos besoins ? Mais c’est une autre histoire…

Après une soirée animée, un réveil difficile où vous vous dites que vous n’avez plus 20 ans, retour ce matin dans la plus grande salle afin de participer à la KeyNotes de SpringSource. Sur scène, un très bon speaker en la personne d’Adrian Colyer, CTO de SpringSource.

La présentation s’intitule : The Changing Nature of Enterprise Java Application Development

La lumière s’éteint, début du show…

Adrian Colyer : notre écosystème Java est comme la Forêt Vierge : une végétation dense, des petits arbres, de grands arbres, beaucoup d’animaux, qui se battent… On voit des strates, la canopée est l’étage en contact avec la lumière du soleil. Les arbres les plus grands, 20 mètres plus haut que les autres. En dessous de cela, la canopée, ceux qui bénéficient de la lumière. Pour un oiseau c’est cool. En dessous, pas top. La vie est difficile si vous êtes en dessous, 5% de la lumière du SUN (soleil) arrive jusqu’au sol.

Adrian prend le temps de laisser les images s’imprimer…

Le sol de la forêt ne reçoit que 2% de la lumière. Mais de temps en temps arrive une éclaircie dans la forêt. Dans ce cas, arrive une explosion de la vie, jusqu’à prendre peut-être la place des autres. Peut-être même une nouvelle canopée.

Regardons les arbres géants : ce sont les grosses compagnies (IBM, SUN, Oracle…). La canopée est l’espace de vie pour les mediums-size players. Il constate qu’il est très dur pour une nouvelle idée, une nouvelle approche, de faire sa place.

Oracle rachète SUN. Pour lui, un grand arbre est tombé. Cela crée un trou de lumière qui touche le sol, ce qui va entrainer du changement.
Un ange passe..

Il cherche à nous faire prendre conscience qu’en ce moment, il se passe quelque chose.

Où en sommes-nous dans notre forêt vierge ? Au couché du soleil, en anglais au Sunset. SUN Microsystems se fait racheter par Oracle, nous sommes à la fin de quelque chose pour lui. Adrian montre la courbe de la quotation de SUN pour dire que la compagnie descend tout doucement.

Après le couché du soleil, vient la période sombre (Dark Age) mais nous aurons ensuite une nouvelle aire, de l’innovation, un renouveau. (A cet instant je vois presque Rod sur son cheval blanc… une larme coule… que c’est beau)

Slide suivant, les temps changent. Regardez, dit-il, la présentation de SUN la veille. Parmis les 5 premiers points les plus importants dans le JDK 7, nous voyons que le support des langages dynamiques est cité dans cette liste. C’est très important, vous devez comprendre que les alternatives à Java, qui devient parfois un peu lourd ou complexe pour certains sujets, se trouve dans les nouveaux langages dynamiques, pas dans une quelconque JSR pour les Closures en Java. En avons-nous besoin d’ailleurs ?

Il continue ensuite en expliquant que l’explosion de nouveaux langages basés sur la JVM comme Groovy ou Scala doivent nous faire prendre conscience rapidement qu’un nouvel arbre est entrain de pousser dans la forêt.

Adrian affiche ensuite un slide avec différents langages:
– Groovy,
– Erlang,
– Clojure,
– Jython,
– JRuby,
– Ruby,
– Scala.

Il continue ensuite: Java est peut-être trop compliqué. L’introduction des Generics serait le début de cette complexité. D’autres disent que Java bouge trop lentement. D’autres pensent qu’il y a trop de fonctionnalités. Java est trop ceci, trop cela…

Il nous demande à notre avis quel sera le langage qui aura le plus de chances de pousser dans cette nouvelle forêt ? 4 langages se détachent dans sa sélection
Groovy JRuby Clojure et Scala

Il revient ensuite sur Groovy qui a remporté le « Script Bowl » lors de JavaOne 2009 (voir cet article sur le Touilleur Express). Dans les slides qui suivent, il montre un exemple Groovy vs Java, largement discutable. Mais l’idée est de dire que l’on peut faire la même chose avec moins de code. Ok, à cet instant je suis d’accord sur la quantité. Mais il passe aussi sous silence le changement de paradigme. Programmer avec un langage dynamique est forcément différent par rapport à Java.

Concernant la productivité, Groovy est plus concis, se concentrant sur l’efficacité. Adrian montre l’exemple du script HelloWorld, qu’il transforme en script Groovy. Il passe à un slide en Groovy avec 10 lignes au lieu de 30. Et il fait rire la salle en disant « et c’est la même taille de police ».

Adrian explique ensuite en quelques minutes les principes de Groovy.

class HelloWorld {
	def name
	deg greet() { "Hello ${name}"}

	static main(args) {
		def helloWorld=new HelloWorld(name: "Groovy")
		println helloWorld.greet()
	}
}

Concernant ensuite la gestion des threads, Adrian montre un exemple en Scala.

class Pong extends Actor {
	def act() {
		var pongCount=0
		loop {
			react {
				case Ping =>
					if(pongCount % 1000 ==0)
						println("Pong: ping "+pongCount +" from + " sender)
					sender ! Pong
					pongCo = pongCount + 1
				case Stop =>
					println("Pong : Stop")
					exit('stop')
			}

		}
	}
}

Pour suivre un exemple avec Clojure, langage du domaine fonctionnel comme OCaml.

;; Hello

(use 'clojure.contrib.test-is')

(defn hello
 "return a greeting"
 ([] "Hello World Default")
 ([username] (str "Hello " username " !")))

(println (hello "World"))

(deftest test-hello
	(is (="Hello World" (hello "World")))
	(is (="Hello World" (hello "World")))
	(is (="Hello World Defalt" (hello))
	 "Called with no arg, we default to World !"
	)
)

Il pose ensuite une question à la salle:
A votre avis, quel est le langage qui a le plus de chances d’être le plus populaire ? Il ne nous demande pas le meilleur langage, question à laquelle il n’y a pas de réponses. Il nous demande simplement quel serait selon-nous les chances de chacun de ses langages ? Clairement Groovy se détache du lot. Il conclue en expliquant de manière très pragmatique : « That’s a reason why we bought G2One.Inc »
SpringSource recherche la meilleur technologie, le meilleur framework, afin d’aider à faire émerger de nouveaux arbres dans la forêt vierge.

Il nous demande : seriez-vous prêt à retravailler en assembleur plutôt qu’en Java ?
Non bien entendu car vous êtes plus productif en Java. Il nous encourage ensuite à regarder Groovy comme un moyen d’améliorer encore cette productivité. Et un jour il espère nous demander : « seriez-vous prêt à retravailler en Java ? ». Réaction plus retenue dans la salle, certains ont le sourire, d’autres moins. Mais l’objectif ce matin est de nous remuer et de nous faire prendre conscience que quelque chose est entrain de se passer.

Adrian Colyer parle maintenant des frameworks. Nos besoins sont assez communs et connus, lors de la création d’une application Web. Si nous acceptons que les langages dynamiques peuvent nous faire gagner du temps, il est logique d’accepter que des frameworks nous aident à améliorer notre productivité.

Un exemple de site : Wired.com 12 millions de lecteur cité sur le site de SpringSource utilise Grails. Aegon est une autre compagnie citée.

Adrian montre ensuite un écran 3270 avec 2 couleurs. Il rappelle qu’il y a peu nous avions des applications développées en mode texte, avec des touches de fonctions pour naviguer. En 2009 nous sommes aujourd’hui complètement dans un autre univers, avec la présence du réseau.

Il lance ensuite une charge sur la lourdeur des applications J2EE classiques, trop lourdes. Le déploiement d’une application écrite avec de vieilles technologies comme J2EE 1.4 est difficile. Alors vient OSGI et les modules.

L’objectif est de livrer une application modulaire, afin de ne déployer qu’une partie, et donc de faciliter le déploiement.

SpringSource cherche avec Spring dm Server à proposer une autre approche. Tout d’abord il rappelle que le cycle de vie de déploiement ne s’arrête pas à la construction de votre War. Le déploiement et l’administration sont aussi très importants. D’où le besoin de rendre facilement administrable une application.

We live in an Interesting times… s’affiche sur le slide suivant… C’est la fin de sa présentation, qui aura le mérite de lancer le débat sur l’avenir de Java et de la plateforme.

La présentation s’est axée autour de la prise de conscience que les choses sont entrain de changer. Le Cloud Computing, les langages dynamiques, la modularité, on ne sait pas encore ce qu’il va se passer mais comme il le dit, nous vivons en ce moment des moments de changement intenses.
Le futur arrive, que l’on aime cette idée ou pas, le Futur arrive à nous.

Analyse et Réflexions
Quoiqu’un peu polémiste, sa présentation vise tout d’abord à faire prendre conscience des changements qui s’opèrent dans notre industrie. Le rachat de SUN Microsystems par Oracle est un événement, dont la portée est encore mal estimée selon les analystes. SpringSource s’engoufre certainement sur une pente un peu glissante en se présentant comme le chevalier blanc. Quoique le framework soit excellent, le temps nous dira si en effet tout change, et donc le choix d’une solution plus légère, modulaire, basée sur des langages dynamiques, constitue le bon choix ou non.
En tous les cas, il y a une guerre froide qui ne dit pas son nom, qui devra éclater pour que la communauté continue à diriger Java et son avenir. Je pense que la professionnalisation de l’open-source expose aujourd’hui les débats d’idées entre les grands contributeurs. Là où il y a quelques années, les guerres entre IBM et SUN Microsystems se déroulaient entre 2 commerciaux chez le client, négociant le cuir de leur Porsche de fonction, aujourd’hui un barbu de JBoss réglera son compte à un barbu de SpringSource autour d’une bière ou au board d’une JCR.