Juillet 2017 et la sortie de Java 9 a marqué un changement majeur dans le cycle des releases de Java.
En effet, depuis cette date, une nouvelle version de Java sort tous les 6 mois. C'est ainsi que Java 10 est sorti le 20 mars 2018 et que Java 11 va sortir le 25 septembre 2018.
Si Java 9 a constitué une release relativement importante, non pas au niveau langage (comme ce fût le cas pour Java 8) mais plutôt au niveau plateforme, cette accélération des cycles des releases a pour effet d'avoir un périmètre d'évolution plus modeste sur les différentes versions. Quels sont les impacts pour les équipes de développement ?

Et le support dans tout ça ?

Alors que nous avions l'habitude de bénéficier d'un support dans le temps relativement confortable des versions de Java, cette augmentation de la fréquence de sortie de versions de Java va avec la décision d'Oracle de ne proposer un support long terme (LTS) que tous les 36 mois. Ainsi, toute version intermédiaire entre deux versions bénéficiant de LTS perd tout support dès lors qu'une version ultérieure est mise à disposition.

Explications avec du concret :

  • Java 8 bénéficie d'un support long terme
  • Java 9 ne bénéficie pas d'un support long terme, et au 20 mars 2018 (sortie de Java 10) son support expirait
  • Java 10 ne bénéficie pas d'un support long terme, et au 25 septembre 2018 (sortie de Java 11) son support va expirer
  • Java 11, dont la sortie est imminente, bénéficiera d'un support long terme [Mise à jour au 3/10/2018]payant auprès d'Oracle[/Mise à jour]

En d'autres termes, ceux qui auraient construit une nouvelle application reposant sur Java 9 (ou migré une application vers Java 9) sont devant leurs responsabilités en cas de problème de production puisque, même si le problème venait d'un bug de Java, Oracle leur indiquerait poliment d'utiliser Java 10 (et leur indiquera bientôt d'utiliser Java 11).

Et une fois que la version 12 sera sortie, si vous vous hasardez à l'utiliser, il vous faudra suivre le rythme des mises à jour jusqu'à la version 17 pour retrouver la sérénité d'une LTS.

[Mise à jour au 3/10/2018]

Les choses sont plus compliquées puisque Oracle a décidé, à compter de Java 11, de n'accorder un usage du JRE/JDK en production qu'en échange d'une licence payante, ce qui évidemment a provoqué un tollé mais surtout permis de remettre en avant OpenJDK et la communauté dont certains acteurs ont déjà pris l'engagement d'un support gratuit sur du long terme pour Java 11.

[/Mise à jour]

Êtes vous le dernier à migrer ?

Vous comprendrez sans doute pourquoi le pourcentage d'application utilisant une version supérieure à Java 8 n'est pas encore significatif. En effet, outre l'effort de migration, l'impact de ce changement sur le support d'Oracle est relativement dissuasif.
Vont-ils pour autant rester sur Java 8 encore longtemps ? La réponse se trouve en ligne puisque tout support long terme possède une date d'expiration : celle ci correspond à janvier 2019 (aux dernières nouvelles, susceptible d'être repoussée d'après la légende).

Oracle will continue to provide Public Updates and auto updates of Java SE 8, until at least the end of December 2020 for Personal Users, and January 2019 for Commercial Users.
Le sujet du support est d'ailleurs plus complexe, en témoigne les récentes communications d'Oracle et réactions, mais les évoquer serait s'écarter du sujet de cet article.

[Mise à jour au 3/10/2018]

Il reste pertinent d'évoquer le cas de Red Hat qui a récemment pris l'engagement d'apporter un support étendu sur Java 8 jusqu'en 2023 en rendant disponible sur OpenJDK toutes les corrections de failles critiques ou bugs sur lesquels il aurait à intervenir pour ses clients

[/Mise à jour]

A quoi m'attendre ?

En tant que développeur ou responsable d'application Java, il faut donc s'attendre à prendre une décision d'ici à janvier 2019 puisqu'il faudra passer à la casserole pour bénéficier d'un support de la part d'Oracle et/ou disposer d'une version du JDK / JRE 8 corrigeant un éventuel défaut sur la dernière version publique [Mise à jour au 3/10/2018], ou il faudra basculer sur un build OpenJDK 8 pour pouvoir profiter de l'effort produit par la communauté (Red Hat en chef de file)[/Mise à jour].

Si vous écartez les deux options précédentes, la fenêtre de temps pour basculer de Java 8 à Java 11 est donc relativement mince puisque limitée à 4 mois. En 4 mois, il vous faudra peut-être pour une (ou plusieurs) applications migrer de 3 versions en production, sans pouvoir se permettre le luxe de faire cela par étapes (pour ce qui est de la production évidemment), de quoi éprouver l'agilité des équipes qui ont l'habitude de mettre en production assez régulièrement. Néanmoins, là où ceux-ci auront 4 mois (s'ils sont bien dans les starting-blocks), ceux qui ont pris l'autre option n'ont aucun délai à compter du 25 septembre puisqu'ils devront migrer de Java 10 (je suppose que c'est la version courante de leur application en production) à Java 11 sans autre alternative en cas de problème sur la dernière version de maintenance de Java 10.

Petite parenthèse : pourquoi avoir migré à Java 9 ou ultérieur ? Non pas nécessairement pour des fonctionnalités offertes, mais pour la promesse d'une amélioration de performances. Et peut-être que vous pouvez même tirer profit d'un JRE 9 ou ultérieur sur votre application développée pour l'instant en Java 8 si aucun problème de compatibilité ne se pose (et le seul usage d'un JRE plus récent peut s'avérer être l'opportunité de bénéficier d'une amélioration de performance).

Si vous êtes aujourd'hui en production avec Java 10, félicitations vous avez sans doute fait le plus dur et vous avez déjà pris l'habitude de basculer sur une nouvelle version de Java dès sa sortie. Vous avez sans-doute essuyé des plâtres comme en témoigne Stephen ou vous avez eu beaucoup de chance / une application de faible complexité.

Bien évidemment, si vous avez suivi les actualités de Java ces dernières années, vous avez conscience que l'effort le plus significatif concernera le passage de Java 8 à Java 9 puisque ce ne sont pas moins de 42 mois qui séparent les sorties de ces deux versions (contre je le rappelle 6 mois entre Java 9 et Java 10, puis Java 10 et Java 11). Vous savez probablement aussi nommer l'une des avancées significatives amenés par Java 9, j'ai nommé la modularisation. Il ne s'agira pour autant pas de négliger les bénéfices / changement, mais surtout retraits / incompatibilités amenées par Java 10 et Java 11.

Pourquoi parler de ce sujet ?

C'est ainsi que, outre d'éventuelles publications (très liées à mon temps libre) autour de cette thématique, je propose dès octobre une formation de 2 jours visant à vous permettre d'appréhender les tenants et aboutissants d'un passage de Java 8 à Java 11.
Vous pensez que vous allez devoir modulariser toute votre application ? Vous pensez que la majeur partie de vos efforts consistera à rendre votre application compatible avec le système de modules introduit par Java 9 ? Détrompez-vous, je ne vous parlerai pas pendant de jour de modularisation, nous n'en feront d'ailleurs pas une obsession sauf si c'est la priorité des priorités pour vous (et le reste du groupe évidemment).

Si cette formation, disponible sur Paris ou en région en format inter-entreprise ou intra-entreprise, avec possibilité d'ajustements sur le contenu, vous intéresse, je vous invite à prendre contact).