Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

111PARTAGES

6  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior 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.
4  0 
Avatar de Traroth2
Membre chevronné 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.
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 05/12/2014 à 17:24
C'est juste qu'on pourrait se poser la question différemment : pourquoi ceci devrait être si important au point d'être intégré dans le langage lui-même ?
Et quel est la limite à cela ? Il y aurait plein de syntaxe possible à intégrer dans le langage. Pourquoi se limiter à cela ?

Pourquoi ne pas intégrer une syntaxe simplifiant le parsing des fichiers ?
Pourquoi ne pas intégrer une syntaxe mathématique plus avancé à la MatLab ?
Pourquoi ne pas intégrer une syntaxe optimisé pour dessiner ?
etc...

La différence entre Java et C# c'est surtout une différence de point de vue et de philosophie.

.NET a fait le choix d'un langage ultra-complet (presque "boulimique" en fonctionnalités), prenant le pas sur les API jusqu'à les masquer.
A l'inverse le langage Java veut rester le plus simple possible. Les différentes fonctionnalités venant plus des API (standard ou non).

Mais ce n'est pas pour autant que l'un est en retard sur l'autre. C'est deux approches différentes...

a++
2  0 
Avatar de 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...
1  0 
Avatar de 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.
1  0 
Avatar de 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...
1  0 
Avatar de 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++
1  0 
Avatar de esperanto
Membre expérimenté 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à.
0  0 
Avatar de 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
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 08/12/2014 à 17:39
Citation Envoyé par tralloc Voir le message
Je ne dis pas que la syntaxe d'une API du genre linq doive être intégré au langage, mais que le temps qu'a mis SUN puis Oracle pour intégrer les lambda dans java retarde l'arrivée d'une telle API dans JPA, et je pense que c'est très bien que ces APIs restent dans JPA, Hibernate ou autres, et que la modularité de ces ajouts est bonne.
Oui mais ce n'est pas forcément la faute du JCP. Y'a surtout eu la vente de Sun qui a retardé pas ma de chose...

Citation Envoyé par tralloc Voir le message
Cela dit maintenant les lambda sont intégrées : ces idées peuvent faire leur chemin. Mais il me semble que depuis qu'on parlait des lambdas jusqu'à leur arrivée définitive, on aura perdu de précieuses années.
Mais on a des lambdas qui s'intègre bien dans le langage et qui sont utilisable avec n'importe quelle API, qu'elle ait été pensé spécifiquement pour les lambdas ou pas.
Le temps gagné n'aurait pas forcément été si significatif si l'on avait eu à devoir remanier grandement toutes les API existante...

a++
0  0