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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2016
    Messages
    1 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 1 793
    Points : 40 465
    Points
    40 465
    Par défaut Oracle annonce la disponibilité de Java 16
    Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent,
    et devrait arriver avec la prise en charge des fonctionnalités du C++ 14

    Bien que les travaux sur le JDK 15 continuent, avec une disponibilité générale prévue pour le 15 septembre, le JDK 16, son successeur, est déjà en cours de développement. Le site Web de l’OpenJDK dédié à cet exercice recense désormais 3 JEP (JDK Enhancement Proposals). Prévu pour mars 2021, le JDK 16 devrait arriver avec la prise en charge des fonctionnalités du C++ 14 dans le code source C++ du JDK. La communauté de l’OpenJDK prévoit également de migrer les référentiels de code source OpenJDK de Mercurial vers Git (GitHub) pour diverses raisons.

    Activation des fonctionnalités du langage C++ 14

    Selon la description donnée par le JEP 347, ce changement vise l'utilisation des fonctionnalités du C++ 14 dans le code source C++ du JDK et à donner des indications spécifiques sur les fonctionnalités qui peuvent être utilisées dans le code de la VM HotSpot. Par le biais du JDK 15, les caractéristiques du langage utilisées par le code C++ dans le JDK ont été limitées aux normes du langage C++ 98/03. Avec le JDK 11, le code source a été mis à jour pour permettre la construction avec des versions plus récentes du standard C++.

    Nom : z2.png
Affichages : 49653
Taille : 88,0 Ko

    Cela inclut la possibilité de construire avec des versions récentes de compilateurs qui prennent en charge les caractéristiques du langage C++ 11/14. La présente proposition ne propose aucun changement de style ou d'usage pour le code C++ utilisé en dehors du HotSpot. Les règles sont déjà différentes pour le code du HotSpot et pour le code non HotSpot. À titre d’exemple, les exceptions C++ sont utilisées dans certains codes non HotSpot. Par contre, elles sont interdites dans HotSpot par les options de compilation.

    Cependant, les exigences de cohérence de la construction rendront les nouvelles fonctionnalités du langage disponibles pour une utilisation dans tout le code C++ du JDK. Ensuite, pour tirer profit des fonctionnalités du langage C++, certaines modifications doivent être apportées au fil du temps, les détails dépendant du compilateur de la plateforme. Les versions minimales acceptables des différents compilateurs de plateforme doivent également être spécifiées. Le standard de langage souhaité doit être spécifié explicitement.

    Migration des dépôts de code source OpenJDK de Mercurial vers Git

    Le développement du JDK 16 se fera en même temps que la migration des référentiels de code source de la communauté OpenJDK de Mercurial (hg) vers Git. Le JEP 357 donne plusieurs raisons à cela. L’une d’entre elles est que les premiers prototypes de dépôts convertis montrent une réduction significative de la taille des métadonnées de contrôle de version. Par exemple, le répertoire .git du dépôt jdk/jdk est d'environ 300 Mo avec Git et le répertoire .hg est d'environ 1,2 Go avec Mercurial, selon la version de Mercurial utilisée, ce qui présente plusieurs avantages.

    Le JEP 357 indique que cette réduction des métadonnées préserve l'espace disque local et réduit les temps de clonage, car moins de bits doivent passer par le fil. Git comporte également des clones peu profonds qui ne clonent que des parties de l'historique, ce qui permet de réduire encore les métadonnées pour les utilisateurs qui n'ont pas besoin de l'historique complet. Ainsi, l’objectif de cette action est de migrer tous les projets OpenJDK à dépôt unique de Mercurial vers Git, conserver l'historique du contrôle des versions, y compris les balises, reformater les messages d'engagement selon les meilleures pratiques de Git, porter les outils jcheck, webrev et defpath vers Git et créer un outil de traduction entre les hachages Mercurial et Git.

    La migration vers GitHub

    La migration vers GitHub est liée à la migration de Mercurial vers Git, avec des dépôts de code source JDK 16 qui seront sur le populaire site de partage de code. Mais pourquoi GitHub ? Le JEP 369 indique que la motivation pour choisir GitHub est qu'il excelle dans les trois principales raisons de choisir un fournisseur externe. Les performances de GitHub sont aussi bonnes, voire supérieures à celles des autres fournisseurs, c'est le plus grand service d'hébergement de code source au monde (50 millions d'utilisateurs en mai 2020), et il possède l'une des API les plus complètes.

    Ce choix est aussi motivé par l'API étendue de GitHub qui permet la prise en charge de nombreux outils, notamment des éditeurs de texte, des EDI, des outils de ligne de commande et des clients de bureau graphique. Les versions préliminaires du JDK 16 pour Linux, Windows et macOS sont disponibles à l'adresse jdk.java.net. Comme le JDK 15, le JDK 16 sera une version à court terme, supportée pendant six mois. Le JDK 17, prévu pour septembre 2021, sera une version de support à long terme (LTS) qui bénéficiera d'un support pendant plusieurs années. La version actuelle du LTS, le JDK 11, est sortie en septembre 2018.

    Source : Site de l’OpenJDK

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi

    Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors et supprimera le moteur JavaScript Nashorn

    Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres

    JDK 14 va apporter plus de fonctionnalités que les deux versions précédentes combinées. Petit tour d'horizon sur celles qui sont susceptibles d'intéresser le plus les développeurs

    Le JDK 9 va supporter la compilation anticipée (AOT) en commençant par les systèmes Linux 64-bit exécutant Java 64-bit
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Analyste
    Inscrit en
    juillet 2013
    Messages
    2 415
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 415
    Points : 76 682
    Points
    76 682
    Billets dans le blog
    2
    Par défaut Oracle annonce la disponibilité de Java 16
    Oracle annonce la disponibilité de Java 16
    Tour d'horizon des nouvelles fonctionnalités et améliorations du JDK

    Oracle annonce la disponibilité de Java 16 avec 17 nouveautés (JEP) visant à améliorer la productivité des développeurs. La dernière version du Java Development Kit (JDK) intègre la finalisation des enregistrements et du filtrage par motif (Pattern Matching) pour l'opérateur instanceof, ainsi que des améliorations du langage présentées en préversion dans Java 14. Les développeurs pourront également utiliser le nouvel outil de packaging pour livrer des applications Java autocontenues, mais aussi découvrir trois interfaces de programmation en incubation : l'API Vecteur, l'API d'édition de liens étrangers et l'API d'accès à la mémoire étrangère. Il y a en outre une fonctionnalité qui est disponible en préversion : les classes scellées.

    Oracle publie tous les six mois des mises à jour de Java afin que les développeurs puissent s'appuyer sur un calendrier de sorties prévisible. Les innovations sortent à un rythme soutenu pour améliorer constamment la performance, la stabilité et la sécurité, et contribuer à la diffusion de Java dans toutes les entreprises de tous les secteurs d'activité, quelle que soit leur taille.

    Ainsi, après un semestre de collaboration intense entre les ingénieurs Oracle et les membres de la communauté Java, le JDK 16 est disponible avec son lot de nouveautés : ont été intégrées 17 propositions d'améliorations (JEP) relatives au langage, aux outils, à la gestion de la mémoire, avec de nouvelles fonctionnalités en statut incubation ou préversion.

    Améliorations du langage présentées dans JDK 14 et finalisées dans JDK 16

    • JEP 394 : le filtrage par motif (Pattern Matching) pour l'opérateur instanceof.

    • JEP 395 : les enregistrements (Records)[/B], qui peuvent être vus comme des tuples nominaux.

    Un nouvel outil pour améliorer la productivité des développeurs

    • JEP 392 : un outil de packaging, jpackage, pour packager des applications Java autocontenues.

    Améliorations de la gestion de la mémoire pour augmenter encore les performances

    • JEP 387 : métaespace élastique. Cela permet de restituer plus rapidement au système d'exploitation la mémoire classe-métadonnées HotSpot inutilisée (c'est-à-dire le métaespace, ou metaspace), diminuer l'empreinte du métaespace et simplifier le code du métaespace pour réduire les coûts de maintenance.

    • JEP 376 : traitement simultané de la pile de threads de ZGC. Il s'agissait ici de déplacer le traitement de la pile de threads de ZGC des points de sécurité (safepoints) vers une phase concurrente.

    Amélioration du réseau pour renforcer la souplesse et la productivité des développeurs

    • JEP 380 : les canaux des sockets de domaine UNIX. L'amélioration consiste à ajouter le support de toutes les fonctionnalités des sockets de domaine Unix (communes à Windows et aux plus grandes plateformes Unix) aux API de canaux de socket et de canaux de socket serveur dans le package java.nio.channels. Les sockets de domaine Unix sont utilisées pour les communications interprocessus (IPC) sur le même hôte. Elles sont en de nombreux points comparables aux sockets TCP/IP, sauf qu'elles sont adressées par des noms de chemin du système de fichiers plutôt que par des adresses et des numéros de port Internet Protocol (IP).

    Traitement du code incompatible avec les évolutions futures

    • JEP 396 : encapsulage fort des internes du JDK par défaut. Dans le JDK 9, Oracle avait encapsulé fortement les nouveaux éléments de l'API interne, afin d'en limiter l'accès. Cependant, pour faciliter la migration, JDK 9 avait délibérément choisi de ne pas encapsuler fortement à l'exécution le contenu des packages qui existaient dans JDK 8. JDK 16 restreint cette contrainte en encapsulant par défaut la plupart des éléments internes du JDK, sauf pour des API internes critiques telles que sun.misc.Unsafe. Les utilisateurs finaux peuvent toujours choisir l'encapsulation forte plus légère qui était le comportement par défaut depuis JDK 9. Cette solution encourage les développeurs à migrer de l'utilisation d'éléments internes à l'utilisation des API standards, afin qu'eux-mêmes et leurs utilisateurs puissent passer sans problème aux futures versions de Java.

    • JEP 390 : avertissements pour les classes basées sur des valeurs. La proposition ici était de désigner les classes enveloppantes primitives comme étant basées sur des valeurs et déprécier leurs constructeurs pour encourager leur suppression, en générant de nouveaux avertissements de dépréciation. Cette version génère des avertissements de tentatives inappropriées de synchronisation sur des instances de toute classe basée sur des valeurs dans la plateforme Java.

    Nom : java_horz_clr.png
Affichages : 167953
Taille : 4,8 Ko

    Fonctionnalités en statut d'incubation ou en préversion

    • JEP 338 : API Vecteur. Cette fonctionnalité fournit une itération initiale d'un module en incubation, jdk.incubator.vector, pour exprimer des calculs de vecteurs se compilant de façon fiable à l'exécution vers des instructions matérielles optimales de vecteurs sur les architectures CPU supportées.

    • JEP 389 : API d'édition de liens étrangers (Foreign Linker API). Cette fonctionnalité en statut d'incubation introduit une API offrant un accès au code natif pur Java typé statiquement.

    • JEP 393 : API d'accès à la mémoire étrangère (Foreign-Memory Access API). Cette fonctionnalité également en statut d'incubation introduit une API permettant aux programmes Java d'accéder de façon sure et efficace à la mémoire étrangère à l'extérieur du heap Java.

    • JEP 397 : Classes scellées (préversion). Cette nouveauté enrichit le langage de programmation Java avec des classes et interfaces scellées. Les classes et interfaces scellées restreignent les autres classes ou interfaces qui pourront les étendre ou les implémenter.

    Améliorations pour les contributeurs d'OpenJDK

    • JEP 347 : activation des fonctionnalités du langage C++14 (dans le code source du JDK). Cette amélioration vise à permettre l'utilisation des fonctionnalités du langage C++14 dans le code source C++ du JDK, et formuler des recommandations précises sur les fonctionnalités qui peuvent être utilisées dans le code HotSpot.

    • JEP 357 : migration de Mercurial vers Git. Il s'agissait ici de migrer les référentiels de codes sources de la communauté OpenJDK depuis Mercurial (hg) vers Git.

    • JEP 369 : migration vers GitHub (hébergement des référentiels Git de la communauté OpenJDK sur GitHub).

    De nouveaux portages pour le support de Java sur encore plus de plateformes

    • JEP 386 : portage du JDK sur Alpine Linux et sur d'autres distributions Linux utilisant musl comme bibliothèque C primaire, sur les deux architectures x64 et AArch64.

    • JEP 388 : portage du JDK sur Windows/Aarch64

    Selon Georges Saab, Vice-Président d'Oracle en charge du développement de la plateforme Java, cette dernière version démontre toute la puissance de ce rythme semestriel. « Le filtrage par motif et les enregistrements étaient apparus pour la première fois il y a un an avec le JDK 14, ils ont, depuis, intégré plusieurs cycles de commentaires de la communauté basés sur leur utilisation dans des applications opérationnelles. Ce processus a permis aux développeurs Java d'expérimenter ces fonctionnalités avant leur finalisation, mais il a aussi permis de tenir compte de ces retours essentiels pour aboutir à deux JEP solides comme le roc, qui répondent vraiment aux besoins de la communauté », dit-il. Java 16 est disponible en téléchargement pour les différentes plateformes prises en charge.

    Source : Oracle, Nouveautés du JDK 16

    Et vous ?

    Que pensez-vous de ces nouvelles fonctionnalités et améliorations ?
    Lesquelles appréciez-vous le plus ? Pourquoi ?
    Quelles fonctionnalités disponibles dans les autres langages aimeriez-vous voir dans Java ?

    Voir aussi :

    Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java, y a-t-il des raisons de regretter les applets Java ?
    Alors que Java fête ses 25 ans, Oracle annonce l'arrivée de JDK 15. Cette version modernise le code existant et s'accompagne de la suppression du moteur JavaScript Nashorn
    Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent, et devrait arriver avec la prise en charge des fonctionnalités du C++ 14
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  3. #3
    lvr
    lvr est déconnecté
    Membre éprouvé Avatar de lvr
    Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    avril 2006
    Messages
    866
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : avril 2006
    Messages : 866
    Points : 1 174
    Points
    1 174
    Par défaut
    Je suis un peu confus entre les version du JRE et celles du JDK.
    Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?

  4. #4
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Citation Envoyé par lvr Voir le message
    Je suis un peu confus entre les version du JRE et celles du JDK.
    Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?
    Non. L'inverse est possible mais c'est déjà moins étonnant. Ça veut dire qu'on peut utiliser les programmes et libs existants, sans être obligé de garder les versions de Java qui les ont faites à l'époque (et sans être obligé de se caler sur une version unique de Java pour les différentes bibliothèques.)
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2009
    Messages
    379
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 379
    Points : 1 277
    Points
    1 277
    Par défaut
    Citation Envoyé par lvr Voir le message
    Je suis un peu confus entre les version du JRE et celles du JDK.
    Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?
    Le JRE contient ce qu'il faut pour éxécuter du Java.

    Je JDK contient le JRE plus ce qu'il faut pour développer en Java (le compilateur Javac par exemple). A noter que certaines technos peuvent avoir besoin du JDK pour être exécuté car elles génèrent du code automatiquement (JSP/SOAP sont des exemples de mémoire).

    Il est impossible d'écrire du code incompatible avec une version précédente et de l’exécuter dessus. En revanche tu peux prendre un JDK 16, régler ton environnement en Java 8 et écrire le code en conséquence.

  6. #6
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    562
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 562
    Points : 1 890
    Points
    1 890
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Non. L'inverse est possible mais c'est déjà moins étonnant. Ça veut dire qu'on peut utiliser les programmes et libs existants, sans être obligé de garder les versions de Java qui les ont faites à l'époque (et sans être obligé de se caler sur une version unique de Java pour les différentes bibliothèques.)
    L'inverse est possible, mais attention, pas toujours: il faut aussi que tu n'aies pas utilisé une des nombreuses librairies qu'Oracle a considéré comme obsolètes depuis la version 9, ou alors tu dois les télécharger séparément. J'ai notamment le cas pour un projet que je maintiens mais qui a une vieille dépendance à JAXB dont on peine à se débarasser parce que nous avons des dépendances à d'autres librairies qui elles ont conservé l'usage de JAXB.

  7. #7
    Membre à l'essai Avatar de Jonathan muswil
    Homme Profil pro
    informatitien
    Inscrit en
    juillet 2018
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : Congo-Kinshasa

    Informations professionnelles :
    Activité : informatitien

    Informations forums :
    Inscription : juillet 2018
    Messages : 21
    Points : 12
    Points
    12
    Par défaut
    Quand je pense a sun vraiment 🤔🤔🤔

  8. #8
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2009
    Messages
    379
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 379
    Points : 1 277
    Points
    1 277
    Par défaut
    Citation Envoyé par esperanto Voir le message
    L'inverse est possible, mais attention, pas toujours: il faut aussi que tu n'aies pas utilisé une des nombreuses librairies qu'Oracle a considéré comme obsolètes depuis la version 9, ou alors tu dois les télécharger séparément. J'ai notamment le cas pour un projet que je maintiens mais qui a une vieille dépendance à JAXB dont on peine à se débarasser parce que nous avons des dépendances à d'autres librairies qui elles ont conservé l'usage de JAXB.
    Sur les cas que j'ai eu ce n'est pas vraiment difficile, j'ai passé un code Java 8 JAXB / Corba en Java 11 sans trop de soucis.

    Maintenant si on tombe sur des cas ou des personnes ont utilisées des vieilles classes internes au JRE, ce sera un autre problème.

  9. #9
    Membre expérimenté
    Homme Profil pro
    Ingénieur
    Inscrit en
    septembre 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : septembre 2002
    Messages : 2 096
    Points : 1 610
    Points
    1 610
    Par défaut
    Par expérience je me rends compte que bon nombre de professionnels migrent ou ont migré vers d'autres langages.

    En effet, la réactivité de Oracle semble venir trop tard pour éviter une "hémorragie" vers d'autres horizons.

    Dommage car JAVA était un bon produit du temps de Sun qui avait un dynamisme et une politique permettant de pallier aux évolutions qu'il aurait fallut faire il y a bien des années.

    A+
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

  10. #10
    lvr
    lvr est déconnecté
    Membre éprouvé Avatar de lvr
    Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    avril 2006
    Messages
    866
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : avril 2006
    Messages : 866
    Points : 1 174
    Points
    1 174
    Par défaut
    Comment gérer l'hétérogénéité de la distribution du JRE pour des app grand public ?
    Je constate que sous Windows c'est encore souvent la 1.8 (sans toujours une possibilité de mettre à jour (ex des PC corporate)).
    Sous ma VM Xubuntu, openJdk 8 et 11 sont présents, ...
    Donc j'aurais tendance à tout garder sour Java 8, tant qu'elle est supportée, et quand elle ne l'est plus, alors passer à Java 11.
    C'est quoi votre approche ?

  11. #11
    Membre expérimenté
    Homme Profil pro
    Ingénieur
    Inscrit en
    septembre 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : septembre 2002
    Messages : 2 096
    Points : 1 610
    Points
    1 610
    Par défaut
    Citation Envoyé par lvr Voir le message
    Donc j'aurais tendance à tout garder sour Java 8, tant qu'elle est supportée, et quand elle ne l'est plus, alors passer à Java 11.
    C'est quoi votre approche ?
    Après près de 20 ans de bons et loyaux services, cela fait 2 ans que je ne réalise plus d'applications en JAVA et la vie est belle.
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

  12. #12
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Ça tombe bien, ça fait un sacré bail que Java 8 n'est plus supporté. En tout cas pas sa version canonique, fournie par Oracle. D'autres comme Coretto fournissent leur propre mouture du JDK 8 et le maintiennent encore, jurant à qui veut l'entendre que ça continuera pendant un bon moment.

    Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.

    "Mais l'intérêt de Java n'est-il pas d'être indépendant des système et machine hôtes ?" Ça fait un sacré bail que Java n'est plus le seul, et les autres qui font pareil, ne distribuent que des exécutables natifs. Autrement dit, ça fait bien plus de 10 ans qu'on a compris que s'abstraire de l'hôte, ça donne de gros avantages d'architecture de conception, mais que le fait qu'à la fin le livrable binaire puisse tourner sur n'importe quelle machine ça n'a aucun intérêt. Il en existe trois, de toute façon, des machines différentes. L'abstraction précitée permet de partir du programme Java et de générer les trois binaires pour les trois machines clientes possibles, sans effort.

    Quant aux cas où on a vraiment besoin d'être abstraits du système, c'est pour être capable de s'adapter aux changements d'écosystèmes qui ne préviennent pas. C'est pour les applications hébergées, pas les applications qui tournent sur un ordi de salon. Et même si c'est pas le fournisseur qui héberge, en 2019 (pardon, 2021,) les livrables de ce genre d'applis ce sont des images docker. Sur lesquelles Java entre autres est installé. Dont le fournisseur a bien évidemment lui-même choisi la version.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  13. #13
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2009
    Messages
    379
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 379
    Points : 1 277
    Points
    1 277
    Par défaut
    Une autre raison pour fournir des exécutables est que cela permet de bloquer la ligne de commande aux utilisateurs lambda comme mesure de sécurité.

    Car si tu livre avec un .bat, il faut autoriser la ligne de commande.

    Quant aux bienfondé de bloqué la ligne de commande, je n'en sais rien

  14. #14
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 218
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 218
    Points : 20 686
    Points
    20 686
    Par défaut
    Citation Envoyé par walfrat Voir le message
    Car si tu livre avec un .bat, il faut autoriser la ligne de commande.
    ? Curieuse idée... Il suffit de double-cliquer sur le .bat.

    Et de fournir un raccourci avec icône qui se contente de lancer le .bat.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  15. #15
    Membre expérimenté
    Homme Profil pro
    Ingénieur
    Inscrit en
    septembre 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : septembre 2002
    Messages : 2 096
    Points : 1 610
    Points
    1 610
    Par défaut
    Citation Envoyé par walfrat Voir le message

    Car si tu livre avec un .bat, il faut autoriser la ligne de commande.
    On peut aussi fournir le programme sur disquette...
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

  16. #16
    lvr
    lvr est déconnecté
    Membre éprouvé Avatar de lvr
    Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    avril 2006
    Messages
    866
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : avril 2006
    Messages : 866
    Points : 1 174
    Points
    1 174
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.
    Je crois que je vais me pencher vers .jarpackager. Mais, bon, comme mes apps sont des apps perso fait sur mon petit temps libre et que je mets à dispo de qui ça intéresse, cette hétérogénéité ne motive pas trop à partager son taf...

  17. #17
    lvr
    lvr est déconnecté
    Membre éprouvé Avatar de lvr
    Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    avril 2006
    Messages
    866
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : avril 2006
    Messages : 866
    Points : 1 174
    Points
    1 174
    Par défaut
    Citation Envoyé par thelvin Voir le message
    Sinon, l'approche recommandée, c'est de fournir des exécutables natifs aux clients chez qui on installe pas Java nous-même. jpackager (pour faire des .exe, .msi ou équivalents MacOS et linux à partir d'un programme Java) est justement mis en avant dans cette nouvelle release. Il existait avant, et puis il y avait des alternatives tierces.
    Je suis parti vers le plugin Maven io.github.fvarrui.javapackager .
    Je cale sur comment faire un exe Linux (e.g. un ".deb") sous Windows...De manière, avec javapackager, c'est possible où la seule option est de faire un ".tar.gz" ?

  18. #18
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2009
    Messages
    379
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 379
    Points : 1 277
    Points
    1 277
    Par défaut
    Citation Envoyé par thelvin Voir le message
    ? Curieuse idée... Il suffit de double-cliquer sur le .bat.

    Et de fournir un raccourci avec icône qui se contente de lancer le .bat.
    Ben d'après ce qu'on m'a rapporté, si tu interdit l'accès a cmd.exe au poste client, double clicquer sur un bat ne marche pas. Il faut donc livrer un EXE.

  19. #19
    Rédacteur/Modérateur

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

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

    Informations forums :
    Inscription : août 2005
    Messages : 6 615
    Points : 22 951
    Points
    22 951
    Billets dans le blog
    50
    Par défaut
    Citation Envoyé par lvr Voir le message
    Je suis un peu confus entre les version du JRE et celles du JDK.
    Peut-on écrire du code avec le JDK 16 (pour par exemple profiter de fonctionnalités comme les blocs de textes) et l'exécuter avec une JRE 1.8 ?
    Le JRE n'existe plus depuis belle lurette, deal with it!

    Il devrait etre possible d’écrire du code en JDK 16 pour l'executer sur du JDK/JRE (1.)8 si on se contente d'utiliser des anciennes API, aucun des ajouts apportes par les JDK 9-10-11-12-13-14-15 et 16 et avec le flag qu'il faut pour sortir du bytecode compatible JDK/JRE (1.)8. Qq chose dans le genre javac -source 1.8 -target 1.8 ... ou un truc du genre. Normalement les IDE permettent de configurer ce genre de choses.

    Et sinon on vous fourni un outil pour créer des applications avec lanceur natif donc le fichier bat/script de lancement sur la ligne de commande il serait également temps de l'envoyer aux oubliettes. Bon après il va falloir aussi la signer numériquement votre app si vous voulez pas que Windows / votre antivirus envoie des alarmes a l'utilisateur...
    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

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

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 4 184
    Points : 12 801
    Points
    12 801
    Par défaut
    Citation Envoyé par bouye Voir le message
    Il devrait etre possible d’écrire du code en JDK 16 pour l'executer sur du JDK/JRE (1.)8 si on se contente d'utiliser des anciennes API, aucun des ajouts apportes par les JDK 9-10-11-12-13-14-15 et 16 et avec le flag qu'il faut pour sortir du bytecode compatible JDK/JRE (1.)8. Qq chose dans le genre javac -source 1.8 -target 1.8 ... ou un truc du genre. Normalement les IDE permettent de configurer ce genre de choses.
    C'est possible, mais je le déconseille fortement. En faisant ça, on peut facilement utiliser sans s'en rendre compte une méthode/classe qui n'existe pas dans la version ciblée. Du coup, on se retrouve, avec un code qui compile et fonctionne bien sur l'environnement de développement, mais qui plantera à l'exécution sur l'environnement final, parfois de manière sournoise.

    Il est généralement plus prudent d'utiliser le JDK qui correspond à la version minimale ciblée.

Discussions similaires

  1. Réponses: 2
    Dernier message: 08/04/2020, 14h13
  2. Réponses: 0
    Dernier message: 19/07/2017, 18h54
  3. Réponses: 3
    Dernier message: 11/07/2008, 12h56
  4. Comment effectuer un saut de page si un table est coupé au cours d'une impression ?
    Par jean-pierre96 dans le forum Balisage (X)HTML et validation W3C
    Réponses: 3
    Dernier message: 29/05/2007, 13h33

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