accueilLogicielsDéveloppement et Qualité LogicielsÉcosystème Java
 

Évolution des licences Java


Préambule

Article rédigé en novembre 2018.

Les différents composants de Java

Il existe plusieurs plateformes du langage Java :
-  Java SE : Standard Edition. C’est ce qui permet de faire tourner les programmes Java, aussi bien des applications desktop que des programmes type serveur d’application
-  Java EE : Enterprise Edition. Cette plateforme utilise Java SE, et est en ensemble de spécifications pour fournir des services nécessaires aux serveurs d’applications tels que JBoss.
-  Java ME : Mobile Edition. Non pertinent ici
-  Java FX : création d’interfaces utilisateurs sur un poste client (nécessite Java SE).

L’objet de cet article porte sur Java SE : le cœur de Java, ce qui permet de faire tourner les programmes.

Java SE est composé de :
-  JRE : Java Runtime Environment, ce qui permet de faire tourner les programmes Java
-  JDK : Java Development Kit, ce qui permet de compiler du Java ; l’installation du JDK installe également le JRE

Historique

Java a été développé par l’entreprise Sun Microsystems, initialement dans un licence non Open-source. Cependant, l’utilisation de Java était gratuite.

Progressivement, Sun a rendu les différents composants de Java Open-source. En 2006, Sun annonce que le JDK sera rendu complètement Open-source. En 2007, OpenJDK, l’implémentation (par Sun) libre de Java est née.

En 2009, Oracle achète Sun et par conséquent Java. Jusqu’à récemment, la licence d’utilisation de Java n’a pas bougé.

Comme le projet Java est Open-source (le code source est dans le projet OpenJDK), il est tout à fait possible pour n’importe quel éditeur de prendre ces sources et de construire un binaire Java. À noter que pour avoir le droit d’appeler le produit « Java », il est nécessaire de passer un test de compatibilité, TCK, qui lui n’est pas libre (en tout cas jusqu’à récemment).

Le plus souvent, la version de Java installée par les développeurs était la version de Sun, puis celle d’Oracle.

À partir de Java 6, RedHat propose dans ses dépôts une version d’OpenJDK, mais beaucoup d’installations continuent à être celles d’Oracle. D’autant plus qu’il pouvait exister quelques subtiles différences entre OpenJDK et le JDK d’Oracle.

Depuis Java 11, OpenJDK et le JDK d’Oracle sont strictement identiques : les binaires sont produit à partir des mêmes sources, celles du projet OpenJDK.

Nouvelle politique d’Oracle

Description

La nouvelle politique d’Oracle s’applique à partir de Java 11, sortie en septembre 2018.

Depuis cette version, il y aura une nouvelle version de Java tous les 6 mois, en mars et septembre (Java 12 en mars 2019, Java 13 en septembre 2019, …).

À chaque sortie de version majeure, il n’y a plus de support de la part d’Oracle sur la version précédente. Ainsi, quand Java 12 sortira en mars 2019, il n’y aura plus de support (notamment pas de correction de failles de sécurité) sur Java 11.

Une version LTS (Long Term Support) est promue tous les 3 ans. Java 11 est une version LTS, la prochaine sera Java 17. Le support d’Oracle sur une LTS est de plusieurs années (jusqu’à la prochaine LTS, plus du temps supplémentaire pour laisser le temps de migrer).

Une LTS ne signifie pas que pendant 3 ans on a les mises à jour et les correctifs gratuitement. Même avec la LTS, au bout de 6 mois, quand la prochaine version de Java sort, il n’y a plus de support de la part d’Oracle sur la LTS, sauf à souscrire un support commercial chez Oracle.

Cycle de vie de Java https://www.infoq.com/news/2018/01/...

Il est à noter qu’Oracle fournit Oracle JDK (non libre) et Oracle OpenJDK (libre), tous deux construits à partir des sources d’OpenJDK.

Oracle JDK est disponible sous licence commerciale payante (gratuite pour le développement). Sa licence indique que son utilisation en production est soumise à souscription (rappel, c’est à partir de Java 11 ; il est toujours possible d’avoir Oracle JDK 8 en production sans souscription).

https://www.oracle.com/technetwork/...

Oracle fournit donc Oracle OpenJDK, une version libre de Java, identique à la version commerciale Oracle JDK, mais sans support au-delà de 6 mois.

Note : cet article ne traite que des versions LTS de Java ; utiliser une version non LTS impose de changer de version tous les 6 mois, ce qui n’est pas souhaitable.

Impacts

Java 8

Les installations actuelles de Java 8 et inférieures ne sont pas soumises à souscription chez Oracle. Par contre, à partir de janvier 2019, Oracle ne fournira plus de mises à jour et correctifs sur Java 8. Si une faille de sécurité est découverte, Oracle (a priori) ne fournira pas de correctif pour Java 8.

Java 11 et supérieur

L’utilisation de Oracle JDK 11 ou plus en production nécessite une souscription chez Oracle (alors que sous les autres environnements c’est gratuit). Il ne faut donc pas utiliser Oracle JDK en production.

L’utilisation d’Oracle OpenJDK 11 ou plus est tout à fait possible en production. L’inconvénient est qu’au bout de 6 mois, y compris pour les LTS, Oracle ne fournit plus de mises à jours et correctifs sur cette version.

Alternatives au Java d’Oracle

Le projet contenant le code source de Java OpenJDK est libre. Il existe plusieurs éditeurs fournissant leur version de Java, basée sur OpenJDK.

Depuis Java 11, les binaires construits à partir d’OpenJDK et ceux d’Oracle JDK sont les mêmes (ce n’était pas forcément le cas avant, notamment sur des composants tels que Swing).

Les fournisseurs de binaires basés sur OpenJDK les plus connus sont :
-  Azul
-  IBM
-  RedHat (IBM maintenant)
-  Amazon depuis peu

RedHat fournit depuis plusieurs années ses distributions de Java, et ce sont celles qui sont installées sur des serveurs RedHat quand on lance la commande yum install java-1.8.0-openjdk-devel par exemple.

Ce n’est pas parce que Java 8 ne sera plus supporté « gratuitement » par Oracle en janvier 2019 que c’est le cas pour tous les autres distributeurs de Java. Par exemple, RedHat s’engage à supporter Java 8 jusqu’en 2023 :

Support Java de RedHat https://access.redhat.com/articles/...

Depuis l’annonce du changement de licence par Oracle, le projet communautaire AdoptOpenJDK (https://adoptopenjdk.net/) s’est créé afin de pouvoir fournir des binaires de Java sur toutes les plateformes, à partir des sources du projet OpenJDK. Les sponsors de ce projet sont notamment Azul (qui fournit déjà une version de Java), IBM (qui fournit aussi sa version de Java), Microsoft (pour la plateforme Azure).

La roadmap prévue pour ce projet est :

Roadmap AdoptOpenJDK

Les différents sponsors sont des habitués de la construction et mise à disposition de binaires Java. RedHat est un contributeur important d’OpenJDK et rétroporte les correctifs dans les versions qu’il supporte. Comme AdoptOpenJDK utilise les sources d’OpenJDK, le niveau des versions d’AdoptOpenJDK sera le même que les versions officielles RedHat ou Oracle par exemple.

À noter qu’AdoptOpenJDK ne fournit pas de support payant (le support est celui d’un projet Open source classique).

Choix du distributeur Java

Choix possibles

Vu les paragraphes précédents, il faut éviter d’utiliser le Java d’Oracle, que cela soit Oracle JDK (souscription requise pour la production) ou Oracle OpenJDK (pas de support après 6 mois, y compris pour la LTS).

Il faut donc utiliser OpenJDK d’un autre éditeur.

Le choix logique est d’utiliser la version fournie par la distribution.
-  Pour Windows, il n’y en a pas. Je recommande donc la version d’AdoptOpenJDK.
-  Pour Linux, utiliser la version packagée par sa distribution, ou AdoptOpenJDK, en fonction de la roadmap et du soin apporté aux mises à jours et correctifs d’OpenJDK de cette distribution.

En pratique

Ici le terme RedHat est à prendre au sens RedHat/CentOS.

Ne pas installer Oracle JDK 11

Quoiqu’il arrive, il ne faut pas utiliser Oracle JDK 11 ou plus en production. Cela nécessite une souscription. Afin d’être cohérent, ne pas utiliser du tout Oracle JDK ou même Oracle OpenJDK (environnement de développement, recette, …) y compris sur les postes développeur si possible (utiliser plutôt AdoptOpenJDK sur Windows).

Pour les applications avec Java 6 ou moins

Il n’y a déjà plus de support ni d’Oracle ni d’autres fournisseurs de Java (RedHat, …), il faut migrer vers OpenJDK 8 (binaire de la distribution).

Pour les applications avec Java 7

Si c’est Java d’Oracle, il n’y a plus de support, il faut migrer vers OpenJDK 8 (binaire de la distribution ou AdoptOpenJDK).

Si c’est le Java de RedHat, il y a encore du support jusqu’en 2020. Cependant, il est très fortement recommandé de migrer vers OpenJDK 8 (binaire de la distribution ou AdoptOpenJDK) afin de résorber l’obsolescence. La migration Java 7 vers Java 8 devrait se faire normalement sans trop de problème.

Pour les autres distributions, étudier le support apporté par cette distribution à Java.

Pour les applications avec Java 8

Si c’est Java d’Oracle, il n’y a plus de support à partir de janvier 2019, il faut passer sur OpenJDK 8 (binaire de la distribution ou AdoptOpenJDK).

Si c’est le Java de la distribution et qu’il est supporté, c’est ok (c’est le cas pour RedHat).

Appliquer les mises à jour

Même si on est en OpenJDK 8 (binaire de la distribution ou AdoptOpenJDK), il faut appliquer régulièrement les mises à jour (yum update java-1.8.0-openjdk-devel par exemple), car sinon on utilise des versions avec potentiellement des failles de sécurité.

Besoin de support payant ?

Ce document a supposé depuis le départ que l’on ne souhaite pas acheter le support payant auprès d’Oracle. On peut cependant se poser la question de pourquoi.

(Disclaimer, expérience personnelle) Depuis que je fais du Java (Java 1.2 – 1998), je n’ai jamais rencontré un cas où un bug sur un des composants du JDK nécessitait d’ouvrir un ticket de support chez Sun ou Oracle. L’utilisation majoritaire qui est faite de dans les EPST est extrêmement classique. Nous ne sommes pas dans le cas d’entreprises utilisant des fonctionnalités très avancées de Java (tuning complexe du Garbage Collector, besoins extrêmes de latence, rapidité à la ns, …) pour qui le moindre bug génère immédiatement des pertes.

Autrement dit, je pense que les bugs dans l’implémentation de Java du ressort d’OpenJDK seront détectés bien avant par d’autres avant qu’on ne les rencontre dans les EPST (si on les rencontre un jour).

Cela étant dit, il doit surement exister des projets dans des laboratoires qui poussent la JVM dans ses retranchements, et alors la question mérite d’être posée pour ces cas-là.

Un progiciel installe lui-même Java

Il existe le cas particulier de progiciels qui installent eux-mêmes Java lors de l’installation du produit. Dans ce cas, il faut voir avec l’éditeur quelle est la version, le mode de licence, qui est le fournisseur du Java qu’il installe (Oracle JDK, OpenJDK de RedHat, OpenJDK d’IBM, version 7, 8, …).

Surtout, demander à l’éditeur :
-  Quelle est sa roadmap de mise à jour des versions, afin de s’assurer que c’est toujours une version supportée qui est installée
-  Si c’est Oracle JDK, quelle est son engagement vis-à-vis de l’utilisation Oracle JDK en production ?

Une tendance de fond émerge, et beaucoup de distributeurs logiciels deviennent compatibles avec OpenJDK, voir abandonnent Oracle JDK pour installer Java d’un autre distributeur.

Conclusion

Ne pas utiliser le Java fourni par Oracle, utiliser OpenJDK.

Utiliser les versions OpenJDK fournies par les distributions Linux, ou AdoptOpenJDK le cas échéant.

Rester sur les LTS.

Mettre à jour régulièrement les versions correctives.

Contacter les éditeurs qui fournissent une version de Java avec leurs produits.

Ressources

Termes de la licence Oracle pour Java SE

https://www.oracle.com/technetwork/...

Blog RedHat : le futur de Java et les mises à jour OpenJDK sans le support d’Oracle

https://developers.redhat.com/blog/...

Blog RedHat : migrer d’Oracle JDK vers OpenJDK

https://developers.redhat.com/blog/...

Blog « All You Need To Know For Migrating To Java 11 »

https://blog.codefx.org/java/java-1...

Blog « It’s time ! Migrating to Java 11 »

https://medium.com/criciumadev/its-...

« Java is still free » rédigé par les Java Champions

https://docs.google.com/document/d/...

Blog de Stephen Colebourne

« Java is still available at zero-cost »

https://blog.joda.org/2018/08/java-...

« Time to look beyond Oracle’s JDK »

https://blog.joda.org/2018/09/time-...

« Oracle’s Java 11 trap - Use OpenJDK instead ! »

https://blog.joda.org/2018/09/do-no...

 

Stéphane DERACO
Envoyer un courriel

 


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits