Versions temporelles de Java

1. Introduction

Dans cet article, nous discuterons des nouvelles versions temporelles de Java et de leur impact sur tous les types de développeurs.

Les modifications apportées au calendrier de publication incluent la mise à jour de la livraison des fonctionnalités et des niveaux de support pour les versions de Java. Dans l'ensemble, ces changements sont nettement différents de Java qui est pris en charge par Oracle depuis 2010.

2. Pourquoi des versions de six mois?

Pour ceux d'entre nous habitués à la cadence de publication historiquement lente de Java, il s'agit d'un départ assez important. Pourquoi un changement si radical?

À l'origine, Java définissait ses principales versions autour de l'introduction de fonctionnalités volumineuses. Cela avait tendance à créer des retards, comme ceux que nous avons tous expérimentés avec Java 8 et 9. Cela a également ralenti l'innovation de langage tandis que d'autres langages avec des cycles de rétroaction plus serrés évoluaient.

En termes simples, des périodes de libération plus courtes conduisent à des avancées plus petites et plus faciles à gérer. Et les fonctionnalités plus petites sont plus faciles à adopter.

Un tel modèle se marie bien dans les conditions actuelles et permet au développement JDK de fonctionner dans des méthodologies agiles similaires à la communauté qu'il prend en charge. En outre, cela rend Java plus compétitif avec des environnements d'exécution tels que NodeJS et Python.

Bien sûr, le rythme plus lent a également ses avantages, et donc le cycle de publication de six mois joue également un rôle dans un cadre de support à long terme plus large, que nous examinons dans la section 4.

3. Changement de numéro de version

Un aspect mécanique de ce changement est un nouveau schéma de numéro de version.

3.1. Schéma de chaîne de version JEP 223

Nous connaissons tous l'ancien, codifié dans JEP 223. Ce schéma rendait les numéros de version incrémentiels et relayait des informations supplémentaires.

 Actual Hypothetical Release Type long short ------------ ------------------------ Security 2013/06 1.7.0_25-b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Security 2013/10 1.7.0_45-b18 7u45 Security 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60

Si nous exécutons java -version sur une JVM pour la version 8 ou antérieure, nous verrons quelque chose comme:

>java -version java version "1.6.0_27" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

Dans ce cas, on peut deviner que c'est pour Java 6, qui est correct, et la 27e mise à jour, qui est fausse. Le schéma de numérotation n'est pas aussi intuitif qu'il n'y paraît.

Les versions mineures étaient des multiples de 10 et les versions de sécurité remplissaient tout le reste. En règle générale, nous voyons la courte chaîne ajoutée à nos installations locales, telles que JDK 1.8u174. La prochaine version pourrait être JDK 1.8u180, qui serait une version mineure avec de nouveaux correctifs.

3.2. Nouveau schéma de chaîne de version

Le nouveau schéma de chaîne de version « refondra les numéros de version pour encoder non pas la compatibilité et la signification, mais plutôt le passage du temps, en termes de cycles de publication », selon Mark Reinhold dans le JEP.

Jetons un coup d'œil à quelques-uns:

9.0.4 11.0.2 10.0.1

En un coup d'œil, cela semble être un versionnage sémantique; Cependant, ce n'est pas le cas.

Avec le versionnage sémantique, la structure typique est $ MAJOR. $ MINOR. $ PATCH , mais la nouvelle structure de version de Java est:

$FEATURE.$INTERIM.$UPDATE.$PATCH

$ FEATURE est ce que nous pourrions considérer comme la version principale , mais augmentera tous les six mois quelles que soient les garanties de compatibilité. Et $ PATCH est pour les versions de maintenance. Mais c'est là que s'arrêtent les similitudes.

Premièrement, $ INTERIM est un espace réservé, réservé par Oracle pour les besoins futurs. Pour le moment, ce sera toujours zéro.

Et deuxièmement, $ UPDATE est basé sur le temps comme $ FEATURE, mis à jour mensuellement après la dernière version de la fonctionnalité.

Et enfin, les zéros de fin sont tronqués.

Cela signifie que 11 est le numéro de version de Java 11, publié en septembre 2018, 11.0.1 est sa première version de mise à jour mensuelle en octobre, et 11.0.1.3 serait une troisième version de correctif hypothétique à partir de la version d'octobre.

4. Distributions de versions multiples

Ensuite, voyons comment choisir la bonne version.

4.1. La stabilité

En termes simples, Java dispose désormais d'un canal rapide, tous les six mois, et d'un canal lent, tous les trois ans. Chaque version de troisième année est appelée une version LTS.

Sur le canal rapide, le langage libère des fonctionnalités en incubation. Ces fonctionnalités de langage se stabilisent dans la version LTS.

Ainsi, pour les entreprises qui peuvent adopter la volatilité en échange de l'utilisation de nouvelles fonctionnalités, elles peuvent utiliser le canal rapide. Pour les entreprises qui apprécient la stabilité et peuvent attendre la mise à niveau, elles peuvent mettre à niveau à chaque version de LTS.

L'expérimentation avec les versions JDK permet aux développeurs de trouver la meilleure solution.

4.2. Soutien

Il y a aussi, bien sûr, la question du soutien. Maintenant que le support de Java 8 est arrivé à expiration, que faisons-nous?

Et comme indiqué précédemment, la réponse se trouve dans les versions LTS, Java 11 étant la version LTS la plus récente et la 17 étant la suivante . Les mises à jour seront disponibles et prises en charge par des fournisseurs tels qu'Oracle et Azul.

Si nous pouvons faire confiance au support de la communauté, Redhat, IBM et d'autres ont déclaré leur soutien pour l'application de corrections de bogues pour OpenJDK. En outre, le projet AdoptOpenJDK fournit des binaires prédéfinis pour OpenJDK.

4.3. Licence

Une zone de confusion pour certains est la différence entre OpenJDK et Oracle JDK.

En fait, ils sont presque identiques, ne différant que par les correctifs de bogues et les correctifs de sécurité, selon Brian Goetz.

OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.

4.4. Fragmentation

With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.

Of course, containerization could help address this. From Docker and CoreOS to Red Hat's OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.

5. Conclusion

En conclusion, nous pouvons attendre beaucoup plus de l'équipe Java d'Oracle avec une version régulière de Java tous les six mois. En tant que développeur Java, la perspective de nouvelles fonctionnalités linguistiques tous les six mois est passionnante.

Gardons à l'esprit certaines des implications lorsque nous décidons quel est notre canal de mise à niveau si nous avons besoin d'assistance et de licences, et comment faire face à la fragmentation.