2017 devait être une année importante pour Java avec la sortie attendue de Java SE 9, Java EE 8 et une position prédominante maintenue à l’index TIOBE.  Par Jean-Michel Doudoux

Depuis les deux annonces faites par Oracle cet été, 2017 pourrait être une année exceptionnelle pour Java si les changements majeurs annoncés se concrétisent :

• l’annonce de l’intention d’Oracle sur son blog de confier la gestion des futures plateformes Java EE à une fondation open source. Depuis hier, le choix en accord avec IBM et Red Hat s’est porté sur la fondation Eclipse avec un changement de nom pour Java EE (voir l’annonce).
• deux posts sur le blog d’Oracle et celui de Mark Reinhold détaillent plusieurs propositions d’Oracle pour modifier la manière dont JAVA SE sera développé et diffusé.

Java SE : nouvelle gouvernance de livraison et changement de licence pour OpenJDK

Java est l’un des langages de programmation les plus utilisés. Cependant, indépendamment de considérations techniques, Java présente plusieurs points qui nuisent à son développement et à sa diffusion :

• Il y a beaucoup de critiques sur le délai entre deux livraisons majeures de Java : la durée entre deux versions est considérée comme trop longue
• La licence actuelle du JDK d’Oracle limite la redistribution de Java

Or l’évolution des solutions dans le secteur IT, telles que les microservices déployés dans le cloud avec des conteneurs, implique que Java évolue pour rester un langage moderne et toujours prisé pour le développement des applications futures.

Le mode de déploiement des applications évolue notamment avec le cloud, les conteneurs et les microservices. Avec ces solutions, il y a de plus en plus d’artefacts à déployer et la licence restrictive du JDK d’Oracle est un frein.

Oracle propose un changement majeur dans la façon dont Java va être construit et livré. Oracle a l’intention de produire et de distribuer les binaires OpenJDK en tant que JDK principal pour les développeurs. Cela remplacerait le JDK d’Oracle sous licence propriétaire comme l’artefact principalement distribué par Oracle.

A partir de Java 9 GA, Oracle prévoit de diffuser les builds d’OpenJDK sous licence GPLv2 with the “Classpath Exception”. Une version binaire pour Linux x64 devrait arriver en premier, et les versions pour Windows et Mac suivront ultérieurement. Le but est de permettre de faciliter la distribution d’applications notamment dans des conteneurs.

La diffusion d’OpenJDK sous licence GPLv2 devrait permettre sa libre redistribution et de ne plus avoir les contraintes actuelles du JDK d’Oracle liées à sa licence. C’est un modèle différent du modèle historique qui consistait à télécharger un JRE et à l’installer de manière centralisée.

Oracle propose aussi de transférer certaines fonctionnalités actuellement commerciales présentes uniquement dans le JDK d’Oracle, comme JFR (Java Flight Recorder), vers OpenJDK. Ces fonctionnalités seront alors utilisables gratuitement (ce qui n’est pas le cas actuellement en production).

Le but est de pouvoir intervertir de manière transparente OpenJDK et le JDK d’Oracle : il est donc nécessaire que les deux possèdent les mêmes fonctionnalités.

Cet alignement nécessitera probablement plusieurs releases mais le but est que OpenJDK et le JDK d’Oracle soient interchangeables pour la fin 2018. Il sera par exemple nécessaire de partager une infrastructure de build permettant de générer les livrables entre Oracle et OpenJDK et de réaliser les mêmes batteries de tests. Il existe déjà, le projet Adopt OpenJDK propose déjà de construire OpenJDK pour différentes plateformes :  Windows x64, Linux x64, MacOS x64, Linux ARM arch64, Linux s360x, Linux ppc64le, AIX ppc64.

Cette mise en avant d’OpenJDK ne remet pas en cause l’existence du JDK d’Oracle dans sa forme actuelle. Le JDK d’Oracle restera la forme avec support commercial pour les clients qui le souhaitent.

Certaines fonctionnalités commerciales packagées séparément du JDK D’Oracle, comme Advanced Management Console, seront toujours proposées dans l’offre commerciale d’Oracle “Java SE Advanced”.

La version 8 du JDK d’Oracle aura des mises à jour gratuites au moins jusqu’à fin 2018, et le support commercial jusqu’en 2025.

Un nouveau modèle de release

L’intention d’Oracle lors de son rachat de Java était de livrer une version majeure de tous les deux ans : cependant ce délai n’a jamais été tenu (pour Java 9, ce délai a été de 3 ans et demi), essentiellement à cause d’un projet (Lambda pour Java 8 et Jigsaw pour Java 9) et de problèmes relatifs à la sécurité.

Oracle propose de changer la gouvernance des releases pour passer d’un modèle reposant sur les fonctionnalités à un modèle reposant sur la durée : il est envisagé d’avoir deux releases majeures par an.

La nouvelle gouvernance de livraison devrait prendre trois formes :

• Release de nouvelles fonctionnalités (feature release) tous les 6 mois
• Release de mise à jour (update release) tous les 3 mois
• Long term support release (LTS release) tous les 3 ans

Les features releases pourront contenir de nouvelles API ou des mises jour d’API et des évolutions dans le langage et la JVM. Ces fonctionnalités ne seront mergées qu’une fois qu’elles seront quasiment terminées pour être sûr de maintenir la date de la release. Si une fonctionnalité n’est pas prête pour une release, il suffit de six mois pour qu’elle puisse être diffusée dans la feature release suivante. Les features releases seront publiées en mars et en septembre en commençant en mars 2018.

Contrairement au modèle actuel (comme ce fût le cas avec les Lambda de Java 8 ou les modules de Java 9), une feature release ne sera pas reportée si une des fonctionnalités n’est pas prête. Cela permet de livrer dans les temps les fonctionnalités qui sont prêtes.

Selon Mark Reinhold, le report d’une fonctionnalité à la release suivante devrait être une décision tactique avec des inconvénients mineurs plutôt qu’une décision stratégique avec des conséquences majeures. C’est un changement radical de stratégie.

Cette accélération des releases a donc pour but de fournir les nouvelles fonctionnalités plus rapidement. D’autant que des releases plus fréquentes impliquent moins de fonctionnalités et donc potentiellement une adoption plus rapide.

Les updates releases contiendront uniquement des corrections relatives à des bugs, à la sécurité ou à des régressions. Il devrait y avoir deux update releases entre deux features releases soit une update release par trimestre prévues au mois de janvier, avril, juillet et octobre.

Le modèle avec support proposé est proche du modèle LTS déjà utilisé par certaines applications open source avec support commercial pour répondre à la demande d’entreprises qui souhaitent avoir de la stabilité et du support pour une durée plus longue. Une nouvelle LTS release sera définie tous les 3 ans avec la première prévue en septembre 2018. Elle offre un support payant avec des mises à jour pour un délai d’au moins 3 ans.

Ce nouveau modèle permettra de choisir le modèle à utiliser en fonction de ses besoins (notamment de nouveautés) ou de ses contraintes liées aux cycles de livraisons :

• OpenJDK qui contiendra les dernières fonctionnalités avec une nouvelle version tous les 6 mois et des mises à jour régulières
• JDK d’Oracle avec support qui favorisera la stabilité

Les modules de Java et les modules incubateur proposés par le projet Jigsaw dans Java 9 devraient faciliter la bonne mise en œuvre de ce nouveau modèle de livraison avec une fréquence plutôt courte entre deux releases. Notamment les fonctionnalités non terminées pourraient être livrées sous la forme de modules incubateur pour permettre de les tester.

Le nouveau modèle de release devrait être mis en place juste après la livraison de la version finale de Java 9 prévue avant la fin de ce mois.

Le numéro de version devrait, encore une fois, changer pour prendre la forme ANNEE.MOIS de livraison soit pour 2018 les versions 18.3 et 18.9. On devrait donc passer de la version 9 à la version 18. D’ailleurs la JSR 383 Java™ SE 18.3 vient d’être créée.

Ce qu’il faut attendre de ces propositions

Tous ces changements ne vont pas être simple à mettre en place et vont aussi nécessiter qu’ils soient discutés avec les contributeurs d’OpenJDK et éventuellement amendés en fonction des retours suggérés avant qu’ils ne soient validés et mis en application. Il est aussi envisagé un assouplissement du JCP (Java Community Process).

Pour l’heure, tous ces changements sont des propositions mais il est fort probable que celles-ci soient validées et mises en œuvre avec des impacts positifs majeurs pour les plateforme Java SE et Java EE.

Notamment ces nouvelles propositions pourraient favoriser l’augmentation de la contribution d’autres acteurs comme IBM ou Red Hat et même de contributeurs individuels.

Il faudra aussi voir comment les autres fournisseurs vont s’accommoder à ce nouveau modèle et l’adopter sachant qu’ils seront toujours soumis à la validation par le TCK (Test Compatibility Kit).

Mais ces changements ne pourront être que bénéfiques pour Java, notamment le nouveau modèle de releases impliquant des livraisons beaucoup plus fréquentes qui permettront d’avoir accès plus rapidement à de nouvelles fonctionnalités.