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 :

Oracle annonce la sortie officielle de Java 11


Sujet :

Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2013
    Messages
    320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

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

    Informations forums :
    Inscription : Janvier 2013
    Messages : 320
    Billets dans le blog
    1
    Par défaut Oracle annonce la sortie officielle de Java 11
    JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA,
    dans le cadre des mises à jour semestrielles

    Dans le cadre de la nouvelle cadence de lancement de chaque six mois, adoptée pour l’édition standard de Java, Oracle est en train de peaufiner les dernières fonctionnalités de prochaine la version du JDK, la version 11, dont la sortie est prévue en septembre 2018. Cette version contrairement à JDK 10, est une version LTS pour « Long Term Support » ou version avec un support à long terme. Elle devrait avoir un support Oracle de premier niveau jusqu’en septembre 2023 et un support étendu incluant des correctifs et des alertes de sécurité jusqu’en 2026.

    Succédant au JDK 10 lancé le 20 mars, seules trois nouvelles fonctionnalités sont annoncées à ce jour bien que d’autres puissent s’y greffer avant la date de sortie prévue.

    • Le format de fichier de classe Java qui sera étendu pour prendre en charge une nouvelle forme de pool de constante, CONSTANT_Dynamic.
    • Le mot clé « var » sera désormais utilisable lors de la déclaration des paramètres formels d'une expression lambda typée implicitement. En d’autres termes, une syntaxe à variable locale pour les paramètres lambda doit suivre la syntaxe d'une déclaration de paramètre formelle dans une expression implicitement typée avec la syntaxe d'une déclaration de variable locale.
    • Le « garbage collector » ou ramasse-miette Epsilon, annoncé en tant que collecteur "no-op", gérera l'allocation de mémoire sans implémenter de mécanismes de récupération de mémoire. Les cas d'utilisation d'Epsilon comprennent les tests de performance, la pression de la mémoire et l'interface de la machine virtuelle. Il pourrait également être utilisé pour des utilisations de courtes durées.


    Nom : Screen Shot 2018-03-28 at 08.13.17.png
Affichages : 33215
Taille : 123,8 Ko

    Parallèlement à ces ajouts, certaines fonctionnalités ne seront plus présentes. En effet dans la version Java 11, Java FX ainsi que les modules CORBA et Java JEE seront supprimés. La suppression de JavaFX étant en cours se prolongera dans cette version puisque n’étant pas liée au programme de mise à jour semestrielle de Java JDK. Déprécié depuis Java SE9, le retrait des modules Java EE et CORBA était une mesure prévue et sera effectif avec JDK11.
    La suppression de CORBA peut être justifiée par deux facteurs. Premièrement, elle date des années 1990 et ne recèle plus aucun intérêt pour le développement d’applications Java modernes d’après Oracle. Enfin, les coûts de maintenance sont élevés comparés aux bénéfices rapportés. Cependant, cette suppression risque d’entrainer des dysfonctionnements sur des implémentations existantes. En effet, ces dernières risquent de ne pas fonctionner si elles n’incluent qu’une partie de l’API CORBA. Elles s’attendront à ce que le JDK leur fournisse le reste. De plus, il n’existe pas de versions tierces pour CORBA et il est peu probable qu’un tiers se décide à en prendre la charge.

    Pour ce qui est de la plateforme JAVA EE, la suppression est due à des difficultés de maintenance qu’elle a entrainées dans JAVA SE au fil de ses évolutions. Sortie en décembre 2011, JAVA SE 6 était accompagnée d’une large panoplie des services web utiles au développeur. Parmi ceux-ci, on peut en citer quatre qui étaient dédiés à JAVA JEE : JAX-WS (Java API for XML-based Web Services,**JAXB (Java Architecture for XML Binding), JAF (JavaBeans Activation Framework) et Common Annotations for Java. Ces ajouts de fonctionnalités pour JAVA EE ont entrainé des complications pour JAVA SE notamment parce qu’ils incluaient des fonctionnalités sans rapport avec cette dernière. Ainsi Oracle affirme qu’avec des versions « standalone » disponibles sur des sites tiers, il n’est plus nécessaire de l’inclure dans JAVA SE ou dans le JDK. Cependant, certaines applications pourraient ne pas compiler si elles s’appuient sur un support prêt à l’emploi du JDK pour les API et outils Java EE. Des incompatibilités binaires et de source se produiraient lors de la migration de JDK 6,7 et 8 vers une version ultérieure. Oracle recommande aux développeurs concernés par ces risques de déployer sur des versions alternatives des technologies Java EE à la place.

    Source : Mail List Open JDK, Open JDK

    Et vous ?

    Que pensez-vous de la suppression annoncée des trois modules cités plus haut de JDK 11 ?

    Voir aussi

    JDK 10 : les fonctionnalités de la prochaine version de Java sont désormais gelées, la sortie est attendue pour le 20 mars 2018

    Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial

  2. #2
    Membre Expert

    Homme Profil pro
    Consultant informatique
    Inscrit en
    Janvier 2004
    Messages
    2 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Janvier 2004
    Messages : 2 301
    Par défaut
    Suppression de... JavaFX? J'ai bien lu? C'est une blague??!

    N'ayant jamais vraiment utilisé, je ne vais pas trop m'en plaindre, mais par contre ça me semblait un framework moderne pour développer du standalone... le successeur de swing... mis en avant par Oracle (au moins durant un temps...) comme LA solution à tous nos problèmes

    ça devient un package séparé? ou c'est vraiment end of life?

  3. #3
    Membre très actif
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    97
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 97
    Par défaut
    Citation Envoyé par Pill_S Voir le message
    Suppression de... JavaFX? J'ai bien lu? C'est une blague??!

    N'ayant jamais vraiment utilisé, je ne vais pas trop m'en plaindre, mais par contre ça me semblait un framework moderne pour développer du standalone... le successeur de swing... mis en avant par Oracle (au moins durant un temps...) comme LA solution à tous nos problèmes

    ça devient un package séparé? ou c'est vraiment end of life?
    J'avoue ne pas comprendre, JavaFX permet la création d'application d'une manière super simple et de séparer la vue du reste, c'est le top. J'espère que c'est juste séparer JavaFX (et pk pas le laisser à la communauté); car bon, SWING et consorts, c'est quand même le meilleur moyen d'avoir des interfaces dégueulasses d'un autre age; en claire c'est la mort de Java pour les apps desktop.

  4. #4
    Membre chevronné
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 947
    Par défaut
    Citation Envoyé par robertledoux Voir le message
    J'avoue ne pas comprendre, JavaFX permet la création d'application d'une manière super simple et de séparer la vue du reste, c'est le top. J'espère que c'est juste séparer JavaFX (et pk pas le laisser à la communauté); car bon, SWING et consorts, c'est quand même le meilleur moyen d'avoir des interfaces dégueulasses d'un autre age; en claire c'est la mort de Java pour les apps desktop.
    le développement de nouvelle app desktop se fait quand même rare
    je vois presque peu d'offre d'emploi

  5. #5
    Rédacteur/Modérateur

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

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

    Informations forums :
    Inscription : Août 2005
    Messages : 6 900
    Billets dans le blog
    54
    Par défaut
    Ahah des mots chocs pour un effet choc .

    Le principe est le même que pour Java EE (ou plutôt je devrais dire désormais Jakarta EE) : Oracle s'en désolidarise et le renvoie a son niveau de module séparé du JDK tel que c’était le cas lors de JavaFX 1.x, 2.0 et 2.1 (JavaFX a fait uniquement parti du JDK dans ses version 2.2, 8, 9 et 10). Comme le projet est OpenSource, il sera géré par l'OpenJFX qui est en train de s'organiser autour de Johan Vos et de Gluon pour manager la chose. Pour le moment il sont en train de simplifier la maniere de contribuer (mise en place d'un GitHub forkable) et de build, ensuite le plan c'est de fournir des binaires precompiles sous Maven et une distro ZIP.

    EDIT - et même si l'info est déjà passée dans une autre news, coté client les vraies suppressions dans le JDK 11 sont celles des Applets et de Java Web Start qui vont eux tomber aux oubliettes (pas de passage en OpenSource pour JWS). La roadmap indique que Oracle cherche même un repreneur pour Swing sur le long terme, c'est dire a quel point le desktop ne les intéresser plus (ça se voyait quand même depuis 2013), sans doute faute de reel plan ou de rentrées financières suffisantes. Le fait de larguer JEE me fait juste dire que Java ne rapporte sans doute pas assez d'argent pour Oracle, ce qui rejoint les rumeurs qu'on avait eut il y a 2 ans.
    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 éprouvé
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    961
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 961
    Par défaut
    D'après
    https://blogs.oracle.com/java-platfo...oadmap-updates
    JavaFx sera disponible comme module séparé.

    J'ai un projet JavaFx en production et ça ne me plait pas. JavaFx a besoin de davantage d'engagement de la part d'Oracle, pas moins.

  7. #7
    Membre à l'essai
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Décembre 2014
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Décembre 2014
    Messages : 6
    Par défaut ce que Jasper Potts en pense
    Jasper Potts, un des lead dev de JavaFX a retweeté 2 tweets:
    un tweet pessimiste : https://twitter.com/skovatch/status/971495384206880768
    un tweet de consolation : https://twitter.com/johanvos/status/971447653144899586

    Ca sent pas bon de toute manière

  8. #8
    Membre très actif
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

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

    Informations forums :
    Inscription : Décembre 2010
    Messages : 548
    Par défaut
    Pour JavaFX, c'est juste une question de suivi des mises à jours du JDK, que JavaFX ne pourra suivre le cycle de 6 mois, pas mais la plate-forme JavaFX restera encore là a évoluer et être utilisé. Et avec la modularité introduite dans JDK9, JavaFX est un module à part entière mais cela ne veut pas dire qu'il sera supprimé de la plate-forme Java, non mais il sera distribué séparément. Celui qui veut faire le JavaFX va télécharger le module JavaFX pour l'intégrer au projet.

    Mais ces informations sont déjà publiées ici par des gens qui connaissent les choses mais celui qui a publié cette actualité, on voit qu'il ne maîtrise pas bien ce qu'il dit, ce qui fait de la polémique.

  9. #9
    Membre Expert
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 76
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Par défaut
    Ce qui me semble beaucoup plus inquiétant c'est que ça boite au niveau des techniques de déploiement (ça grince sur jigsaw-dev à ce sujet).

    - Java Web start est sur siège éjectable (mais pas encore éjecté) ... probablement au vu des problèmes des jars "exécutables"
    - justement les jars "exécutables" (on clique dessus) ne sont plus là avec les jars modulaires ... et donc par quoi les remplacer? pour l'instant par des scripts !
    - Les images jlink c'est chou ... mais c'est 1) spécifique à une plate-forme 2) délicat à mettre à jour dès qu'une nouvelle version de java apparait 3) troublant (doux euphémisme ) lorsqu'on veut mettre en place des plug-ins ou des données de configuration in situ

    Les migrations des bibliothèques et des apps. vers Java modulaire génèrent certes quelques souffrances mais il faudra aussi hurler bien fort pour que les techniques de déploiement soient remises à jour.

  10. #10
    Expert éminent
    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
    Billets dans le blog
    1
    Par défaut
    Personnellement je vois plutôt d'un très bon œil le fait que certains modules puissent être détaché du JRE.
    Le JRE devrait vraiment se concentrer sur l'essentiel.

    Et ce n'est pas forcément une mise à mort.
    Au contraire le fait de séparer ces modules apporte même des avantages :
    • Ils pourront évoluer indépendamment de Java et avoir des cycles de release différent sans avoir à attendre la prochaine version de Java.
      Et ce même si avec le passage aux releases tous les 6 mois le problème est moins flagrant qu'avant...
    • Ils auront la possibilité de proposer des évolutions "incompatibles", ce qui est quasi-impossible dans le standard sans tout casser.
      Avec des modules distincts on peut tout à fait envisager cela sans trop de problème.




    Reste juste les problèmes de déploiements soulevé par professeur shadoko... mais je ne saurais en dire plus vu que je n'ai pas encore touché à Java 9 !

  11. #11
    Membre Expert

    Homme Profil pro
    Consultant informatique
    Inscrit en
    Janvier 2004
    Messages
    2 301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Janvier 2004
    Messages : 2 301
    Par défaut
    Tout dépend toujours du point de vue sous lequel on observe un événement...

    Personnellement, je vois ça plutôt comme quelque chose de mauvais, quand tu dis:

    Ils pourront évoluer indépendamment de Java et avoir des cycles de release différent sans avoir à attendre la prochaine version de Java.
    ... moi je retiens plutôt:
    Et ce même si avec le passage aux releases tous les 6 mois le problème est moins flagrant qu'avant...
    donc avantage limité, mais surtout:
    Ils auront la possibilité de proposer des évolutions "incompatibles"
    ... et ça ça peut être plutôt méchant. Bien que n'ayant pas trop codé en C/C++, j'ai entendu tellement de fois les légendaires citations du genre "ouaaaaais quand tu prends la version 1.2 du compilateur avec la version 3.4 de telle librairie, ça fait que la version 5.6 de la dépendance truc a un bug alors faut upgrader machintruc en version 7.8 mais si tu fais ça tu pourras plus utiliser la syntaxe bidule-machin"...

    On était plutôt épargné avec Java, étant donné que tout beaucoup était géré par Sun/Oracle, on utilisait un runtime cohérent. J'ai peur que cela soit en train de disparaitre et que tout devienne très bordelique avec un JRE explosé en de multiples dépendences, plus vraiment sous contrôle...

    PS: souvenez-vous de Flex. ça lui a pas trop réussi d'être désolidarisé d'Adobe...

  12. #12
    Expert éminent
    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
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Pill_S Voir le message
    donc avantage limité
    Ça peut rester malgré tout plus "long" puisqu'il faut se caler sur le planning du JRE... Et si c'est pas prêt ou validé ça reporte de 6 mois...

    Citation Envoyé par Pill_S Voir le message
    On était plutôt épargné avec Java, étant donné que tout beaucoup était géré par Sun/Oracle, on utilisait un runtime cohérent. J'ai peur que cela soit en train de disparaitre et que tout devienne très bordelique avec un JRE explosé en de multiples dépendences, plus vraiment sous contrôle...
    Pourtant beaucoup de librairie se sont développées en dehors de Java SE/EE, parfois avant d'être intégrées plus tard.

    Le fait de pouvoir proposer des versions incompatibles permet aussi de passer outre les erreurs du passé...

    IMHO c'est très important pour la couche UI afin de pouvoir évoluer avec son époque...

  13. #13
    Membre très actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

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

    Informations forums :
    Inscription : Janvier 2007
    Messages : 187
    Par défaut
    C'est une bonne chose que l'on extirpe ces libs du framework Java, bien sûr cela restera des libs indépendantes disponibles dans le repository Maven.

    > Java Web start est sur siège éjectable (mais pas encore éjecté) ... probablement au vu des problèmes des jars "exécutables"

    Il serait effectivement aussi temps de virer la pire invention du monde Java, je connais des clients qui l'utilisent encore à fond cela et cela ne va pas les arranger mais dans le même temps ils sont à des années lumières d'arriver à Java 11 ...

  14. #14
    Rédacteur/Modérateur

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

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

    Informations forums :
    Inscription : Août 2005
    Messages : 6 900
    Billets dans le blog
    54
    Par défaut
    Je sais que JWS fonctionne pour beaucoup de gens mais je sais aussi qu'il ne fonctionne pas pour beaucoup d'autres. Lors de la session de la JavaOne tournant autour en 2011 ou 12 (je sais pu ça date déjà) on était quand même 4 personnes dans la salle en train de se plaindre de manière assez virulente que ça ne fonctionnait pas du tout du tout, super pénible a mettre en place, impossible a diagnostiquer... M'enfin il me fallait passer par un outil externe (JaNeLa) pour valider les JNLP et corriger ceux pas vraiment optimises que me pondaient NetBeans ou ceux non-fonctionnels que je pouvais écrire a mano en suivant les références du format et autres didacticiels officiels
    De plus les commentaires laisses sur Twitter laissent a penser que le fait que ce n'est pas open source pour des raisons de copyright dans doute (la techno etait licenciée a un tiers ou repompée d'ailleurs ?) ou encore que le code est de trop mauvaise qualité pour être publié.
    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

  15. #15
    Nouveau membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Septembre 2015
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Septembre 2015
    Messages : 5
    Par défaut Migration Applet / JNLP sous Java 11
    Bonjour ,
    J'ai une application qui tourne en Applet et qui s'exescute avec un JNLP sur le navigateur , comme vous le savez les applets et le jnlp vont être supprimer à partir de la version 11 ( janvier 2019 )
    J'envisage de faire une migration en Java 11 , et je me pose la question : est ce que je dois garder mon ancien code ( qui tourne depuis des années ) ou passer sur une nouvelles technologies basé sur java jee ou java fx
    D'après vous c'est quoi qui est mieux et moins violent pour cette migration : garder le code et maigrir vers les Swing ( ou FX ) ou bien changer la stratégie est passer au java fmk( spring boot / jsf ... )
    Merci d'avance pour vos conseils
    Cordialement .

  16. #16
    Membre très actif

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    608
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 608
    Par défaut
    Sincèrement, je n'en peux plus.

    J'ai passé un week-end à essayer de migrer une application Java 8 en Java 10 et à la mettre en modules.
    Arrivé à un sous-projet utilisant Apache Spark, j'avais du mal : un module spark.core_2.11 m'était proposé, mais le placer dans module-info.java le faisait râler : il n'aime pas les chiffres ; j'étais étonné qu'un module puisse avoir ce nom-là, s'il ne convenait pas.
    J'ai cherché trop longtemps : il ne fallait pas. Spark 2.3.1, la dernière version, ne soutient pas Java 10. Pas la 9 non plus. Seulement la 8. J'étais grognon.

    C'en est ainsi de quasiment tout.
    Java 9+ ça peut être le 10 ou le 11, ça reste un fiasco. Un an après la sortie de Java 9, je n'ai pas vu d'entreprises et je ne aucun projet autour de moi qui ait migré dessus.
    Et surtout : aucune qui en ait l'intention. Et elles ont raison : il faudrait déjà que les projets open source, qui sont partie de nos logiciels, fonctionnent eux-mêmes avec du Java 9+ : c'est loin d'être le cas.

    En Janvier prochain, nous serons tous sur une version obsolète : Java 8. On aura jamais vu ça. Personne n'est capable de migrer.
    Qu'Oracle continue donc avec du Java 11, 12, 13 ! Ça ne sert à rien. Il fait du forcing à coup d'injonctions, mais nous sommes tous bloqués, tous coincés derrière.

    Comme il dit mon maître à penser : "J'voudrais trouver les mots, mais y a pas de mots."

  17. #17
    Expert éminent
    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
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par grunt2000 Voir le message
    Personne n'est capable de migrer.
    Il y a pourtant une solution simple : ne pas utiliser le système de module !

    Tant que les modules ne seront pas largement adoptés par les librairies tierces, ce sera inutilisable (ou difficilement).

    C'est pas vraiment anormal, on avait eu un peu les mêmes problèmes avec les Generics...

  18. #18
    Rédacteur

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    Juillet 2005
    Messages
    14 974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : Juillet 2005
    Messages : 14 974
    Par défaut
    Je suis du même avis que AdiGuba, pour l'instant les modules je n'en occupe pas. Il y a des warnings quand certaines API souhaitent accéder à des éléments natifs du JDK, je ferme les yeux ;-)

    Mickael
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de Developpez.com : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : mickael-baron.fr
    LinkedIn : www.linkedin.com/in/mickaelbaron
    DBLP : dblp.uni-trier.de/pers/hd/b/Baron:Micka=euml=l

  19. #19
    Membre très actif

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    608
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 608
    Par défaut
    Je reviens sur le problème des modules.
    Citation Envoyé par adiGuba Voir le message
    Il y a pourtant une solution simple : ne pas utiliser le système de module !
    Je suis passé sur le JDK 10 il y a quelques mois. Et je lance Geoserver sur mon poste.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    SEVEN@SEVEN-PC MINGW64 /c/Outils/Programmation/geoserver-2.13.2/bin
    $ sh startup.sh
    GEOSERVER DATA DIR is F:\data\dev-compte-france\geoserver_data_dir
    [...]
    29 sept. 06:05:48 ERROR [context.ContextLoader] - Context initialization failed
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'KMLEncoder': Failed to introspect bean class [org.geoserver.kml.KMLEncoder] for lookup method metadata: could not find class that it depends on; nested exception is java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
    D'après les solutions que l'on trouve sur Internet sur ce sujet, il faut rajouter à la ligne de commande la directive :
    --add-modules java.xml.bind

    Alors, je force le trait exprès pour exagérer mais j'ai fait l'essai et bien sûr ceci ne fonctionne pas :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    sh startup.sh --add-modules java.xml.bind
    sh startup.sh -D--add-modules java.xml.bind

    Il faut lire le contenu du script startup.sh livré par Geotools :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    #!/bin/sh
    # -----------------------------------------------------------------------------
    # Start Script for GEOSERVER
    #
    # $Id$
    # -----------------------------------------------------------------------------
     
    # Guard against misconfigured JAVA_HOME
    if [ ! -z "$JAVA_HOME" -a ! -x "$JAVA_HOME"/bin/java ]; then
      echo "The JAVA_HOME environment variable is set but JAVA_HOME/bin/java"
      echo "is missing or not executable:"
      echo "    JAVA_HOME=$JAVA_HOME"
      echo "Please either set JAVA_HOME so that the Java runtime is JAVA_HOME/bin/java"
      echo "or unset JAVA_HOME to use the Java runtime on the PATH."
      exit 1
    fi
     
    # Find java from JAVA_HOME or PATH
    if [ ! -z "$JAVA_HOME" ]; then
      _RUNJAVA="$JAVA_HOME"/bin/java
    elif [ ! -z "$(which java)" ]; then
      _RUNJAVA=java
    else
      echo "A Java runtime (java) was not found in JAVA_HOME/bin or on the PATH."
      echo "Please either set the JAVA_HOME environment variable so that the Java runtime"
      echo "is JAVA_HOME/bin/java or add the Java runtime to the PATH."
      exit 1
    fi
     
    if [ -z $GEOSERVER_HOME ]; then
      #If GEOSERVER_HOME not set then guess a few locations before giving
      # up and demanding user set it.
      if [ -r start.jar ]; then
         echo "GEOSERVER_HOME environment variable not found, using current "
         echo "directory.  If not set then running this script from other "
         echo "directories will not work in the future."
         export GEOSERVER_HOME=`pwd`
      else 
        if [ -r ../start.jar ]; then
          echo "GEOSERVER_HOME environment variable not found, using current "
          echo "location.  If not set then running this script from other "
          echo "directories will not work in the future."
          export GEOSERVER_HOME=`pwd`/..
        fi
      fi 
     
      if [ -z "$GEOSERVER_HOME" ]; then
        echo "The GEOSERVER_HOME environment variable is not defined"
        echo "This environment variable is needed to run this program"
        echo "Please set it to the directory where geoserver was installed"
        exit 1
      fi
     
    fi
     
    if [ ! -r "$GEOSERVER_HOME"/bin/startup.sh ]; then
      echo "The GEOSERVER_HOME environment variable is not defined correctly"
      echo "This environment variable is needed to run this program"
      exit 1
    fi
     
    #Find the configuration directory: GEOSERVER_DATA_DIR
    if [ -z $GEOSERVER_DATA_DIR ]; then
        if [ -r "$GEOSERVER_HOME"/data_dir ]; then
            export GEOSERVER_DATA_DIR="$GEOSERVER_HOME"/data_dir
        else
            echo "No GEOSERVER_DATA_DIR found, using application defaults"
    	      GEOSERVER_DATA_DIR=""
        fi
    fi
     
    cd "$GEOSERVER_HOME"
     
    if [ -z $MARLIN_JAR]; then
        export MARLIN_JAR=`find \`pwd\`/webapps -name "marlin*.jar" | head -1`
    fi
    export MARLIN_ENABLER="-Xbootclasspath/a:$MARLIN_JAR -Dsun.java2d.renderer=org.marlin.pisces.MarlinRenderingEngine"
     
    echo "GEOSERVER DATA DIR is $GEOSERVER_DATA_DIR"
    #added headless to true by default, if this messes anyone up let the list
    #know and we can change it back, but it seems like it won't hurt -ch
    exec "$_RUNJAVA" $JAVA_OPTS $MARLIN_ENABLER -DGEOSERVER_DATA_DIR="$GEOSERVER_DATA_DIR" -Djava.awt.headless=true -DSTOP.PORT=8079 -DSTOP.KEY=geoserver -jar start.jar
    Là, on peut observer qu'en définissant à l'extérieur la variable d'environnement :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    export JAVA_OPTS='--add-modules java.xml.bind'
    Il démarre correctement.

    Donc, c'est résolu pour lui. Mais tous les autres programmes Java démarrant par des scripts se pose le même problème, s'ils ne démarrent pas directement avec un JDK 9+.
    Le .sh, ici, il est bien fait. Mais pour les autres que je rencontrerai, s'ils n'ont pas un JAVA_OPTS aussi bien placé : il faudra faire un cycle de lancement et examen des classes manquantes, édition à la main du sh pour rajouter un module, jusqu'à ce que ça marche.

    C'est pas si instantané que ça.

  20. #20
    Expert éminent
    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
    Billets dans le blog
    1
    Par défaut
    C'est toutefois un cas un peu particulier, car il utilise une librairie de Java EE, et donc qui ne fait pas partie de l'API standard de Java SE...

    La vrai solution serait de fournir une implémentation avec le programme.

    Pour la grande majorité des programmes le fonctionnement reste identique qu'en Java 8 ou inférieur tant qu'on n'utilise pas les modules.

Discussions similaires

  1. Réponses: 2
    Dernier message: 11/08/2006, 15h45
  2. Réponses: 2
    Dernier message: 30/06/2006, 15h12
  3. Réponses: 4
    Dernier message: 23/04/2006, 10h36
  4. Réponses: 7
    Dernier message: 16/12/2005, 14h59
  5. Rafraichissement de la fiche ainsi que de tous les objets
    Par portu dans le forum Composants VCL
    Réponses: 7
    Dernier message: 06/01/2004, 00h25

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