IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

bouye

[Actualité] OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage

Noter ce billet
4 Commentaires
par
bouye
, 04/09/2019 à 00h41 (1916 Affichages)
OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage,
l'outil en ligne de commande de créations de lanceurs natifs pour Java

jpackage est défini dans la proposition d’amélioration JEP 343: Packaging Tool comme étant un ensemble d'outils pour créer des lanceurs natifs pour les applications Java pour les principaux systèmes d'exploitation supportés par Java coté client (Linux, macOS et Windows). Dans son concept, il reprend dans les grandes lignes les fonctionnalités de javafxpackager, un outil introduit par Oracle dans le JDK7 et destiné à créer des lanceurs natifs pour JavaFX. Cet outil était devenu par la suite javapackager dans les JDK 8, 9 et 10 et permettait de créer des lanceurs pour n'importe quel type d'application Java (CLI, Swing).

Les applications ainsi créées contenaient une JVM embarquée ainsi que des lanceurs, installeurs et désinstalleur natifs adaptés au système d'exploitation hôte (exe, msi, pkg, dmg, deb ou encore rpm) et facilitaient l'expérience utilisateur de l'installation et de la désinstallation ou encore des icônes et descriptifs de l'application. Ces paquetages natifs permettaient la prise en charge des signatures numériques natives pour vérifier l’authenticité du paquetage par l'OS ou l'antivirus et facilitaient également la création d'une distribution de l'application compatible sur les magasins en ligne des éditeurs.

Il avait cependant cessé d’évoluer et ne supportait pas les modules. Ne faisant de plus pas partie de l'OpenJDK, javapackager avait été retiré des JDK 11 et 12 au profit de jlink un outil supportant les modules et capable de créer une distribution Java restreinte, mais sans support de lanceurs ou installeur natifs, ce qui avait créé un vide dans écosystème Java coté client.

Bien que jpackage fut initialement prévu pour le JDK 13, cette version anticipée est construite sur une version préliminaire du JDK 14. L'outil tiers Wix est toujours requis pour construire des installeurs sous Windows.

Source :

Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog Viadeo Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog Twitter Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog Google Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog Facebook Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog Digg Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog Delicious Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog MySpace Envoyer le billet « OpenJDK annonce la mise en disponibilité en accès anticipé de jpackage » dans le blog Yahoo

Mis à jour 06/09/2019 à 04h49 par bouye

Catégories
Java , Java

Commentaires

  1. Avatar de Gugelhupf
    • |
    • permalink
    Bonjour,

    Quels sont les différences entre la JEP 148: Small VM et la JEP 343: Packaging Tool ? Je pensais que la JEP 148 avait pour objectif de créer des applications Java natives.

    Est-ce que jpackage est une initiative pour concurrencer Golang ? (un peu comme comme jshell contre les langages de script)

    Merci pour le billet
  2. Avatar de bouye
    • |
    • permalink
    Salut,
    il n’y a aucun rapport entre les deux JEP, il suffit de lire leur descriptif. Le but de la JEP 343 est de créer des lanceurs et installleurs/désinstalleur natifs tandis que celui de la JEP 148 est de réduire la taille de la JVM (encore plus qu’actuellement et ce pour les machines embarquées - small devices est mentionné dans la description). À la rigueur la JEP 148 semble se rapporter aux fonctionnalités de jlink et serait une optimisation supplémentaire sur ce que cet outil peut faire actuellement. Après en combinant les deux ben ça permet d’avoir des applications plus légères à distribuer.

    Y a aucun rapport entre Golang, jshell et jpackage... ; le premier est un langage compilé, le deuxième est un environnement d’interprétation d’instructions écrites en Java et le troisième un outil de packaging... où as-tu bien pu chercher une telle idée...
    Mis à jour 07/09/2019 à 05h45 par Malick (correction de petites coquilles)
  3. Avatar de Gugelhupf
    • |
    • permalink
    Nous avions eu quelques discussion avec la communauté à l'époque où la JEP 148 était créée, il était question d'avoir des applications Java ne nécessitant pas de machine avec une JRE pour fonctionner, et ne nécessitant pas d'embarquer un dossier contenant toute la JRE. GCJ étant obsolète, la JEP 148 semblait être une solution pouvant satisfaire ce besoin.

    Je sais bien qu'il n'y a aucun rapport entre Golang, jshell et jpackage (je pourrais presque me sentir offensé par ta réponse ), c'était à titre de comparaison entre Java et la concurrence.
  4. Avatar de chinagirl
    • |
    • permalink
    C'est une bonne nouvelle.
    Il faut que je trouve le temps d'essayer ça car j'ai commencé à porter des applis 8 en 12 et en 8 il y a le javapackager.

    Je trouve que fournir Java sans cela a été une erreur car dans le camp d'en face (Node), il y a des solutions qui fonctionnent (Electron) et choisies par Microsoft par exemple.
    Java devrait se mettre au moins au même niveau de façon à ne plus se poser 15000 questions quand on veut faire une appli desktop en Java.