Humeur, Java, Java 8

Java 8 est là !

Et même plus précisément ici ! Si l’on compte que la version de Java qui aurait dû porter les lambda expressions est la 7, qu’elle aurait dû sortir deux ans après la 6, elle-même sortie en 2006, et si l’on compte que la version était annoncée pour le 18 mars, et que nous ne l’avons eue qu’à 19h48, cela nous fait environ 6 ans, 19 heures et 48 minutes d’attente, dont environ 6 années de « retard ». Retard est un mot un peu curieux, car la version que nous avons aujourd’hui est certainement très différente de celle que nous aurions eue il y a 6 ans.

Une version majeure, dans tous les sens

Mark Reinhold nous l’a dit à Devoxx 2013 : cette version est la mise à jour la plus importante du langage et de ses API depuis que Java existe. Le nombre de classes modifiées par l’arrivée des lambda expressions en Java 8 est plus important que le nombre de classes modifiées par l’introduction des génériques en 2004, lors de l’arrivée de Java 5. Avec Java 8 tout change : le langage, ses API, et, même si cela a moins d’impact sur notre travail de développeur au quotidien, la JVM elle-même change.

Qui plus est, les patterns les plus profondément ancrés dans nos habitudes changent eux-mêmes. Au premier rang le pattern Iterator, bread and butter de tout développeur Java depuis 15 ans que l’API Collection a été introduite. L’API Collection ne change pas, ou peu, on peut continuer à l’utiliser comme avant, et elle continuera de rendre les mêmes services qu’elle rend depuis 15 ans. En revanche, apparaît à côté l’API Stream, qui apporte de nouvelles façons de traiter les données. Un stream se connecte à une collection, et permet d’effectuer des map / filter / reduce de façon élégante et efficace. On serait tenté d’ajouter « de façon simple », mais cette API n’est certainement pas si simple à maîtriser.

La croisée des chemins pour les développeurs

Et c’est là que les choses se compliquent. Passer de Java 4 à Java 6 ou 7 pouvait certainement se faire à l’intuition. Un peu de doc sur les API dont on a vraiment besoin, une formation ou deux sur les points nouveaux du langage, peu nombreux, et la migration pouvait se faire sans douleur.

Avec Java 8, les temps changent. « Se mettre » à Java 8 va requérir un vrai travail, et une remise en cause de ce que l’on sait, ou plutôt croit savoir. Les lambda expressions et l’API Stream s’appuient sur quelques nouveautés.

  • Un nouveau concept d’interfaces, avec des méthodes par défaut et des méthodes statiques, ça ne devrait pas être trop dur à avaler, les concepts sont nouveaux mais simples.
  • La notion d’interface fonctionnelle : super facile, il s’agit juste d’une interface qui ne possède qu’une seule méthode abstraite.
  • La notion de lambda expression : plus dur, cela s’appuie sur la notion de classe anonyme, et sur les nouvelles interfaces. Le plus complexe de ce point réside probablement dans la façon dont on utilise ces lambda expressions. Il suffit de jeter un coup d’œil aux interfaces Function et Predicate pour se rendre compte de la difficulté.
  • La notion de Stream. On entre là dans le concret. Il faut comprendre le comment et le pourquoi. Pas si évident.
  • Et puis on finit en apothéose : comprendre la notion de collecteur, et les API associées. Techniquement les choses ne sont pas si compliquées. En pratique, ce sont de nouveaux patterns à apprendre, une nouvelle façon de raisonner et de concevoir les traitements de données. Cela revient presque à passer d’un modèle de programmation impérative, à un modèle fonctionnel. Les afficionados du « fonctionnel » vont crier victoire, mais ce n’est pas sur ce plan qu’il faut se placer. Il faut comprendre que cette migration de façon de penser va en faire souffrir plus d’un.

Quels enjeux, et pour qui ?

Vu les opportunités que Java 8 ouvre, il ne m’étonnerait pas que les migrations se fassent plus vite vers Java 8 que vers les autres versions. Je suis toujours surpris lors des nombreuses présentations que je fais, que ce soit en BBL ou dans les JUG, de l’intérêt que suscite cette version, et de l’enthousiasme que montrent les développeurs pour adopter cette version. Je pense que l’adoption de Java 8 se fera plus rapidement qu’on ne le croit, au moins sur une certaine partie des projets. Franchement, un projet qui s’offre une migration aujourd’hui aurait bien tort de ne pas choisir Java 8 : le coût sera à peu de choses près celui d’une migration vers Java 7, et les opportunités ouvertes seront, elles, incomparablement plus larges. 

Dans les années qui viennent, les écoles et universités vont mettre leurs formations à jour (si ce n’est déjà fait), et les prochaines générations de jeunes diplômés, qui n’auront pas connu l’avant Java 8, trouveront ces nouvelles notions, qui ne seront pas nouvelles pour eux, naturelles. Il y aura donc trois catégories de développeurs dans les entreprises :

  • les jeunes diplômés, bien formés, opérationnels ou presque, sur tous ces sujets ;
  • les développeurs expérimentés, qui se sont mis à jour, et qui continueront de capitaliser sur leurs acquis : l’alliance du savoir et de l’expérience ;
  • et les développeurs expérimentés, qui resteront coincés sur la case « Java 7 ». Pour ceux-là la situation va être dure, car ils resteront sur le bord de la route.

Quand on est développeur, on est habitué à se remettre en cause régulièrement. L’arrivée de Java 8 ne fait pas exception, et les enjeux sont de taille. Il y a déjà un avant Java 8, et un après. Un virage à ne pas manquer. Pourvu que cette dernière catégorie se vide rapidement, on va tâcher d’y travailler.