+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 4 PremièrePremière 1234 DernièreDernière
  1. #41
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2010
    Messages
    28
    Détails du profil
    Informations personnelles :
    Âge : 25
    Localisation : France

    Informations forums :
    Inscription : décembre 2010
    Messages : 28
    Points : 52
    Points
    52

    Par défaut

    Y a un truc qui m'échappe : pourquoi se manifestent-ils seulement maintenant, à 3 mois de la release ? Le projet Jigsaw ne date pourtant pas d'hier.

  2. #42
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2013
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mai 2013
    Messages : 9
    Points : 24
    Points
    24

    Par défaut

    C'est vrai qu'à trois mois d'une release... c'est un peu court pour rebondir. Mais bon, si cela aboutis, cela sera une excellente amélioration pour Java. Le principal avantage sera la taille en mémoire de la JVM qui va considérablement baisser. On rejoint aussi le crédo du C++ : ne t'embarrasse que ce dont tu as la nécessité.
    Par contre si, comme certains semblent le supposer, Oracle se détourne de Java, il risque (tant mieux ?) d'y avoir une reconversion de pas mal de développeur vers d'autres écosystèmes (.Net par exemple) : "Le malheur des uns, fait le bonheur des autres".

  3. #43
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    981
    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 : 981
    Points : 2 042
    Points
    2 042

    Par défaut

    Citation Envoyé par Vyrob Voir le message
    Y a un truc qui m'échappe : pourquoi se manifestent-ils seulement maintenant, à 3 mois de la release ? Le projet Jigsaw ne date pourtant pas d'hier.
    Il faut lire les posts detailles et les discussions en lien.
    Les inquietudes vis-a-vis de Jigsaw et de son interet technique et pour la communaute ont ete manifestees par tous des le debut. La compatibilite avec OSGi ou Maven a ete identifiee comme critique tres tot. Maitenant que Jigsaw a atteint un "pallier", il a ete teste dans ces environnements (OSGi et Maven) et il apparait qu'en l'etat actuel, ca complique tout sans ajouter grand chose. En l'etat actuel, il ne delivre pas les promesses qui ont ete identifiees initialement comme des "requirements".
    Si l'annonce n'est publiee que maintenant, c'est qu'avant, il y avait encore de l'espoir que ca tourne mieux; mais maintenant, Jigsaw est face a un constat d'echec programme, et il est donc temps d'etre plus explicite si on veut que les choses aillent dans le bon sens.

    Le principal avantage sera la taille en mémoire de la JVM qui va considérablement baisser.
    Si par memoire tu entends "espace disque du deliverable", OK. Pour la RAM ou le Heap ca ne devrait pas changer grand chose car les classloaders ne chargent deja que ce qui est utile.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  4. #44
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    octobre 2012
    Messages
    593
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : octobre 2012
    Messages : 593
    Points : 1 188
    Points
    1 188

    Par défaut

    C'est sûr que si au final, ca fait un peu d'OSGI et un peu de Maven, mais en moins bien, tout en ne marchant pas ni avec l'un ni avec l'autre, ça n'a pas d'intérêt...
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  5. #45
    Membre du Club
    Profil pro
    Inscrit en
    décembre 2010
    Messages
    28
    Détails du profil
    Informations personnelles :
    Âge : 25
    Localisation : France

    Informations forums :
    Inscription : décembre 2010
    Messages : 28
    Points : 52
    Points
    52

    Par défaut

    Citation Envoyé par Mickael_Istria Voir le message
    Il faut lire les posts detailles et les discussions en lien.
    Je n'ai lu que cette news effectivement, je n'ai pas été voir les articles qui y sont liés. C'est juste que je pensais qu'avec leur processus de développement, ils se seraient rendu compte dès le début si ça n'allait pas, et de fait n'auraient pas eu besoin d'attendre d'en être à la dernière phase pour manifester leur refus. M'enfin il semblerait que je me sois trompé ! Merci pour l'explication en tout cas.

  6. #46
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 404
    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 404
    Points : 39 422
    Points
    39 422
    Billets dans le blog
    2

    Par défaut Java 9 : une nouvelle proposition d’Oracle pour résoudre l’un des problèmes évoqués par Red Hat

    Java 9 : une nouvelle proposition d’Oracle pour résoudre l’un des problèmes évoqués par Red Hat
    sur le système de modules Java (Jigsaw)

    Comme nous l’avons rapporté récemment, Red Hat et IBM ont décidé de voter contre le projet Jigsaw qui vise à fournir un système de modules standardisé à la plateforme Java. Dans un billet de blog, un ingénieur de Red Hat a exposé les raisons de cette position. Il explique que de nombreux cas de déploiement d'applications largement implémentées aujourd'hui ne sont pas possibles sous Jigsaw, ou nécessiteraient une réarchitecture significative. Il pense également que l’écosystème Java sera perturbé, expliquant que dans certains cas, Jigsaw contredit des années de meilleures pratiques de déploiement d'applications modulaires qui sont déjà couramment utilisées par l'écosystème dans son ensemble. L’un des points également mis en avant par l’ingénieur de Red Hat est la fragmentation de l’écosystème. En raison de capacités d'interopérabilité insuffisantes et d'autres restrictions, il craint qu'il y ait deux mondes de développement de logiciels Java : le monde Jigsaw et le monde « tout le reste » (chargeurs de classes Java SE, OSGi, modules JBoss, Java EE, etc.).

    Dans les détails, Red Hat explique encore que les modules automatiques de Jigsaw ne sont pas bien accueillis par la communauté ; un problème qu’Oracle veut résoudre avec une nouvelle proposition. Pour information, les modules automatiques sont considérés comme un mécanisme de compatibilité qui permet de « transformer » les JAR en modules dans un environnement modulaire. L'idée est qu'un module soit généré automatiquement à partir d'un JAR ; le nom du module serait alors un nom dérivé de celui du JAR, après diverses transformations pour le faire s'aligner sur la convention de nommage proposée pour les modules. Le problème est que de nombreux membres de la communauté estiment que les modules automatiques risquent d'apporter plus de mal que de bien, notamment à cause des risques de collision de noms.

    Ils ont donc suggéré à Mark Reinhold d'Oracle, Specification Lead du projet Jigsaw, de « réviser l'algorithme qui calcule les noms des modules automatiques pour inclure l'identifiant de groupe Maven, lorsqu'il est disponible dans le fichier 'pom.properties' d'un fichier JAR ». Cela devrait faire « en sorte que les noms des modules soient moins susceptibles d'entrer en collision. » Dans le cas contraire, Mark Reinhold devrait envisager de « supprimer entièrement la fonctionnalité des modules automatiques », étant donné qu’elle peut créer plus de problèmes qu’en résoudre.

    Mark Reinhold a donc fait des ajustements à son plan sur les modules Java, mais propose de ne pas supprimer la fonctionnalité de modules automatiques. D’après l’architecte en chef de la plateforme Java chez Oracle, la fonctionnalité de modules automatiques est « une partie critique de toute l’histoire de migration : elle permet aux développeurs d'applications de commencer à modulariser leur propre code sans avoir à attendre que toutes les bibliothèques et les frameworks qu'ils utilisent soient modularisés », dit-il. « Les bibliothèques et les frameworks populaires qui sont activement maintenus seront éventuellement modularisés assez rapidement, mais les projets moins actifs prendront plus de temps – peut-être des années ou même des décennies – et de nombreux projets inactifs ou abandonnés ne seront jamais modularisés. » C’est en cela que les modules automatiques sont importants dans le projet Jigsaw.

    Mark Reinhold ne compte toutefois pas non plus réviser l'algorithme qui calcule les noms des modules automatiques, comme cela lui a été suggéré. « La suggestion d'utiliser les coordonnées Maven lorsqu'elles sont disponibles aiderait moins de la moitié des projets les plus populaires en cours d'utilisation aujourd'hui, d'après trois enquêtes différentes », dit-il. Par contre, il propose de ramener l’attribut manifeste de fichier JAR, une option qui avait été suggérée précédemment, mais qu’il avait rejetée. « L'attribut manifeste 'Automatic-Module-Name' est, d'un point de vue technique, esthétiquement désagréable, car il définit une deuxième façon de nommer des modules. Pris seul, cependant, il permet une modularisation non coordonnée en utilisant des noms de modules stables avec peu d'effort, et donc il semble que ce soit la moins mauvaise option sur la table », a-t-il expliqué. Il recommande par ailleurs que tous les modules soient nommés selon la convention de nom de domaine Internet inversé.

    La nouvelle proposition de Mark Reinhold ne résout pas complètement le problème, mais semble déjà satisfaire un bon nombre de personnes, y compris les développeurs du projet Apache Maven. « Je pense que c'est un développement formidable qui permettra d’emprunter le chemin vers la modularisation et s’éloigner de la fragmentation potentielle de l'écosystème Java », a répondu Brian Fox, ancien président du projet Apache Maven.

    Il est important de noter que la proposition d'Oracle ne vient pas en réponse aux inquiétudes exprimées par Red Hat et IBM. Il s'agit en effet d'un problème sur lequel une discussion a été ouverte il y a des mois déjà.

    Sources : Proposition révisée de Mark Reinhold, Réponse de Brian Fox
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  7. #47
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 404
    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 404
    Points : 39 422
    Points
    39 422
    Billets dans le blog
    2

    Par défaut Modules Java : Mark Reinhold d’Oracle remet en cause la bonne foi de Red Hat et IBM

    Modules Java : Mark Reinhold d’Oracle remet en cause la bonne foi de Red Hat et IBM
    et invite le comité exécutif du JCP à soutenir le projet Jigsaw

    Red Hat et IBM ont récemment annoncé qu’ils n’apporteront pas leur soutien au système de modules implémenté dans Java 9, dans sa forme actuelle. Ils estiment que le JSR 376 (Java Platform Module System) n'est pas prêt en ce moment pour dépasser l'étape de la révision publique et qu’un délai supplémentaire vaut le coût pour résoudre les problèmes évoqués. En ce qui concerne ces problèmes, on peut les résumer comme suit : le système de modules introduits dans Java 9 apporte une solution qui ne couvre pas tous les cas d'utilisation, mais vient également avec des capacités d'interopérabilité insuffisantes et d'autres restrictions, qui pourraient créer une fragmentation de la communauté Java.

    Le problème est qu’il existe d’autres implémentations de modules dans Java, dont les principales sont les modules JBoss de Red Hat, et OSGi qui est pris en charge par un certain nombre de fournisseurs, y compris IBM. Ainsi, les objections de Red Hat et IBM sont-elles de bonne foi ou visent-elles simplement à défendre leurs intérêts personnels ? Pour Mark Reinhold d’Oracle, ces entreprises cherchent simplement à défendre leurs intérêts. L’architecte en chef du JDK chez Oracle a donc sévèrement critiqué les deux fournisseurs, dans une lettre ouverte publiée hier, avant d’inviter les membres du comité exécutif du Java Community Process (JCP) à soutenir le JSR 376.

    Mark Reinhold rappelle avant tout que l'objectif de ce JSR (soumis et approuvé par le comité exécutif en décembre 2014) est de concevoir un système de module accessible à tous les développeurs pour leur utilisation dans leur propre code, mais évolutif vers la modularisation de la plateforme Java SE elle-même. Et la spécification actuelle a atteint cet objectif.

    Mark Reinhold affirme que Red Hat « a d'abord accepté les objectifs et les exigences du JSR, mais a travaillé de façon constante à les saper. Ils ont tenté de transformer ce JSR en autre chose que ce qui était prévu. Plutôt que de concevoir un système de module à la fois accessible et évolutif, ils ont plutôt voulu concevoir un "méta" système de modules par lequel plusieurs systèmes de modules différents pourraient interagir profondément ». Et de déduire : « Je ne peux supposer qu'ils ont poursuivi cet objectif alternatif afin de préserver et de protéger leur système de modules non standardisé, qui est peu utilisé en dehors de l'écosystème JBoss/Wildfly », dit-il. « La conception d'un "méta" système de modules serait un projet intéressant », poursuit Mark Reinhold, « mais ce serait encore plus large et beaucoup plus difficile que ce JSR. En se concentrant sur un public d'experts de système de modules, cela entraînerait probablement une conception qui n'est pas accessible à tous les développeurs. C'est pourquoi j'ai souligné à maintes reprises à Red Hat Middleware que beaucoup des fonctionnalités qu'ils préconisaient étaient hors de portée, mais ils ont choisi de ne pas accepter ces décisions. »

    La décision de Red Hat de ne pas soutenir le système de modules introduit dans Java 9 n’est donc pas une surprise pour Mark Reinhold. Par contre, le « non » d’IBM était vraiment inattendu. « IBM a dit très peu de choses au cours de ce JSR. Après avoir annoncé qu'ils voteraient contre, ils ont ensuite envoyé une liste de problèmes spécifiques au groupe d’experts (EG), mais seulement en réponse à une demande d'un autre membre de l’EG. Aucun de ces problèmes n'est nouveau, beaucoup d'entre eux ont été discutés depuis longtemps, et IBM était silencieux pendant la plupart des discussions », affirme Mark Reinhold. « La position récente d'IBM semble être figée sur un désir vague d’un meilleur consensus parmi les membres de l’EG. Je préférerais davantage de consensus, mais ce n'est pas possible compte tenu de la position de Red Hat Middleware. Je ne peux donc conclure que IBM a décidé que ses intérêts sont mieux servis en retardant ce JSR et aussi le JSR 379 (Java SE 9), ce qui est regrettable ».

    Mark Reinhold reconnaît que la spécification actuelle de ce JSR n'est pas parfaite, mais reflète des années de développement, de test et d'amélioration avec des feedbacks actifs de nombreux développeurs. Il est d'accord avec le fait que la spécification pourrait être améliorée s'ils y passent plus de temps. Il estime également que « ce que nous avons maintenant ne résout pas tous les problèmes pratiques liés à la modularité auxquels sont confrontés les développeurs, mais ils répondent aux objectifs et aux exigences convenus et constituent une base solide pour les travaux futurs. Il est temps de livrer ce que nous avons, de voir ce que nous en tirons comme leçon et d'améliorer itérativement », dit-il, avant d’ajouter de ne pas laisser la recherche du parfait empêcher de livrer ce qui est déjà bien : « Ne laissez pas le parfait être l'ennemi du bon ».

    Pour conclure, Mark Reinhold réaffirme qu’on ne devrait pas retarder ce JSR (peut-être pendant des années) afin d'obtenir un meilleur consensus, sachant que certains poursuivent un objectif différent ; lequel objectif pourrait aboutir à une plateforme bloatware et complexe qu'aucun développeur n’utiliserait, ce qui n’est pas dans le meilleur intérêt de la communauté Java. Il rappelle également que le JCP « ne prévoit pas de consensus et pour une bonne raison. Il donne délibérément des pouvoirs de décision aux Specification Leads, précisément pour empêcher les membres de l'EG d'obstruer les progrès afin de défendre leurs propres intérêts. » Il appelle les membres du comité exécutif qui se demandent ce que sera leur vote, de juger la spécification sur le fond et non de voter contre le JSR en raison du manque de consensus dans l'EG. Un tel vote sera « un vote contre le JCP lui-même », dit-il, et condamne les futurs JSR « au consensus des "experts" qui se servent ».

    Source : Lettre ouverte de Mark Reinhold

    Et vous ?

    Que pensez-vous des déclarations de Mark Reinhold ?
    Red Hat et IBM essaieraient-ils de protéger leurs intérêts au détriment de celui de la communauté ?
    Faut-il livrer ce qu’on a déjà ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  8. #48
    Membre habitué Avatar de steel-finger
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2013
    Messages
    102
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

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

    Informations forums :
    Inscription : janvier 2013
    Messages : 102
    Points : 164
    Points
    164

    Par défaut

    Quelqu'un sais comment va fonctionné ce système de module ?

    Sinon ça ne m'étonne pas de RedHat & IBM, ils protègent leur intérêts et c'est normal n'importe quelle entreprise ferais de même

  9. #49
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 585
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 585
    Points : 8 462
    Points
    8 462
    Billets dans le blog
    3

    Par défaut

    C'est pour gérer / arbitrer ce genre de situation que les processus de standardisation existent.

    En C++, il y a en ce moment un peu le même souci : créer un système de modules avec la difficulté de gérer la transition / compatibilité avec l'existant. Microsoft et Google développent chacun leur vision et se sont un peu frittés sur le sujet. Mais le processus ISO protège mieux il me semble contre les intérêts propres à ces groupes car au final leur vote est noyé dans la masse.

    Quelqu'un sait comment ça se passe avec Java? Combien de personnes / acteurs ont le droit de voter?

  10. #50
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    981
    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 : 981
    Points : 2 042
    Points
    2 042

    Par défaut

    Citation Envoyé par steel-finger Voir le message
    Sinon ça ne m'étonne pas de RedHat & IBM, ils protègent leur intérêts et c'est normal n'importe quelle entreprise ferais de même
    Les inquietudes sont purement techniques et en rien politiques, et les problemes mentionnes sont valables pour tout l'ecosysteme Java. Il ne faut pas voir la critique d'une specification comme un moyen de ralentir le monde, disons qu'il faut plutot le voir comme un coup de frein pour etre sur de ne pas louper le virage...
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  11. #51
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    981
    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 : 981
    Points : 2 042
    Points
    2 042

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Quelqu'un sait comment ça se passe avec Java? Combien de personnes / acteurs ont le droit de voter?
    Les changement de specification de Java (nommes JSR) passent par un systeme de standardisation, avec revue, vote et compagnie - nomme JCP. Chaque spec definit des "expert groups" qui contribuent et ont le droit de vote. Pour JPMS, c'est https://www.jcp.org/en/jsr/detail?id=376 . Les specifications peuvent etre un peu "adoptees" avant la revue et compagnie, mais tant qu'il n'y a pas approbation de tous, ca reste externe a la spec Java; souvent le process se fait dans l'autre sens: ca part d'une solution existant (genre Spring) pour en extraire les parties interessantes a ajouter du contenu dans la spec Java/JavaEE et ca se passe bien. La on est sur un truc tres structurant et qui ne reprend pas specialement les solutions actuelles qui marchent, et qui semble avoir encore des defauts majeurs, c'est pour ca que ca coince un peu.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  12. #52
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 585
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 585
    Points : 8 462
    Points
    8 462
    Billets dans le blog
    3

    Par défaut

    Merci pour les précisions. C'est très similaire au fonctionnement du comité de normalisation pour C++.

  13. #53
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    octobre 2012
    Messages
    593
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : octobre 2012
    Messages : 593
    Points : 1 188
    Points
    1 188

    Par défaut

    Citation Envoyé par Mickael_Istria Voir le message
    La on est sur un truc tres structurant et qui ne reprend pas specialement les solutions actuelles qui marchent, et qui semble avoir encore des defauts majeurs, c'est pour ca que ca coince un peu.
    J'ai deux questions : d'abord, pourquoi ne pas être partie justement de "truc qui marche", genre maven ou osgi? Deuxièmement, tu peux expliciter les défauts majeurs, vu qu'à priori tu suis plutôt de près ? Il est dit plus haut que ca coince côté Maven notamment, mais à quel point?
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  14. #54
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    981
    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 : 981
    Points : 2 042
    Points
    2 042

    Par défaut

    Citation Envoyé par Cafeinoman Voir le message
    J'ai deux questions : d'abord, pourquoi ne pas être partie justement de "truc qui marche", genre maven ou osgi? Deuxièmement, tu peux expliciter les défauts majeurs, vu qu'à priori tu suis plutôt de près ? Il est dit plus haut que ca coince côté Maven notamment, mais à quel point?
    J'avoue que sur la premiere question, je ne connais pas la reponse.
    Pour Maven, je te suggere de lire la derniere proposition pour JPMS (qui est dans l'un des derniers liens postes), qui re-explique un peu le probleme et propose une solution satisfaisante mieux que je ne saurais le faire.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  15. #55
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 404
    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 404
    Points : 39 422
    Points
    39 422
    Billets dans le blog
    2

    Par défaut Java 9 : le comité exécutif du JCP rejette la spécification actuelle des modules Java (Jigsaw)

    Java 9 : le comité exécutif du JCP rejette la spécification actuelle des modules Java (Jigsaw)
    qui a voté « Non » et pourquoi ?

    Comme prévu, le 8 mai, les membres du comité exécutif du Java Community Process (JCP) ont voté sur le système de modules Java (Jigsaw). Bien avant le vote, IBM et Red Hat avaient exprimé des préoccupations au sujet du système de modules Java (Java Platform Module System, en abrégé JPMS), et annoncé qu’ils allaient voter « Non ». Ils n’étaient toutefois pas les seuls parmi les membres du comité exécutif du JCP à désapprouver le JSR 376 (Java Platform Module System) et le vote d’hier vient de le prouver. Le comité exécutif du JCP vient en effet de voter avec 13 « Non » contre 10 « Oui ». Qui a voté contre le JSR 376 et pour quelles raisons ?


    Avant d’aller plus loin, il est important de rappeler les conditions qu’il fallait remplir pour que le JSR soit approuvé. Le JSR est approuvé si (a) au moins une majorité des deux tiers des votes exprimés sont des votes « Oui », (b) un minimum de 5 votes « Oui » sont exprimés, et (c) Oracle vote également « Oui ». Autrement, il sera rejeté.

    Comme vous pouvez le voir, la première condition déjà n’a pas été remplie, étant donné que les « Non » enregistrent plus de la moitié des votes ; ce qui indique un clair rejet des modules Java (version Jigsaw). Des commentaires des différents votants, on retient deux raisons principales à cette objection : la nécessité d’un consensus entre les membres du groupe d’experts travaillant sur le système de modules, mais surtout l’interopérabilité ou la compatibilité avec des outils et systèmes populaires de l’écosystème Java.

    La nécessité d’un meilleur consensus entre les membres du groupe d’experts du JSR 376 est une raison évoquée par certains membres du comité exécutif ayant voté « Non ». D’après le fournisseur Hazelcast par exemple, « le manque de consensus au sein du groupe d'experts est un signe dangereux qui indique que tous les problèmes n'ont pas été clarifiés comme ils le devraient ou que certains problèmes ont été marqués résolus d'un seul point de vue. » Il est rejoint par Software AG qui lui aussi « s'inquiète de l'absence d'un consensus parmi les membres du groupe d'experts. » Bien que Software AG reconnaisse qu’un consensus parfait soit impossible, la société pense qu’un meilleur consensus reste quand même possible, et que cela « entraînerait un écosystème Java plus sain et une transition plus douce de l'industrie vers un monde Java modulaire. » Ils ne sont toutefois pas les seuls à demander un meilleur consensus. Tomitribe, Twitter, London Java Community et Crédit Suisse sont également de cet avis.

    Mais dans le fond, c’est l’interopérabilité et la compatibilité avec les outils et systèmes populaires de l’écosystème Java qui sont à l’origine du rejet de la spécification des modules Java dans sa forme actuelle. C’est ce que résume Werner Keil, architecte logiciel et membre du comité exécutif du JCP depuis 2008. « Je comprends les raisons d'IBM et d'autres pour leur vote "Non" et j'ai entendu de nombreuses préoccupations similaires, par exemple, de la communauté OSGi ou de contributeurs derrière les grands systèmes de build comme Maven, Gradle ou Ant. La plupart de leurs préoccupations ne sont pas encore résolues », dit-il. Software AG, pour sa part, réclame également « une attention particulière » sur la question de « la migration des logiciels existants vers le monde modulaire et à la coexistence de la spécification avec les pratiques Java et les systèmes de build existants. »

    Avec ce vote, le JCP accorde un délai de 30 jours au Specification Lead, Mark Reinhold d’Oracle, pour tenter de trouver un consensus au sein du groupe d’experts, donc probablement régler les problèmes évoqués et soumettre une nouvelle proposition. Il faut également préciser que certains membres qui ont voté « Non » disent être prêts à soutenir la spécification, si les membres du groupe d’experts trouvent un meilleur consensus. Mais vu les déclarations publiques de Red Hat et IBM, et celles d’Oracle, on peut se demander si ces 30 jours seront suffisants pour trouver un compromis. Cela dit, Java 9 sera-t-il encore repoussé ? Et combien de temps faudra-t-il encore attendre avant sa livraison ?

    Source : Vote du comité exécutif du JCP

    Et vous ?

    Que pensez-vous du vote ?

    Voir aussi :

    Java 9 : une nouvelle proposition d'Oracle pour résoudre l'un des problèmes évoqués par Red Hat sur le système de modules Java (Jigsaw)
    Modules Java : Mark Reinhold d'Oracle remet en cause la bonne foi de Red Hat et IBM et invite le comité exécutif du JCP à soutenir le projet Jigsaw
    Java 9 : IBM et Red Hat vont voter contre l'implémentation des modules Java via Jigsaw, une solution qui ne couvre pas tous les cas d'utilisation
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  16. #56
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    août 2005
    Messages
    5 641
    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 641
    Points : 20 193
    Points
    20 193
    Billets dans le blog
    30

    Par défaut

    Erf, a deux mois de la sortie planifiée et déjà repoussée de nombreuses fois, c'est limite ridicule...
    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

  17. #57
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 819
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 819
    Points : 5 747
    Points
    5 747
    Billets dans le blog
    2

    Par défaut

    La prédiction n'a jamais été une science exacte, d'une part, et d'autre part la manie d'établir des dates de rendu même quand on n'en sait fichtrement rien n'aide pas à ce qu'elles soient respectées. Dans ces conditions, on a beau faire ce qu'on peut, il ne faut pas s'étonner que ça arrive.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  18. #58
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 819
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 819
    Points : 5 747
    Points
    5 747
    Billets dans le blog
    2

    Par défaut

    Je viens d'ailleurs de terminer de lire un chapitre à ce sujet :
    Dunning, David. «*Prediction: The Inside View*». In Social psychology: handbook of basic principles, édité par Arie W. Kruglanski et E. Tory Higgins, 2nd ed., 69‑90. New York: Guilford Press, 2007.

    En résumé : l'homme est une machine à prédire de la merde, mais ça se soigne.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  19. #59
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 848
    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 848
    Points : 62 624
    Points
    62 624

    Par défaut JDK 9 : Mark Reinhold fait une proposition pour faciliter la migration vers la plateforme

    JDK 9 : Mark Reinhold fait une proposition pour faciliter la migration vers la plateforme,
    mais prévient qu'il s'agit d'une solution temporaire

    Pour répondre aux craintes des développeurs qui s’inquiètent du fait que le code qui fonctionne sur JDK 8 aujourd’hui puisse ne pas fonctionner sur JDK 9 notamment à cause de la forte encapsulation des API internes de JDK, Mark Reinhold, l’architecte en chef de Java d’Oracle, a fait une proposition qui pourrait « aider l'ensemble de l'écosystème à migrer vers la plateforme Java modulaire à un rythme plus décontracté » : autoriser par défaut la réflexion illegal-access.

    Pour rappel, la réflexion consiste à faire de l’introspection de classe, c’est-à-dire découvrir de façon dynamique des informations relatives à une classe ou à un objet en chargeant une classe, créant une instance et accédant aux membres statiques ou non sans connaître la classe par avance.

    Qu’est ce que cela signifie concrètement ?

    L’architecte en chef a expliqué que « big kill switch » existant de l’option permit-illegal-access va devenir le comportement par défaut du runtime JDK 9, mais sans autant d'avertissements.

    Il a également ajouté que le comportement actuel de JDK 9, où les opérations réflectives illegal-access depuis le code sur le chemin de classe n'est pas autorisé, deviendra la valeur par défaut dans une version future et rien ne changera au moment de la compilation.

    Reinhold a précisé qu’à terme, il est question de remplacer l’option --permit-illegal-access par une option plus généralisée ; le illegal-access. Ce dernier pourra prendre en paramètre un seul mot clé :

    --illegal-access=permit

    Ce sera le mode par défaut pour JDK 9. Il ouvre chaque paquet dans chaque module explicite à coder dans tous les modules non nommés, c'est-à-dire coder sur le chemin de la classe, tout comme l’autorise `--permit-illegal-access`. La première opération réflexive illegal-access provoque un avertissement, comme avec `--permit-illegal-access`, mais aucun avertissement ne sera émis après. Cet avertissement unique décrira comment activer d’autres avertissements.

    --illegal-access=warn

    Cela provoque un message d'avertissement pour chaque opération réflexive illegal-access. Cela équivaut à l'option actuelle `--permit-illegal-access`.

    --illegal-access=debug

    Cela provoque à la fois un message d'avertissement et une trace de pile pour chaque opération réflexive illegal-access. Cette option équivaut à combiner l'option `--permit-illegal-access` actuelle avec `-Dsun.reflect.debugModuleAccessChecks`.

    --illegal-access=deny

    Cela désactive toutes les opérations réflexives illegal-access, sauf pour celles qui sont activées par d'autres options de ligne de commande, telles que `--add-opens`. Cela deviendra le mode par défaut dans une version ultérieure.

    Qu’en est-il des implications ?

    Reinhold a prévenu que « le mode par défaut proposé permet au système d'exécution d'émettre un message d'avertissement, éventuellement longtemps après le démarrage, sans avoir été explicitement invité à le faire. Cela peut être une surprise dans les environnements de production, car il est extrêmement inhabituel pour le système d'exécution d'émettre des messages d'avertissement. Si le mode par défaut permet une réflexion illegal-access, il est donc essentiel de le faire savoir afin que les gens ne soient pas surpris lorsque cela ne sera plus le mode par défaut dans une version ultérieure ».

    Il a ajouté que les messages d'avertissement dans n'importe quel mode peuvent être évités, comme cela était déjà le cas, par l'utilisation judicieuse des options `-add-exports` et` -add-opens`.

    Si elle est adoptée, la proposition nécessitera des modifications au JEP 260 qui « Encapsule la plupart des API internes ». Bien que les API internes au JDK soient encore fortement encapsulées du point de vue du code dans les modules, que ces modules soient automatiques ou explicites, ils ne semblent pas être encapsulés au moment de l'exécution du point de vue du code sur le chemin de la classe.

    En outre, lorsque "deny" va devenir le mode par défaut, Reinhold s'attend à ce que `permit` reste supporté pour au moins une version, afin que les développeurs puissent continuer à migrer leur code. Il convient de mentionner que les modes `allow`,` warn` et `debug` seront, au fil du temps, supprimés, et la même chose arrivera à l'option` -galgal-access`.

    Probablement, la chose la plus importante à saisir est que, même si la proposition est adoptée et que la modification prend effet, elle ne « résoudra pas magiquement tous les problèmes d'adoption JDK 9. Les types concrets des chargeurs de classes intégrés sont encore différents,` rt .jar` est toujours parti, la mise en page d'une image système n'est toujours pas la même et la chaîne de la version possède encore un nouveau format ».

    Source : Proposition Mark Reinhold
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  20. #60
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 132
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 132
    Points : 2 654
    Points
    2 654
    Billets dans le blog
    12

    Par défaut

    Salut,

    Je fais parti de ceux qui sont impacté par cette migration car j'utilise la méthode setAccessible() dans mes API pour accéder aux champs qui ne sont pas public

    A+
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

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, 18h26
  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, 11h03
  3. Optimisation MySQL : suis-je sur la bonne voie ?
    Par dedis dans le forum Requêtes
    Réponses: 1
    Dernier message: 01/09/2010, 15h07
  4. suis-je sur la bonne voie ?
    Par am@123 dans le forum Débuter
    Réponses: 6
    Dernier message: 11/07/2008, 22h52
  5. être ou ne pas être sur un objet
    Par Speed41 dans le forum Delphi
    Réponses: 3
    Dernier message: 24/09/2006, 13h36

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