JDK 1.9 n'existera pas ! Un nouveau format de numérotation est proposé
Le schéma actuel jugé trop contraignant

Le , par Amine Horseman, Expert éminent sénior
JDK 1.9, la prochaine version de kit de développement pour Java 9 n’existera pas. En effet, une proposition d’un nouveau schéma pour le numérotage des versions de Java est en cours d’étude.

Le nouveau schéma, proposé le 20 octobre dernier, sous la référence JEP 223, aura pour but de revoir le format de la chaîne de version du JDK de telle sorte qu'il soit plus facile de distinguer les révisions majeures, mineures, et les mises à jour de sécurité. Inspiré du principe du « versionning sémantique », il aura l’avantage d’être facilement compréhensible par les humains, et en même temps facilement analysable par les programmes.

Ce schéma aura le format suivant « $Major.$Minor.$Security » où $Major sera incrémenté lors d’un changement majeur des spécifications de la plateforme (comme l’arrivée de Java 8 par exemple). $Minor sera incrémenté lors de changements mineurs de la version actuelle (comme la correction de bugs ou quelques révisions dans les API), et finalement, $Security sera incrémenté pour chaque nouvelle mise à jour de sécurité. Ce dernier sera indépendant de $Minor et ne sera remis à zéro que lorsque $Major changera.

Pour comprendre les avantages d’un tel format de numérotation, il faut regarder de plus près le schéma actuel : les numéros de versions avec des changements mineurs sont des multiples de 20. Les mises à jour de sécurité sont basées sur la version mineure précédente à laquelle on ajoute le nombre 5 (ou 6 si nécessaire afin de maintenir le numéro de mise à jour impair). Du coup : « JDK 7 Update 55 » et « JDK 7 Update 60 » contiennent toutes deux les mêmes mises à jour de sécurité, alors que n’importe quelle personne non prévenue croirait que « JDK 7 Update 60 » contient 5 mises à jour supplémentaires par rapport à « JDK 7 Update 55 ».

De plus, « JDK 7 Update 60 », « 1.7.0_60 » et « JDK 7u60 » sont actuellement trois mêmes façons de représenter la même version, ce qui rend la comparaison entre les différentes versions fastidieuses pour les programmeurs, alors que le nouveau format proposé sera facilement analysé par cette expression régulière : « [1-9][0-9]*(\.(0|[1-9][0-9]*))* ».

Du coup, ne vous étonnez pas si Java passe du « JDK 1.8 » directement à « JDK 9 » !

Source : JEP 223

Et vous ?

Qu’en pensez-vous ? Bonne évolution pour la plateforme ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Traroth2 Traroth2 - Expert éminent https://www.developpez.com
le 02/12/2014 à 10:26
Surtout, le 1 au début de la version ne sert à rien. C'est du nommage Schtroumpf.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 02/12/2014 à 10:57
Ca semble évident une fois écrit
A vrai dire, ça faisait belle lurette que j'avais arrêté d'essayer de comprendre la numérotation des JDK tellement je n'y comprenais rien...
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 02/12/2014 à 11:40
Citation Envoyé par Traroth2  Voir le message
Surtout, le 1 au début de la version ne sert à rien. C'est du nommage Schtroumpf.

Il ne servait a rien, mais au final il ne gênait pas vraiment. Il serait même logique si on compte que les version majeures seraient celles qui brisent la compatibilité ascendante.
Ce qui était vraiment incompréhensible c'était surtout l'incrément de version par 20 et le fait qu'il y ait de multiples notations.
Avatar de bouye bouye - Rédacteur/Modérateur https://www.developpez.com
le 02/12/2014 à 23:01
Proposition != déjà acceptée, même si ça se fera sans doute. On est en train de tomber dans le travers des journaux qui font le gros titre de propositions de loi pendant 1-2 semaines, propositions qui ne sont jamais votées au Parlement ou qui sont tellement amendées a la fin qu'on ne reconnait plus la proposition initiale.

Sinon pour le reste, c'est la faute a Sun qui a sans cesse changé de format de nommage de ses versions oscillant sans cesse entre la dénomination Java 2 orientée marketing et le versioning normal. Oracle a suivit aussi et a même embrouillé encore tout le monde avec ses JDK7u71 et JDK7u72 sortis récemment tous les deux en même temps...

Pour comprendre les avantages d’un tel format de numérotation, il faut regarder de plus près le schéma actuel : les numéros de versions avec des changements mineurs sont des multiples de 20. Les mises à jour de sécurité sont basées sur la version mineure précédente à laquelle on ajoute le nombre 5 (ou 6 si nécessaire afin de maintenir le numéro de mise à jour impair). Du coup : « JDK 7 Update 55 » et « JDK 7 Update 60 » contiennent toutes deux les mêmes mises à jour de sécurité, alors que n’importe quelle personne non prévenue croirait que « JDK 7 Update 60 » contient 5 mises à jour supplémentaires par rapport à « JDK 7 Update 55 ».

N'importe quoi... en plus cette façon de sauter des versions est propres a Oracle et n'a cours que depuis 1 an et demi-2 ans. Et meme ainsi ils ne la suivent pas toujours (mention encore des deux JDK7 sortis récemment avec numéros 71 et 72)
Avant ils (et Sun avant eux) incrémentaient les numéros de versions avec des changements mineurs généralement que de 1 (sauf changement/ajout d'API ou apport d'un bouleversement complet au niveau sécurité). Et ce n’était franchement pas plus clair que maintenant pour les utilisateurs et on avait d'ailleurs un bien plus grand nombre de versions intermédiaires du JRE/JDK que maintenant (la palme allant au JDK 6).

EDIT - bref, en regardant les historiques des annonces Sun/Oracle, c'est comme d'hab : environs 2 ans se sont écoulés depuis la dernière annonce concernant un changement dans la politique sur la manière de procéder au versionning de Java/sur la politique de publication des mise a jour donc on en propose une autre qui durera probablement aussi longtemps avant que quelqu'un d'autre fasse une nouvelle proposition plus mieux.
Avatar de Schouss Schouss - Membre régulier https://www.developpez.com
le 03/12/2014 à 13:18
C'est triste de voir que les librairies qu'on utilise en java avec Maven & Co ont une normalisation de version depuis belle lurette et que le JDK non...
Avatar de esperanto esperanto - Membre averti https://www.developpez.com
le 03/12/2014 à 17:09
Citation Envoyé par Uther  Voir le message
Il serait même logique si on compte que les version majeures seraient celles qui brisent la compatibilité ascendante.

Sauf que ce n'était pas le cas.
Je me souviens d'avoir vu de franches incompatibilités entre la version 1.0 et la 1.1 : Sun avait reçu ses premières critiques et en avait tenu compte, assez logique.
La version 1.1, c'était en gros la 1.0 corrigée par les remarques des utilisateurs.

Au contraire la 1.2 (appelée aussi Java 2 dans le commerce) introduisait beaucoup de nouveautés mais pratiquement pas d'incompatibilités, tout au plus quelques "deprecations". Et les suivantes ont plutôt été dans le même sens, quitte à se retrouver avec plein d'API redondantes (java.nio par exemple, qui est clairement meilleure que java.io mais sans qu'il soit possible de se passer totalement de l'ancienne).

Donc cette 1.9 devrait probablement être une 2.7 en suivant votre logique. Mais c'est vrai qu'appeler commercialement Java 9 une version dont le numéro informatique est 2.7, même les gars tordus de Sun (qui ont pourtant l'habitude de cette double numérotation tordue, existant aussi pour SunOS) n'allaient pas aller jusque là.
Avatar de tralloc tralloc - Membre actif https://www.developpez.com
le 04/12/2014 à 9:58
Bon, pourquoi pas.

Mais j'aurais attendu qu'ils changent également leurs modes de développement avec un cycle de développement plus court, et apportant à chaque itération un ou deux ajouts phares.
Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 04/12/2014 à 15:04
Pas cool pour l'utilisation en entreprise. On a déjà des outils qui, pour pouvoir couvrir un maximum de clients possibles, sont compatibles java 5,6,7 et 8, si il fallait des cycle plus court, je te dis pas le nombre de version qu'il faudrait se coltinner en test.

Parce qu'une application buisness, tu la met pas à jour tous les 2 mois facilement
Avatar de tralloc tralloc - Membre actif https://www.developpez.com
le 04/12/2014 à 15:18
C'est vrais. Moi je ne me sers de java que côté serveur donc j'ai pas ce soucis...
Mais il me semble aussi que la longueur chaque publication des versions, ainsi que la lourdeur du JCP ralenti énormément la progression du langage, et je pense que si Java a du mal à suivre .Net c'est en partie à cause de ça.
exemple : combien de temps a-til fallu attendre les closures ? et maintenant combien de temps pour que le JPA arrive à un équivalent de linq (avec des closures)

Maintenant je compend ton problème et la solution me semble proche de celle proposée par mozilla, debian :
* une version qui ne change que tous les 1 ou 2 ans qui n'intègre que les corrections de sécurité spécialisée pour les gens qui veulent une version qui ne change pas tout le temps
* et la version qui suit les évolutions pour quand tu attends une fonctionnalité qui pourrais te simplifier la vie sans que ça casse tout ce que tu avais fait jusque là.
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 05/12/2014 à 9:18
Citation Envoyé par tralloc  Voir le message
Mais j'aurais attendu qu'ils changent également leurs modes de développement avec un cycle de développement plus court, et apportant à chaque itération un ou deux ajouts phares.

C'est un peu ce qu'ils ont fait en ciblant une nouvelle release tous les 2 ans...

Citation Envoyé par tralloc  Voir le message
C'est vrais. Moi je ne me sers de java que côté serveur donc j'ai pas ce soucis...

Heu. Même coté serveur tu peux avoir des soucis si la rétrocompatibilité n'est pas respecté !

Citation Envoyé par tralloc  Voir le message
Mais il me semble aussi que la longueur chaque publication des versions, ainsi que la lourdeur du JCP ralenti énormément la progression du langage, et je pense que si Java a du mal à suivre .Net c'est en partie à cause de ça.

C'est surtout que Java ne suit pas .NET, puisqu'il prend bien souvent des orientations très différentes.

Et perso je trouve le JCP et plus globalement tout l'aspect "communautaire" autour des évolutions du langage bien plus rassurant.

Il suffit de voir toutes les discussions envisageant les impacts et problèmes que chaque modification pourrait entrainer, et cela permet aussi de relativiser chaque proposition.
C# semblait boulimique à un moment donné, en intégrant toute les fonctionnalités possibles et imaginables, malgré les impacts que cela pouvait apporter.

Java est plus prudent et plus sûr, ne cherche pas à se disperser à tout prix.

Et cela se ressent bien au final car les deux langages ont souvent des approchent très différentes d'une même fonctionnalités ou de fonctionnalités proches (enums, Generics, Lambda, default-method /extension-method, ...)

Citation Envoyé par tralloc  Voir le message
exemple : combien de temps a-til fallu attendre les closures ?

Il faut quand même relativiser sur le fait que Java est un langage plus ancien, ce qui implique des impacts plus important.
Et encore une fois l’implémentation de Java en permet une utilisation plus rapide, même avec des API pas forcément conçus spécialement pour cela...

Citation Envoyé par tralloc  Voir le message
et maintenant combien de temps pour que le JPA arrive à un équivalent de linq (avec des closures)

Si tu parles d'un équivalent au niveau de la syntaxe (à la SQL), je pense que tu n'en auras jamais.
L'idée étant plutôt de laisser les APIs externes implémenter cela...

a++
Offres d'emploi IT
Analyste développeur
LITOO - Ile de France - Bois-Colombes (92270)
Développeur PHP / Symfony
WEB AREA - Aquitaine - Bordeaux (33000)
Micro informatique h/f
STEF - Lorraine - Moulins-lès-Metz (57160)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil