Devoxx France 2012 : l'environnement Java et ses alternatives

Les mots-clés de la 3ème journée de Devoxx France 2012 : langages alternatifs, agilité, open source, mobile, I/O, SQL/NoSQL...

The Artist

Ma journée a commencé par la keynote de P. Chanezon : "Portrait du développeur en The Artist". Comme le titre l'indique, la première partie s'est chargée, non sans une touche d'humour, de faire le parallèle entre l'évolution du développement et le film qui a fait sensation cette année.

Cette keynote est dans la lignée de la conférence de jeudi sur le développement durable, en mettant en avant les méthodes agiles et l'open source, pour montrer une fois de plus que le métier de développeur est un métier à part entière. Comme lors de la conférence d'hier, il évoque brièvement le "Softawre Craftmanship" (nous ne sommes que des artisans), en citant comme référence le livre "The pragmatic programmer", de Andrew Hunt.
Il aborde également l'évolution de notre métier apportée par le cloud, où la focalisation se fait sur des applications et services plutôt que sur les machines, disques durs et réseaux. Cependant, le gros frein du cloud est pour lui le "Lock-in", c'est-à-dire la difficulté pour une entreprise à récupérer son code une fois qu'elle a fait le choix du cloud. La plateforme (Open PaaS) Cloud Foundry est pour lui la réponse à ce frein. A surveiller, donc.
Enfin il émet quelques prédictions sur le futur :

les applications sont de plus en plus saisonnières (notamment les applications mobiles), ce qui met en avant le design pour les différencier ;
les méthodes agiles doivent s'étendre encore ;
enfin, le développeur doit toujours s'exercer à plus de langages et de frameworks, de manière à choisir les meilleurs outils pour résoudre ses problématiques.

La dernière keynote quant à elle, "Abstraction Distrtaction", par Neal Ford, a rencontré un vif succès (couronné par une standing ovation finale). L'homme, dans son intervention incroyablement fluide et maitrisée, s'attache à rappeler, au travers de 7 règles, que les abstractions, c'est bien, mais qu'elles ne doivent pas prendre le pas sur la réalité, et encore moins nous enfermer dans une prison dont nous ne pouvons sortir.

Object Grid Mapper

Je me suis ensuite intéressé à "Hibernate OGM : JPA pour NoSQL". L'objectif du framework est de pouvoir brancher un modèle métier mappé via du JPA, sur des SGBD relationnels ou au contraire du NoSQL, sans rien en changer (du modèle métier). Et la démonstration de Emmanuel Bernard, alias "Mister Hibernate", est bluffante !
A partir d'un modèle métier mappé via du JPA sur une base de données relationnelle, il change deux lignes dans le fichier de persistance (changement de la référence à hibernate ORM par la référence à hibernate OGM) et hop, le modèle est à présent mappé sur du NoSQL, Infinispan pour l'exemple. Puis il change même Infinispan par MongoDB en un clin d'oeil.
En utilisant OGM, on ne se préoccupe même plus de la migration de la base de données après une modification du modèle : le système s\'en charge de manière transparente. Hibernate OGM se charge également de la synchronisation des éléments enregistrés de manière redondante lors de leur modification.
Aujourd'hui, l'interface avec Infinispan, EhCache et Mongo DB est au point; la gestion du CRUD et les requêtes full text (Hibernate Search) sont au point pour ces systèmes. Cependant, la gestion d'autres systèmes NoSQL (type Cassandra) sont en cours, tout comme la prise en compte des requêtes JPQL simples.
En guise de roadmap, voici le top 3 des prochaines tâches à réaliser :

gérer plus de familles NoSQL ;
introduire plus de support JP-QL ;
options de dénormalisation.

Ce dernier point a pour objectif de rendre paramétrable par le développeur la façon dont les entités sont persistées en NoSQL. Car aujourd'hui, elles sont stockés sous forme de tuples, en deux types de fichiers :
- des fichiers entité;
- des fichiers associations.
L'idée est vraiment de pouvoir spécialiser cela par rapport aux besoins de l'application, de manière notamment à améliorer les performances.
Enfin, une fois le socle stable, Emmanuel Bernard indique qu'il souhaite ensuite explorer les possibilités du déploiement hybride, c'est à dire de pouvoir mapper des entités, pour partie sur des SGBD relationnels, et pour uneautre partie sur du NoSQL (voire même sur plusieurs systèmes NoSQL différents). Ça promet !
Pour plus d'infos : http://ogm.hibernate.org.

Guava, au service du développeur Java

J'ai ensuite participé à la présentation de Google "An overview of Guava : Google core libraries for Java". Pour ceux qui ne connaissent pas, Guava est une suite de librairies Google pour faciliter le travail du développeur java. On peut citer les packages suivants :

com.google.common.base
        - vérification de préconditions (checkNotNull par exemple) ;
        - helper pour l'écriture des toString (Objects.toStringHelper) ;
        - Optional<T> : un type de données servant de décorateur d'un autre type et offrant des informations pour se parer des NullPointerException ;
        - Function<F,T> : traitement qui transforme un objet de type F en type T ;
        - Predicate<F> : prédicat sur un objet de type F
com.google.common.collect : traitements sur les collections. Si on retrouve pas mal d'éléments communs avec les CollectionUtils d'Apache, les API Google semblent aller plus loin encore.
        - FluentIterable API : pour faciliter l'itération sur les éléments d'une collection ;
        - Mutliset<E> : équivalent à Map<E,Integer>, où la valeur correspond au nombre d’occurrences de l'objet dans la collection ;
        - Multimap<K,V> : presque comme une java.util.Map, mais autorisant des doublons dans les clés ;
        - BiMap<K1, K2> : map bi-directionnelle ;
        - Table<R, C, V> : équivalent à Map<R, Map<C,V>> (deux clés, R et C) ;
        - Collections immuables qui améliorent considérablement les performances ;
        - Comparateurs
com.google.common.hash : compléments pour les limitations de Object.hashCode (limité à 32 bits par exemple), ou pour limiter les collisions ;
com.google.common.cache : gestion avancée de cache.

Langages alternatifs

Dans la série des langages alternatifs à Java mais toujours pour la JVM, j'ai aussi participé à deux sessions : l'une sur Kotlin, l'autre sur Groovy. Comme Ceylon jeudi, elles visent à améliorer la syntaxe de java pour en limiter la redondance, et permettre au développeur d'écrire le moins de code possible. Groovy va encore plus loin avec des concepts bien à lui, comme la compilation dynamique par exemple.

Concernant Kotlin, c'est un langage open source démarré en 2010 qui propose un typage statique. Il a pas mal de points communs avec Ceylon, découvert jeudi :

simplification de l'écriture des constructeurs de classes (idem Ceylon),
=> plus de new pour instancier une classe (idem Ceylon)
suppression des getter/setter explicites ;
ajout d'éléments spécifiques pour la gestion des NPE (avec une syntaxe du type Type? pour une référence vers un objet du type Type éventuellement nul) (idem Ceylon) ;
pas de type primitif (donc pas de autoboxing) (idem Ceylon) ;
nouvelle syntaxe when/is : à la manière d'un switch, mais sur des types, pour trouver un type réel ;
"smart casts" (idem Ceylon) : plus besoin de cast après un instanceof (ou l'équivalent syntaxique).

Cependant, la grosse différence, avancée par le speaker, avec Ceylon est que Kotlin reste entièrement inter-opérable avec Java. L'idée étant d'utiliser les librairies java existantes dans Kotlin, sans avoir à les réécrire.
Disponible en version Milestone 1, le speaker nous encourage à jouer avec le langage, qu'il annonce comme très rapide à prendre en main quand on fait du java. On peut également contribuer au langage puisqu'il est sous github.

Concernant Groovy, pas mal de nouveautés sont présentées concernant les versions 1.8 et 2.0. Guillaume Laforge (project manager) et Guillaume Champeau (core commiter) rappellent que Groovy est un langage expressif avec une syntaxe concise. Mais pas que! Il permet également de compiler de manière dynamique, ce qui est une réelle distinction par rapport à java!
Évolutions majeures sur la version 1.8 (sortie récemment) :

Grammaire étendue. L'objectif est de simplifier encore le code en supprimant le maximum de points et de parenthèses.
Là où vous écriviez avant "turn(left).then(right)", vous pouvez maintenant écrire "turn left then right". Cela donne quasimment des phrases compréhensibles juste à la lecture.
Support de JSON natif : production, consommation, impression.
Mais aussi et surtout de nouvelles transformations de l'arbre syntaxique (AST) au moment de la compilation.
Ainsi, vous pouvez ajouter dans votre code de nouvelles annotations , pour que le compilateur ajoute automatiquement du code à la compilation. Ainsi, vous n'écrivez plus le code, mais vous pouvez l'appeler !
Exemples d'annotations de classe :

           @Log : permet d'utiliser dans la classe un logger log sans avoir à l'écrire ;
           @ToString : produira un toString sympa sur la classe, reprenant les valeurs de ses paramètres ;
           @TupleConstructor : permet d'utiliser, sans l'écrire, un constructeur avec tous les paramètres sur la classe ;
           @InheritConstructors : permet de redéclarer (sans les réécrire) tous les constructeurs de la classe mère. Indispensable pour les exceptions !

Évolutions majeures pour la version 2.0 (release prévue pour fin mai) :

modularité : pour ne pas que les utilisateurs soient obligés de prendre toute l'API mais seulement les parties dont ils ont besoin ;
prise en compte des nouveautés du JDK 7 (invokeDynamic notamment, qui va certainement faire gagner en performances sur Groovy) ;
flow typing : le compilo sait lors d'une instruction quel est le type d'une variable, même si ce type change entre la déclaration et l'utilisation à cause de nouvelles affectations

Comme vous le savez peut-être, Groovy est un langage qui à compilation dynamique : il est donc possible dans votre code, d'appeler des classes, méthodes ou attributs qui n'existent pas encore. Or, cela freine les nombreux développeurs qui utilisent le langage pour sa simplicité syntaxique, mais qui ne souhaitent pas bénéficier de la compilation dynamique. Deux annotations ont donc été ajoutées pour pallier à cela, et faire un brin de compilation statique.

@TypeChecked : amélioration des vérifications faites sur le typage (static type checking) fait planter à la compilation si on appelle une méthode qui n'existe pas à cette phase, alors qu'avant, l'erreur apparaissait uniquement à l'exécution ;
@CompileStatic : compilation statique, qui produit un code compilé différent du code compilé dynamiquement
- avantages : amélioration de performances, gain sur le taille du bytecode
- inconvénients : perte des fonctionnalités dynamiques de Groovy (meta-classes, catégories), mais pas toutes (on perd le dynamisme à l'exécution, mais pas le dynamisme apporté pâr les transformations d'AST à la compilation)

Java I/O, 16 ans après

Le dernier gros morceau a été pour moi la conférence "Input/Output : 16 ans après". Depuis ses débuts, Java souffre (et les développeurs avec) d'une trop grosse complexité pour gérer les I/O. Mais java 7 révolutionne cela avec NIO2.
Les nouvelles API nécessiteraient un post à part entière, mais voici quelques unes des fonctionnalités que nous, développeurs, allons apprécier tout particulièrement :

arrivée de l'interface Path, chargée UNIQUEMENT de la représentation des chemins ;
+ helper associé, Paths : informations sur les chemins (nombre d'éléments, élément parent,), comparaison et conversion de chemins
notion de Glob : chaine de caractères pour faire des filtres sur des fichiers/répertoires (regex limitées) ;
arrivée du helper associé à la classe File, Files : création, déplacement, copie, suppression de fichiers/répertoires en un appel au helper (le pied!)
Attention cependant : déplacement, copie, suppression ne sont pas récursifs (ces actions doivent utiliser un mécanisme supplémentaire via l'interface DirectoryStream)
classe FileStore : encapsule un système de stockage (disque dur, partition...) ;
classe FileSystem : encapsule le File System, mais pas que! Cette classe est extensible, ce qui permet, entre autre, de représenter le système de fichiers d'un fichier ZIP. Et en plus, l'application aux systèmes de fichiers ZIP est déjà embarquée : il est donc très facile de faire passer un fichier d'un système de fichier à l'autre !
récupération et édition des méta-données de fichiers/répertoires facilitées ;
gestion simple des permissions sur les systèmes de fichiers qui les gèrent, type linux, avec un mode d\'édition via des chaînes "RWX".

J'ai trouvé cette présentation super intéressante, technique et claire, illustrée pour chaque fonctionnalité d'une démonstration concise.
Bravo à Jean-Michel Doudoux (le vrai apparemment...) pour la qualité de sa prez' !

Rapide, mais une bonne porte d'entrée

J'aimerais aussi citer les deux quikies auxquelles j'ai assisté (petites présentations de 15min sur le temps du déjeuner).
- TestNG, un outil qui permet d'écrire des tests, mais finalement avec plus de fonctionnalités que Junit. TestNG est pris en charge par le plugin maven surefire de surcroit! Mais il n'est pas encore intégré à Eclipse sans passer par un plugin supplémentaire...
- Liquibase, un outil de versionning de bases de données très prometteur. Cette présentation a été faite par un développeur qui l'utilise depuis plusieurs années, donc un retour d'expérience immédiat. Pour lui, Liquibase (ou un outil équivalent) est aussi indispensable à un projet industrialisé que l'est SVN ! Il faut donc évoluer nos mœurs pour que cela soit le cas.

Cool !

Et j'ai terminé en beauté par l'enregistrement en live du podcast des "Cast codeurs" : quelle ambiance ! Avec notamment la présence de Antonio Goncalvez, l'un des organisateurs principaux de Devoxx France, ce qui a permis d'avoir un compte-rendu à chaud des trois jours de l'événement. Le bilan est impressionnant, et semble impressionner les organisateurs eux-mêmes puisque l'événement se déroulait à guichet fermé, avec plus de 1200 personnes sur les trois jours; mais aussi de nombreuses propositions de talks... avec un choix difficile à faire du coup.

Bref, je vous invite vivement à écouter ce podcast à l'ambiance survoltée (merci d'ailleurs au fournisseur de bière!).

The Happy End

Je pense que cette première édition de Devoxx France est un énorme succès! Tant du point de vue de l'organisation que du contenu.
Toutes ces conférences montrent l'émergence de nombreuses technologies et méthodes, qui vont j\'en suis sûr énormément faire parler d'elles ces prochains mois :
- poussée de HTML 5 et du développement mobile avec Android ;
- bases de données NoSQL ;
- poussée des méthodes agiles ;
- les (nouveaux) langages java issus de java (Ceylon, Kotlin, Groovy).

Merci à l'organisation et à Netapsys Atlantique pour m'avoir permis de participer à cet événement majeur du monde Java. Et n'oubliez pas : toutes les conférences seront rapidement disponibles sur parleyz !