IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

JDK 1.9 n’existera pas !


Sujet :

Java

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 287
    Points
    12 287
    Par défaut 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 ?

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

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 428
    Points
    2 428
    Par défaut
    Surtout, le 1 au début de la version ne sert à rien. C'est du nommage Schtroumpf.

  3. #3
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 161
    Points : 7 941
    Points
    7 941
    Par défaut
    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...

  4. #4
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 4 481
    Points : 14 758
    Points
    14 758
    Par défaut
    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.

  5. #5
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    août 2005
    Messages
    6 765
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 6 765
    Points : 22 639
    Points
    22 639
    Billets dans le blog
    50
    Par défaut
    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.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  6. #6
    Membre régulier
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    février 2008
    Messages
    48
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Conseil

    Informations forums :
    Inscription : février 2008
    Messages : 48
    Points : 75
    Points
    75
    Par défaut
    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...

  7. #7
    Membre émérite
    Inscrit en
    janvier 2006
    Messages
    701
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 701
    Points : 2 585
    Points
    2 585
    Par défaut
    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à.

  8. #8
    Membre averti
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2006
    Messages
    380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2006
    Messages : 380
    Points : 311
    Points
    311
    Par défaut
    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.

  9. #9
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 800
    Points
    48 800
    Par défaut
    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

  10. #10
    Membre averti
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2006
    Messages
    380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2006
    Messages : 380
    Points : 311
    Points
    311
    Par défaut
    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à.

  11. #11
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 182
    Points
    23 182
    Billets dans le blog
    1
    Par défaut
    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++

  12. #12
    Membre averti
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2006
    Messages
    380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2006
    Messages : 380
    Points : 311
    Points
    311
    Par défaut
    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 Voir le message

    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)

  13. #13
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 182
    Points
    23 182
    Billets dans le blog
    1
    Par défaut
    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++

  14. #14
    Membre averti
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2006
    Messages
    380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2006
    Messages : 380
    Points : 311
    Points
    311
    Par défaut
    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+

  15. #15
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 182
    Points
    23 182
    Billets dans le blog
    1
    Par défaut
    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++

Discussions similaires

  1. javac n'est pas reconnu sous mon jdk?
    Par lalouvesijetattrape dans le forum Débuter avec Java
    Réponses: 6
    Dernier message: 05/04/2020, 16h49
  2. Réponses: 2
    Dernier message: 10/08/2009, 14h34
  3. [JDK] installation ou pas besoin
    Par mafanta dans le forum Général Java
    Réponses: 9
    Dernier message: 24/09/2008, 17h06
  4. Très débutant : je n'arrive pas à faire fonctionner le JDK
    Par miltonis dans le forum Général Java
    Réponses: 20
    Dernier message: 19/10/2005, 22h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo