+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
  1. #21
    Membre du Club
    Inscrit en
    novembre 2004
    Messages
    26
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 26
    Points : 63
    Points
    63

    Par défaut

    Je ne sais pas, au début de la news ça avait l'air sympa ; avant de lire les 36 conditions.
    Ils feraient mieux d'inclure moins de features dans les futurs JDK, ça permettrait de raccourcir le cycle de sorties du JDK. Là, il faut attendre beaucoup trop longtemps avant d'avoir des features qu'on a depuis des lustres sur d'autres plateformes de dev. Et ne parlons pas de la lenteur à laquelle les entreprises migrent d'un JDK à un autre (le JDK7 c'est encore tout nouveau pour certaines). Des cycles plus courts leur forceraient peut être la main.

  2. #22
    Membre averti
    Homme Profil pro
    Lycéen
    Inscrit en
    décembre 2014
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Lycéen

    Informations forums :
    Inscription : décembre 2014
    Messages : 106
    Points : 310
    Points
    310

    Par défaut

    Plutôt que de tout refaire from scratch, il ferait mieux de réutiliser le code de ART ( Android Runtime, le précompilateur java d'Android) qui marche et est largement testé et utilisé, plutôt que de se lancer dans leur propre implémentation infaisable à faire dans les délais de sortie du JDK...

  3. #23
    Rédacteur
    Avatar de Songbird_
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2015
    Messages
    263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 18
    Localisation : France, Ardennes (Champagne Ardenne)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2015
    Messages : 263
    Points : 2 140
    Points
    2 140
    Billets dans le blog
    5

    Par défaut

    la compilation AOT doit être exécutée sur le même système ou sur un système avec la même configuration que celui sur lequel le code AOT sera utilisé par l'application Java
    Je ne vois plus tellement l'intérêt d'utiliser Java, dans ce cas.
    Avant de poster: FAQ Dart; FAQ TypeScript; FAQ Java; FAQ JavaFX.
    Vous souhaiteriez vous introduire au langage Rust ? C'est par ici ou ici !
    N'hésitez pas à contribuer ou nous faire part de vos retours !
    Release Rust FAQ #7


    Ninja Gaiden meets Metal.

  4. #24
    Membre expérimenté Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    888
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 888
    Points : 1 569
    Points
    1 569

    Par défaut

    Citation Envoyé par derderder Voir le message
    Plutôt que de tout refaire from scratch, il ferait mieux de réutiliser le code de ART ( Android Runtime, le précompilateur java d'Android) qui marche et est largement testé et utilisé, plutôt que de se lancer dans leur propre implémentation infaisable à faire dans les délais de sortie du JDK...
    Si je ne me trompe pas, ART c'est uniquement pour l'OS Android.

    Citation Envoyé par Songbird_ Voir le message
    Je ne vois plus tellement l'intérêt d'utiliser Java, dans ce cas.
    Un des intérêts de Java est effectivement Write once run everywhere. Effectivement, avec cette fonctionnalité ce ne sera plus le cas (mais bon personne nous oblige à faire de la compilation anticipée...). A terme, ils visent certainement le Write once compile everywhere ?! Le write once run everywhere n'est pas du tout le seul intérêt de Java.

    Je ne me sens pas vraiment excité par la news, le but est d'éliminer le coût d'évaluation des instructions interprétées mais c'est déjà ce que fait le JIT (ok c'est au runtime mais, ça coûte si cher que ça ? Un serveur, une fois démarré, on n'est pas censé le redémarrer toutes les 20 minutes). En fait, j'ai du mal à voir un use case intéressant pour cette techno (je n'ai pas lu la source) ou alors peut être pour une application pour laquelle on veut des performances aux petits oignons ?!

  5. #25
    Rédacteur
    Avatar de Songbird_
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2015
    Messages
    263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 18
    Localisation : France, Ardennes (Champagne Ardenne)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2015
    Messages : 263
    Points : 2 140
    Points
    2 140
    Billets dans le blog
    5

    Par défaut



    Un des intérêts de Java est effectivement Write once run everywhere. Effectivement, avec cette fonctionnalité ce ne sera plus le cas (mais bon personne nous oblige à faire de la compilation anticipée...). A terme, ils visent certainement le Write once compile everywhere ?! Le write once run everywhere n'est pas du tout le seul intérêt de Java.
    Je suis bien d'accord sur le fait qu'il n'y a pas que la portabilité aisée comme intérêt à utiliser Java, toutefois cette portabilité est quand même bien ancrée dans le coeur du langage.
    Après oui effectivement, on ne nous oblige pas d'utiliser la compilation anticipée, mais, comme tu l'as dit toi-même, je ne vois pas d'intérêt à utiliser cette fonctionnalité.

    En revanche, dans le domaine du jeu vidéo, ça pourrait peut-être permettre à Java de commencer à faire ses premiers pas concrets dans ce milieu.
    Avant de poster: FAQ Dart; FAQ TypeScript; FAQ Java; FAQ JavaFX.
    Vous souhaiteriez vous introduire au langage Rust ? C'est par ici ou ici !
    N'hésitez pas à contribuer ou nous faire part de vos retours !
    Release Rust FAQ #7


    Ninja Gaiden meets Metal.

  6. #26
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 773
    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 773
    Points : 22 637
    Points
    22 637
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par yann2 Voir le message
    Je ne me sens pas vraiment excité par la news, le but est d'éliminer le coût d'évaluation des instructions interprétées mais c'est déjà ce que fait le JIT (ok c'est au runtime mais, ça coûte si cher que ça ? Un serveur, une fois démarré, on n'est pas censé le redémarrer toutes les 20 minutes). En fait, j'ai du mal à voir un use case intéressant pour cette techno (je n'ai pas lu la source) ou alors peut être pour une application pour laquelle on veut des performances aux petits oignons ?!
    Je pense que l'intérêt se situe plutôt coté client pour accélérer le démarrage des applications, en conservant le code natif au lieu de le recompiler à chaque fois...
    Ou alors pour déployer des applications sur des devices spécifiques (TV, etc.)


    Citation Envoyé par Songbird_ Voir le message
    En revanche, dans le domaine du jeu vidéo, ça pourrait peut-être permettre à Java de commencer à faire ses premiers pas concrets dans ce milieu.
    Je pense que le plus gros problème vient plus de l'absence de type "value", qui rend le partage de données difficile entre Java et les appels systèmes natifs...


    a++

  7. #27
    Rédacteur/Modérateur

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

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

    Informations forums :
    Inscription : août 2005
    Messages : 5 453
    Points : 19 682
    Points
    19 682
    Billets dans le blog
    30

    Par défaut

    Coté client et encore plus sur mobile ou le JIT n'est pas forcément autorisé (hum iOS). Donc à la longue ça sera forcément utile pour le port mobile de l'OpenJDK.
    Et puis en chipotant, cela ne change rien au "Write Once, run anywhere". C'est juste, et uniquement pour ceux utilisant cette fonctionnalité, qu'il faudra faire des compilations spécifiques pour les plateformes ciblées, le code Java lui ne changeant pas.

    Par contre, je m'étonne que cette fonctionnalité soit annoncée si tardivement. Plusieurs propositions pour JavaFX pour le JDK9 (telles que le support de WebGL ou encore le remplacement du moteur de rendu Pisces par Marlin un moteur beaucoup plus performant) sont actuellement, après discussions sur la mailing liste de l'OpenJFX, repoussées au calendes grecques (post release JDK 9 ou même JDK 10) sous le prétexte que le JDK9 est déjà "feature complete" et donc qu'il est trop tard pour rajouter des fonctionnalités totalement nouvelles, trop drastiquement différentes ou demandant de trop longues phases de test ou de stabilisation.
    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

  8. #28
    Membre expérimenté Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    888
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 888
    Points : 1 569
    Points
    1 569

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Je pense que l'intérêt se situe plutôt coté client pour accélérer le démarrage des applications, en conservant le code natif au lieu de le recompiler à chaque fois...
    Ou alors pour déployer des applications sur des devices spécifiques (TV, etc.)

    a++
    Ok pour le côté device spécifique mais pour un client lourd j'ai vraiment du mal à voir l'intérêt. Il me semble que le JIT est capable d'optimiser la génération de code machine en analysant la manière dont est utilisée l'application (inline d'une opération souvent appelée par exemple). En générant le code machine au moment de la compilation on perd ces optimisations, non ?


    Bon du coup je suis allé voir la source :
    Motivations

    JIT compilers are fast, but Java programs can become so large that it takes a long time for the JIT to warm up completely. Infrequently-used Java methods might never be compiled at all, potentially incurring a performance penalty due to repeated interpreted invocations.
    Ok, ça aurait été sympa d'avoir des exemples ou chiffres. Parce que, chez moi, Java est déjà super rapide, les seules fois où j'ai des problèmes de performance c'est parce que j'ai fait de la merde

    Ils ont l'air perplexes sur reddit aussi : https://www.reddit.com/r/java/commen...e_compilation/. J'ai beaucoup aimé ce commentaire :

    This is a monster truck feature. Occasionally useful but will be mostly used by jackasses who don't really need it.

  9. #29
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 773
    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 773
    Points : 22 637
    Points
    22 637
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par yann2 Voir le message
    Ok pour le côté device spécifique mais pour un client lourd j'ai vraiment du mal à voir l'intérêt. Il me semble que le JIT est capable d'optimiser la génération de code machine en analysant la manière dont est utilisée l'application (inline d'une opération souvent appelée par exemple). En générant le code machine au moment de la compilation on perd ces optimisations, non ?
    Oui en effet on perdrait certaines optimisations liés au contexte d’exécution.
    Mais apparemment le code AOT peut être recompilé par le compilateur JIT.

    Donc grosso-modo cela pourrait aussi permettre d'exécuter du code natif au lieu du code interprété, tout en bénéficiant d'une compilation JIT si besoin.



    Citation Envoyé par yann2 Voir le message
    Ok, ça aurait été sympa d'avoir des exemples ou chiffres. Parce que, chez moi, Java est déjà super rapide, les seules fois où j'ai des problèmes de performance c'est parce que j'ai fait de la merde
    Je pense que l'intérêt c'est d'améliorer le temps de démarrage.
    Java est très performant pour de "grosses" tâches, mais moins pour un programme qui retourne une valeur immédiatement...

    Le fait d'avoir un java.base précompilé devrait aider de ce coté là.



    a++

  10. #30
    Membre régulier Avatar de l'art souille
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    janvier 2015
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : Conseil

    Informations forums :
    Inscription : janvier 2015
    Messages : 28
    Points : 73
    Points
    73

    Par défaut

    Une excellente étude (IBM) en plusieurs parties sur la compilation real-time Java (notamment Part 2 : JIT et AOT) : http://www.ibm.com/developerworks/vi...time+Java+Part
    Plus tu pédales moins vite, moins tu vas plus vite.

  11. #31
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 196
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 196
    Points : 30 481
    Points
    30 481
    Billets dans le blog
    2

    Par défaut JDK 9 : toutes les fonctionnalités ont été implémentées et la phase Rampdown entamée

    JDK 9 : toutes les fonctionnalités ont été implémentées et la phase Rampdown entamée
    pour la correction de bogues de priorité P1-P3

    Après plusieurs reports, le JDK 9 se dirige tout droit vers sa version stable. Mark Reinhold, l’architecte en chef du JDK chez Oracle, a en effet annoncé que toutes les fonctionnalités ont maintenant été implémentées et intégrées dans le master forest, où réside le code source officiel. Les fonctionnalités ont été gelées, c'est-à-dire qu'ils ne vont plus en ajouter, mais plutôt se concentrer sur la correction des bogues existants sans risquer d'en ajouter de nouveaux. Cela annonce donc le début de la phase de Rampdown.

    Mark Reinhold avait essayé d’entamer cette phase en septembre dernier, conformément à la nouvelle feuille de route après le premier report de la date de sortie du JDK 9. L’architecte en chef du JDK chez Oracle avait envoyé un email à la liste de diffusion OpenJDK pour donner ses objectifs pour cette nouvelle étape. Cette décision n’était toutefois pas réaliste d’après un développeur open source et architecte Java, qui a fait remarquer que les fonctionnalités majeures du JDK 9 n’étaient pas encore toutes finalisées. Cela a donc conduit à un nouveau report de la sortie du JDK 9 et au décalage du reste calendrier. Maintenant que les fonctionnalités sont finalisées, on peut donc aller de l’avant.

    « En fin décembre, nous avons terminé l'étape Feature Extension Complete », écrit Mark Reinhold dans son email. Il s'agit de l'étape à laquelle les JEP et petites améliorations qui ont reçu un délai supplémentaire doivent être implémentées et intégrées dans le master forest. « Nous sommes maintenant dans la première phase du processus de Rampdown, dans lequel nous cherchons à corriger les bogues qui doivent être corrigés et à comprendre pourquoi nous n'allons pas corriger certains bogues qui devraient peut-être être corrigés », a-t-il ajouté.

    Pour cette étape, les objectifs spécifiques définis par Mark Reinhold sont les suivants :

    • corriger tous les bogues P1-P3 qui sont nouveaux dans le JDK 9 ;
    • corriger des bogues P1-P3 supplémentaires ciblés pour JDK 9 si le temps le permet ;
    • reporter explicitement les bogues P1-P2 qui sont nouveaux dans le JDK 9, mais qui ne pourront pas, pour une bonne raison, être fixés dans le JDK 9.

    « Les bogues P4-P5 devraient, en général, être laissés pour les versions futures à moins qu'ils ne concernent seulement la documentation, les démos, ou les tests. Dans ces cas, ils doivent être identifiés comme tels avec les étiquettes "noreg-doc", "noreg-demo", et "noreg-self", respectivement », a rappelé l’architecte en chef du JDK chez Oracle.

    À ceux qui sont responsables de la correction d’un bogue dans la liste de bogues à corriger au cours de la première phase de Rampdown, Mark Reinhold souhaite que le bogue soit corrigé. Si le bogue n’est pas nouveau dans le JDK 9 et que pour une raison il ne peut être corrigé, il demande au responsable du bogue de le retirer de la liste des bogues à corriger dans le JDK 9 ou de spécifier une version future dans laquelle il pourra être corrigé. S’il s’agit d’un bogue P1 ou P2 nouveau dans le JDK 9, le responsable peut faire une demande pour que la correction soit reportée à une prochaine version. Reinhold a exhorté les responsables de la correction des bogues à ne pas changer la priorité d'un bogue afin de le retirer de la liste. « La priorité d'un bogue devrait refléter l'importance de le corriger indépendamment d’une version particulière, comme cela a été une pratique courante pour le JDK depuis de nombreuses années », dit-il.

    Les fonctionnalités ont été gelées, mais le JDK 9 reste ouvert à certaines améliorations si elles sont vraiment justifiées. D’après Mark Reinhold, « de petites améliorations aux nouvelles fonctionnalités seront prises en compte. Les améliorations à faible risque qui ajoutent des petites fonctionnalités manquantes ou améliorent l'utilisabilité peuvent être approuvées, en particulier lorsque les commentaires des développeurs le justifient. » Pour ce qui est des « améliorations qui ajoutent de nouvelles fonctionnalités importantes, [elles] nécessiteront une justification très forte ». Mais celles qui concernent les tests ou la documentation « ne nécessitent pas d'approbation préalable. »

    La version finale du JDK 9 est attendue le 27 juillet 2017, conformément au calendrier dont les étapes en cours et à venir sont les suivantes :

    • 05/01/2017 - Rampdown Start : les Rampdown sont des étapes qui permettent d’appliquer « des niveaux de contrôles croissants » aux changements entrant dans la nouvelle version du JDK. Cette première phase de Rampdown vise à corriger les bogues de priorité P1-P3 ;

    • 09/02/2017 - All Tests Run : tous les tests prévus ont été exécutés, au moins une fois, sur toutes les plateformes supportées ;

    • 16/02/2017 - Zero Bug Bounce : le carnet de bug est complètement pris en compte. Aucun des bugs qui doivent être encore corrigés avant la disponibilité générale de la version ne date de plus de 24 heures, les autres bugs sont reportés à une prochaine version ;

    • 16/03/2017 - Rampdown Phase 2 : à cette deuxième Rampdown, seuls les bugs bloquants peuvent être corrigés ;

    • 06/07/2017 - Final Release Candidate : la date à laquelle la dernière RC doit être proposée et soumise aux tests. Une ou plusieurs RC seront proposées après le Zero Bug Bounce ;

    • 27/07/2017 - General Availability : la version finale, prête pour l'utilisation en production.

    Source : OpenJDK Mailing List

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi :

    JDK 10 : le projet pour l'implémentation de la plateforme Java 10 est ouvert, qu'attendez-vous de cette nouvelle version ?
    Les futures fonctionnalités de JavaFX pour la version 10 de la plateforme Java déjà en discussion sur la liste de diffusion de l'OpenJFX
    Gartner proclame l'obsolescence de Java EE sur le marché des plateformes d'applications, partagez-vous cet avis ?
    Cdlt!
    M.K

  12. #32
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 536
    Points : 52 357
    Points
    52 357

    Par défaut JDK 9 atteint le milestone Feature Extension Complete

    JDK 9 atteint le milestone Feature Extension Complete,
    les JEP qui ont reçu un délai supplémentaire sont désormais implémentés et intégrés dans le master forest

    La sortie initiale de JDK 9 avait été annoncée pour le 22 septembre 2016. Mais Mark Reinhold, architecte en chef du JDK chez Oracle, a demandé un délai supplémentaire de six mois pour la finalisation de Jigsaw, un projet dont l’objectif est de concevoir et de mettre en œuvre un système de modules standards pour Java SE. Après validation de sa proposition, la date de sortie de Java 9 a donc été repoussée au 23 mars 2017, avec donc un décalage dans le reste du calendrier.

    « Nous avons fait beaucoup de progrès sur le projet Jigsaw, l’élément clé de cette version, au cours des huit derniers mois. [...] Malgré ces progrès, à ce stade, il est clair que Jigsaw a besoin de plus de temps. Nous avons récemment reçu des commentaires critiques qui ont motivé une refonte de la fonctionnalité package-export du système de module, sans laquelle nous ne pourrions pas atteindre l'un de nos principaux objectifs. Il existe, en plus de cela, de nombreux problèmes de conception non encore résolus, qui nécessitent du temps pour y travailler », a expliqué Reinhold en septembre dernier, précisant que le nombre de bogues ouverts qui sont nouveaux dans le JDK 9 est également plus important que celui dans le JDK 8. Aussi, il a pu obtenir une rallonge dans le délai de livraison de la version finale de JDK 9 qui est prévue pour le 27 juillet de l’année en cours.

    Selon la feuille de route communiquée par Reinhold, en décembre dernier, JDK 9 a atteint l’étape Feature Extension Complete (les JEP et petites améliorations qui ont reçu un délai supplémentaire ont été implémentés et intégrés dans le master forest). Reinhold l’a d’ailleurs confirmé dans un message sur la liste de diffusion du projet.

    Le 19 janvier, Reinhold a annoncé que le projet est entré dans la première phase du processus Rampdown, des étapes qui permettent d’appliquer « des niveaux de contrôles croissants » aux changements entrant dans la nouvelle version du JDK. Cette première phase de Rampdown vise à corriger les bogues de priorité P1-P3 : il l’a décrit comme un processus durant lequel « nous visons à corriger les bogues qui doivent être corrigés et à comprendre pourquoi nous n'allons pas corriger certains bogues qui devraient peut-être être corrigés ».

    À ce stade du projet, l'ensemble des fonctionnalités est gelé, a expliqué Reinhold, et il est « hautement improbable » que d'autres JEP soient ciblés pour la version JDK 9. Bien que de petites améliorations aux nouvelles fonctionnalités seront prises en considération, « la barre est désormais beaucoup plus élevée ». Les membres de la communauté peuvent demander l'approbation de ce type d'améliorations par le biais du processus FC-extension existant. Ces améliorations peuvent être incluses si elles représentent un faible risque à condition qu’elles ajoutent de petites quantités de fonctionnalités manquantes ou améliorent l'ergonomie, « en particulier lorsqu’elles sont justifiées par un feedback de développeurs ».

    En outre, il a expliqué que les améliorations qui ajoutent de nouvelles fonctionnalités importantes nécessiteront des justifications beaucoup plus importantes. Quant aux améliorations des tests ou de la documentation, elles ne vont pas nécessiter de telles justifications.

    Source : message de Mark Reinhold

  13. #33
    Membre du Club
    Homme Profil pro
    Chômeur
    Inscrit en
    juin 2009
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chômeur

    Informations forums :
    Inscription : juin 2009
    Messages : 23
    Points : 61
    Points
    61

    Par défaut Yeeaaaahhhh

    JDK 9 atteint le milestone Feature Extension Complete,
    les JEP qui ont reçu un délai supplémentaire sont désormais implémentés et intégrés dans le master forest
    Yeah, tous ces termes me mettent de bonne humeur ce matin. Ve masteuw fowest, le maïlessetaune genre les mecs ça fait plus pro , ça m'donne envie de revoir la saison 1 de Stargate SG-1.

  14. #34
    Membre expert
    Avatar de Pill_S
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    2 100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

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

    Informations forums :
    Inscription : janvier 2004
    Messages : 2 100
    Points : 3 408
    Points
    3 408

    Par défaut

    Citation Envoyé par Askeridos Voir le message
    ça m'donne envie de revoir la saison 1 de Stargate SG-1.
    Eclate-toi, Teal'c...

    Ch'ai pas mais c'est des termes tellement esotériques? J'ai l'impression qu'on en pond à la chaîne des biens pires...

    Moi je salue quand même l'arrivée (bien que tardive ^^) d'une release majeure de Java et de quelques fonctionnalités qui vont être bien pratiques (byebye OSGi)
    Si vous posez une question, c'est que vous voulez une réponse, non? Donc merci de surveiller vos sujets, et de les faire vivre jusqu'à leur résolution !!

    "Si l'aventure vous paraît dangereuse, essayez la routine: elle est mortelle...", Confucius, 531 av. JC

  15. #35
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2017
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : février 2017
    Messages : 2
    Points : 3
    Points
    3

    Par défaut Petit à petit...

    On l'aura notre JDK9

    Pas mal de changement intéressant dans cette nouvelle mouture.
    Pour ceux qui seraient intéressé à connaître l'ensemble des changements/évolutions : http://openjdk.java.net/projects/jdk9/

    @Pill_s : je suis pas sûr Qu'OSGI disparaisse de si tôt,
    Je sait que le JDK9 apporte le projet Jigsaw qui est censé apportée de la modularité mais concrètement je n'ai toujours pas compris si cela remplacera réellement OSGI.
    Perso je n'en ai pas l'impression mais à voir plus en détails.

    Si quelqu'un à plus d'info sur la question je suis preneur .

  16. #36
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    915
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 915
    Points : 1 868
    Points
    1 868

    Par défaut

    Citation Envoyé par Pill_S Voir le message
    (byebye OSGi)
    C'est a peu pres impossible car:
    1. Les applis modulaires qui veulent etre backward-compatible ne pourront pas utiliser Jigsaw et devront utiliser OSGi
    2. Jigsaw ne gere pas vraiment de "lifecycle" des modules, ou en tout cas ne laisse pas le developpeur s'appuyer dessus pour gerer son appli (c'est un point tres important en IoT)
    3. Jigsaw ne dispose pas d'une couche service comme OSGi
    4. OSGi a deja beaucoup d'utilisateurs, notamment des tres difficiles -politiquement parlant- a migrer (comme les use-cases embarques)
    5. J'attends de voir si les developpeurs Java "finaux" vont vraiment avoir quelque chose a faire de Jigsaw pour leurs apps. Au final, les applis sont deja quasiment toutes dans des conteneurs modulaires genre OSGi ou Java EE, donc ajouter la modularite a la couche de la JVM ne devrait pas leur changer grand chose.

    Les raisons techniques (1,2,3) rendent par exemple entre impossible et inutile la migration d'applis existantes comme Eclipse ou Karaf

    Au final, j'imagine que seule les applis neuves visant vraiment les perfs optimales (donc l'embarque) vont rapidement adopter Jigsaw, et encore, il faudra attendre que Java 9 soit considere comme robuste avant qu'ils y passent. Pour le dev Java workstation ou serveur, la valeur de Jigsaw est tres faible et inferieure a OSGi.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  17. #37
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 196
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 196
    Points : 30 481
    Points
    30 481
    Billets dans le blog
    2

    Par défaut Oracle prépare les développeurs à la migration vers Java 9

    Oracle prépare les développeurs à la migration vers Java 9
    la documentation Early Access pour le JDK 9 est disponible en ligne

    La sortie de Java 9 est prévue pour le mois de juillet 2017 et depuis le mois dernier, les fonctionnalités ont été gelées pour entamer la phase de Rampdown. Au cours de cette étape, les équipes qui travaillent sur le développement du JDK 9 vont se concentrer sur la correction des bogues, en particulier les bogues de priorité P1-P3 qui sont nouveaux dans cette version, et d’autres bogues de priorité P1-P3 si le temps le permet.

    Ce nouveau virage annonce donc de manière imminente la sortie de la prochaine version du JDK repoussée plusieurs fois. De son côté, Oracle veut préparer les développeurs à la migration vers Java 9. Pour cela, la firme de Redwood City a récemment publié la documentation Early Access pour le JDK 9. En plus de fournir un guide de migration de Java 8 vers Java 9, cette documentation présente les nouveautés dans la nouvelle version de la plateforme Java.

    « Chaque nouvelle version de Java SE introduit des incompatibilités dans les binaires, les sources et les comportements avec les versions précédentes », explique Oracle. Le but de ce guide de migration est donc d’aider les développeurs à identifier les problèmes potentiels et de leur faire des suggestions sur la façon de procéder pour migrer une application Java existante vers JDK 9.

    Les changements les plus importants dans le JDK 9 viennent du projet Jigsaw pour la modularisation de la plateforme Java SE. Cette fonctionnalité « apporte de nombreux avantages, mais aussi de nombreux changements », indique Oracle. « Tout code qui utilise uniquement les API officielles de la plateforme Java SE et les API JDK spécifiques prises en charge doit continuer à fonctionner sans modification. » Par contre, « un code qui utilise certaines fonctionnalités ou des API internes au JDK peut ne pas s'exécuter ou peut donner des résultats différents. » Pour préparer la migration, Oracle suggère de télécharger la dernière build Early Access du JDK 9. Il faut noter que ces builds sont destinées à être utilisées dans des environnements de test, pas en production.

    Avec la build Early Access, Oracle recommande d’exécuter l’application que vous souhaitez migrer avant de recompiler, et de voir ce qui se passe. Si votre programme utilise uniquement des API Java SE standard, il devrait pouvoir s'exécuter sans aucune modification. Si l’application est lancée avec succès, il est conseillé d’examiner attentivement vos tests et vous assurer que le comportement est le même qu’avec le JDK 8. Certains utilisateurs ont en effet remarqué que leurs dates et devises sont formatées différemment.

    Les étapes suivantes dans le guide de migration vers Java 9 consistent à mettre à jour les bibliothèques tierces, compiler l'application et exécuter l'analyse statique jdeps sur le code.

    En ce qui concerne les outils et bibliothèques tiers, il est indiqué dans la documentation qu’il devrait exister des versions mises à jour qui prennent en charge le JDK 9. Il faudra donc consulter les sites web des fournisseurs d’outils et bibliothèques tiers pour obtenir une version de chaque bibliothèque ou outil conçue pour fonctionner sur Java 9. Si des mises à jour existent, il est conseillé de les télécharger et les installer. « Si vous utilisez un IDE pour développer vos applications, il peut vous aider à migrer le code existant », ajoute Oracle. « Les EDI NetBeans, Eclipse et IntelliJ ont tous des versions early access disponibles qui incluent le support de JDK 9. »

    Pour un certain nombre de raisons spécifiques, des erreurs peuvent se produire lors de la compilation à l'aide du compilateur JDK 9. Oracle explique par exemple que la plupart des API internes au JDK sont inaccessibles par défaut, de sorte que les développeurs soient susceptibles d’obtenir des erreurs au moment de l'exécution indiquant que l'application ou ses bibliothèques dépendent d'API internes.

    Pour identifier les dépendances, vous pouvez utiliser l’outil d'analyse de dépendance de Java. Oracle suggère enfin d’exécuter l'outil jdeps sur votre application. Jdeps est un outil d'analyse statique qui vous aide à savoir de quels paquets et classes dépendent vos applications et vos bibliothèques.

    Outre le guide de migration, la documentation Early Access pour le JDK 9 présente les nouveautés dans la nouvelle version de la plateforme Java.

    Téléchargez les builds JDK 9 Early Access

    Sources : Oracle, Guide de migration vers le JDK 9, Nouveautés dans JDK 9

    Et vous ?

    Qu'en pensez-vous ?
    Avez-vous déjà testé la build JDK 9 ? Si oui, partagez votre expérience.

    Voir aussi :

    JDK 10 : le projet pour l'implémentation de la plateforme Java 10 est ouvert, qu'attendez-vous de cette nouvelle version ?
    Les futures fonctionnalités de JavaFX pour la version 10 de la plateforme Java déjà en discussion sur la liste de diffusion de l'OpenJFX
    Gartner proclame l'obsolescence de Java EE sur le marché des plateformes d'applications, partagez-vous cet avis ?
    Cdlt!
    M.K

Discussions similaires

  1. HTML5 ne devrait pas être considéré comme un langage pour créer une page web
    Par Stéphane le calme dans le forum Balisage (X)HTML et validation W3C
    Réponses: 9
    Dernier message: 06/05/2013, 19h26
  2. [AC-2010] ne peux pas être sur deux tournées.
    Par pascal5 dans le forum IHM
    Réponses: 2
    Dernier message: 24/11/2012, 12h03
  3. Optimisation MySQL : suis-je sur la bonne voie ?
    Par dedis dans le forum Requêtes
    Réponses: 1
    Dernier message: 01/09/2010, 16h07
  4. suis-je sur la bonne voie ?
    Par am@123 dans le forum Débuter
    Réponses: 6
    Dernier message: 11/07/2008, 23h52
  5. être ou ne pas être sur un objet
    Par Speed41 dans le forum Delphi
    Réponses: 3
    Dernier message: 24/09/2006, 14h36

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