Fin de crise d’ado en vue pour Play Framework

J’avais écrit un retour d’expérience à propos de Play Framework il y a un peu plus d’un an. J’y exprimais ma frustration quant au fait qu’il ne manquait pas grand chose à Play Framework pour être un super outil de développement.

J’étais assez peu optimiste sur le fait que ces points puissent s’estomper rapidement parce que c’étaient ceux que Typesafe mettait en avant pour se différencier des autres. Il semblerait cependant que le vent a tourné récemment et il souffle maintenant de mon point de vue dans la bonne direction !

L’esprit de contradiction

J’ai choisi de manière provocatrice d’employer la notion de crise d’adolescence dans le titre de cet article. C’est en effet ce que m’inspirait la stratégie de Typesafe depuis le début du développement de Play Framework.

J’ai l’impression qu’à chaque fois qu’une question se posait ils avaient la volonté de ne surtout pas faire comme les autres. Je ne cherche pas à défendre l’idée qu’il faut faire comme ça parce qu’on a toujours fait comme ça, je sais bien que c’est souvent en faisant différemment qu’on innove. Mais l’exercice a ses limites et n’est pas toujours pertinent.

Typesafe a pendant longtemps revendiqué le fait de ne pas faire comme les autres. C’était sans doute leur façon à eux de se faire remarquer, de se faire une place dans ce monde technologique qui évolue si rapidement. Cette tendance ne concernait pas seulement Play Framework mais plus généralement l’ensemble des produits proposés par Typesafe, et notamment scala.

C’est bien entendu leur droit mais c’était parfois à la limite du ridicule. Je me souviens notamment avoir vu une présentation de Play Framework au Lyon JUG dans laquelle le présentateur nous expliquait qu’avec Play Framework on n’avait pas besoin d’IDE pour coder et il nous invitait à utiliser un simple éditeur de texte. Certes les IDE ne sont pas des outils parfaits, ils sont parfois gourmands en ressources, ils ont plein de défauts, mais ils nous assistent dans notre travail pour nous faire gagner du temps précieux, surtout avec un langage comme Java qu’ils maîtrisent très bien.

Cette page de la documentation montre quelques autres exemples de l’anticonformisme de Play Framework. Le nom des packages ne respecte volontairement pas la convention Java (pas de préfixe com.company). Au début on se dit c’est vrai, finalement autant ne pas s’encombrer avec ça, et puis à force de lire des stack traces, on se dit que finalement le préfixe permet très rapidement d’y voir plus clair. On peut également citer le fait que les sources de l’application sont dans le répertoire app au lieu du src/main/java habituel. Individuellement, ces exemples sont anecdotiques, mais, mis bout-à-bout, ils finissent par créer un environnement sensiblement différent de ce à quoi on est habitués pour un gain qui est bien souvent négligeable quand ce n’est pas contre-productif.

Changement de direction

Mon retour d’expérience concernait Play Framework 2.3. Nous en sommes maintenant à la version 2.5. La version 2.4 annonçait les premiers signes du changement, la version 2.5 récemment sortie confirme très largement ce changement de direction. Voilà les 3 principales améliorations récentes qui font que Play Framework est en train d’arriver à l’âge adulte.

Injection de dépendance

La version 2.4 annonçait la couleur. Elle encourage fortement les développeurs à utiliser l’injection de dépendance. Play gère désormais lui-même toute la partie injection de dépendance via Guice. Il faut noter que les versions précédentes ne fermaient pas complètement la porte à l’injection de dépendance mais c’était à nous, développeurs, de la gérer en prenant la main sur l’instanciation des contrôleurs.

La vraie bonne nouvelle pour moi dans ce changement c’est l’intention clairement annoncée dans les notes de version de la 2.4 de se débarrasser de la notion de contexte global (attaché au thread d’exécution de chaque requête) et par là-même de toutes les méthodes statiques qui permettent d’y accéder.

Je vois en ce changement une grosse amélioration au point de vue de la testabilité. L’injection de dépendances est en effet un élément à part entière des 5 principes de base SOLID de la programmation orientée objet. Une API définie via des méthodes statiques implique en effet un couplage fort vis-à-vis de son implémentation. Pour contourner ce problème, Play proposait des outils permettant de faire tourner son code de test au sein d’un faux contexte global, mais c’est encore bien plus simple si on peut se découpler complètement de ce contexte sans avoir à tout abstraire manuellement.

Le contexte global accessible de n’importe où présentait à mon sens un deuxième problème qui est également en train de disparaître. Il était tellement facile d’accéder au contexte (à la requête courante par exemple), qu’on a tendance à l’utiliser n’importe où, y-compris dans du code métier où ça n’a pourtant aucun sens. De base, nous avons tendance à nous coupler trop fortement aux outils que nous utilisons et ce mécanisme augmente largement la tentation de le faire.

Pour limiter l’impact lors des migrations il a été décidé de se séparer du contexte global version après version. La version 2.5 enfonce un peu plus le clou sur ce sujet-là en poursuivant le remplaçant du tout statique par l’injection de dépendance.

API Java enrichie

Je me demandais dans mon premier retour d’expérience si l’API Java de Play Framework (qui permet d’interagir avec Play en Java) n’était pas en sursis. En effet, Play Framework est écrit en scala et un module écrit en Java se charge de faire la passerelle avec l’API scala pour présenter une API exploitable en Java.

L’API Java était en effet largement incomplète et en retard par rapport à celle qui existe en scala. Certaines fonctionnalités n’étaient accessibles que depuis du code scala. On voyait bien que les développeurs Java n’étaient clairement pas la cible de Typesafe à l’époque et que cette API ne représentait donc pas une priorité.

La version 2.5 rattrape tout ce retard et met à niveau l’API Java par rapport à l’API scala.

Du code plus interopérable

Play Framework suit les principes du Reactive Manifesto. Il repose sur Akka et encourage à écrire du code non-bloquant (et donc asynchrone).

Java était assez mal outillé dans les versions précédentes dans ce domaine et ne proposait pas les structures nécessaires pour représenter une promesse. L’API de Play Framework amenait donc ses propres promesses pour compenser cette absence.

Or, si on veut jouer le jeu du code réactif, il faut que tout le code soit réactif (asynchrone), y-compris les accès à la base de données par exemple. Concrètement, cela signifie que l’intégralité du code devait être couplé à l’API de Play Framework pour utiliser les bonnes promesses. Il s’agit là encore d’une augmentation de couplage plutôt indésirable puisqu’elle est très néfaste pour la réutilisabilité du code.

Dans sa version 8, Java apporte le concept de CompletableFuture et propose ainsi une solution alternative aux promesses de Play Framework. La version 2.5 abandonne ainsi ses propres promesses pour utiliser ce qui est maintenant natif en Java. Il est désormais possible d’écrire du code Java standard asynchrone et compatible avec Play.

La migration vers la 2.5 est cependant très lourde pour ceux qui utilisent intensivement les promesses de Play Framework puisque, comme à leur habitude, les développeurs du framework ne s’embarrassent pas à maintenir la compatibilité entre les API des versions successives.

Conclusion

Ce changement de cap est très intéressant pour tous ceux qui travaillent avec Play Framework en Java. Il vient renforcer la crédibilité du framework pour répondre aux problématiques d’aujourd’hui et de demain.

Il semble s’inscrire dans un changement de stratégie bien plus vaste au sein de Typesafe dans lequel même le nom de l’entreprise a changé. Typesafe s’appelle désormais Lightbend. Ce changement a pour objectif de rendre leurs technologies plus agnostiques du langage de développement et donc s’éloigner un peu de scala. Ils justifient ce changement par le fait que la majorité de leurs clients utilisent leurs produits directement en Java.

SBT reste cependant toujours un problème pour moi. Je ne serais pas malheureux de pouvoir m’en passer. Après plusieurs années d’utilisation de Play Framework je ne suis toujours pas capable d’écrire ou de modifier tout seul mon fichier de build sans copier / coller des extraits de code trouvés sur internet. Notons quand même que les améliorations successives du support de Play dans les différentes versions d’IntelliJ IDEA sont très appréciables et permettent de masquer une partie de ce problème.

J’ai hâte de voir ce que nous apporteront les futures versions de Play Framework !

L’image en en-tête provient de Flickr.