JDK 1.9 n’existera pas !

JDK 1.9 n’existera pas !
Un nouveau format de numérotation est proposé, le schéma actuel est trop contraignant

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 ?

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

Surtout, le 1 au début de la version ne sert à rien. C'est du nommage Schtroumpf.

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...

Citation:

---

Envoyé par Traroth2

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.

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...

Citation:

---

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.

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...

Citation:

---

Envoyé par Uther

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à.

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.

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 :aie:

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à.

Citation:

---

Envoyé par tralloc

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

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

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

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

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++

Hello,
Je comprend tes explications et ton point de vue. Je ne vais pas discuter tes arguments, parce que d'une part tu es beaucoup plus expérimenté que moi, et que d'autre part ce serait peut-être stérile.
Je veux juste rebondire sur la dernière partie.

Citation:

---

Envoyé par adiGuba

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++

---

Effectivement ce sont des applis externes qui implémentent cela.
(Il existe d'ailleurs déjà des choses que j'ai essayé comme QueryDSL qui est bien mais qui est assez lourd à utiliser. Il y a aussi dans JPA les critéria mais la syntaxe n'est pas aussi avancée que celle des linq)
Cependant les gens qui proposent des librairies extérieures se basent sur le JDK, donc pour qu'une librairie puisse proposer une syntaxe équivalente il fallait que l'implémentation des lambda arrivent.
Donc pour que les spécifs intègrent JPA ce genre de syntaxe, on va attendre encore longtemps. Et c'est ça qui m'ennuie parce que pendant ce temps il y a des gens qui se tournent vers .Net parce que les fonctionnalités existent depuis longtemps. (Et petite note personnelle je ne peux pas convaincre certains de mes collègues à se tourner vers java)

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++

Hello
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.

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.
A+

Citation:

---

Envoyé par tralloc

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

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++