Qu'est-ce qu'une image d'exécution personnalisée dans Java 9 ?

Java 9 a introduit l'idée d'images d'exécution modulaires avec Project Jigsaw et a officiellement résolu le problème de l'expédition de l'exécution Java sous forme d'artefacts monolithiques. Les images d'exécution monolithiques étaient non seulement lourdes sur l'utilisation de la mémoire, mais elles ralentissaient également les performances globales de l'application qui s'y exécutait. Nous pouvons désormais emballer un sous-ensemble personnalisé de JRE, en fonction des besoins individuels des applications qui s'y exécutent et augmenter leur efficacité. Cet article présente une vue d'ensemble de cette fonctionnalité d'images d'exécution personnalisées introduite avec Java 9.

Un aperçu

L'impact de l'idée de créer une image d'exécution modulaire avec Java 9 est énorme. Il ouvre la porte à une application personnalisée directement à partir de la plate-forme sur laquelle elle s'exécute. La plate-forme Java augmente ses fonctionnalités à chaque nouvelle version. Il n'est pas surprenant qu'à un moment donné, le temps d'exécution soit un artefact monolithique et pèse lourdement sur la mémoire et les performances. Pour cette raison, les développeurs demandent depuis longtemps une solution à ce problème. De plus, la plupart des programmes n'utilisent pas la plate-forme Java dans son intégralité. Si un programme peut être optimisé pour les performances et l'utilisation de la mémoire, pourquoi la plate-forme sur laquelle il s'exécute ne peut-elle pas également être personnalisée ? Java 8 a fait le premier pas et a essayé d'en implémenter certains aspects avec Compact Profiles . Java 9 l'a fait avancer et a implémenté un moyen de créer des images d'exécution personnalisées sans contraintes que les profils compacts imposé. Il a adopté une approche holistique dans l'empaquetage des images d'exécution. La plate-forme elle-même est modularisée pour permettre cette fonctionnalité. Le code d'application empaqueté dans des modules peut être livré avec des images d'exécution personnalisées qui contiennent uniquement les modules de plate-forme utilisés par l'application. Ainsi, un programme d'application peut être un seul artefact groupé qui inclut le JRE personnalisé. Cela tire certainement parti des performances, en accordant un temps de démarrage avec moins d'empreintes mémoire. Si l'application s'exécute dans le Cloud, cela réduit considérablement la surcharge du réseau et le temps de téléchargement.

Profil compact

Bien que Java 9 ait dépassé le concept de Compact Profile introduit avec Java 8, il est souvent utile de comprendre et d'apprécier le jalon atteint. D'une certaine manière, Java 9 s'est nourri de l'idée et a fait évoluer le concept de Compact Profile d'une manière plus holistique.

Un profil compact définit des sous-ensembles de l'API de la plate-forme Java SE qui peuvent réduire la taille statique de l'environnement d'exécution Java. Cette idée est essentiellement destinée à fonctionner sur des appareils à ressources limitées qui ont des capacités de stockage plus petites, comme un appareil intégré. Il existe essentiellement trois profils, appelés compact1 , compact2 , et compact3 . Chaque profil de numéro supérieur est un sur-ensemble de son profil de numéro inférieur. Cela signifie que compact1 est un sous-ensemble approprié de compact2 , compact2 est un sous-ensemble approprié de compact3 , et compact3 , à son tour, est un sous-ensemble approprié de l'API Java 8 SE complète.

Références :

• Profils compacts, documentation Java SE 8
• Présentation des profils compacts Java SE Embedded 8
• Une introduction aux profils compacts Java 8

Présentation de JIMAGE

Le JIMAGE est un format de fichier spécial introduit avec Java 9 pour stocker des images d'exécution personnalisées. Ce format de fichier est optimisé pour les performances et le stockage. Le format de fichier agit essentiellement comme un conteneur pour les ressources, les classes et les modules JDK, et les indexe pour une recherche rapide et un chargement de classe plus rapide. Contrairement à d'autres formats de fichiers tels que les JAR et les JMOD, JIMAGE est rarement utilisé par les développeurs en ce qui concerne les composants internes du JDK, sauf lorsque l'on souhaite créer une image d'exécution personnalisée. Le chargement des classes est plus rapide avec JIMAGE qu'avec les JAR ou les JMOD car il est spécifiquement optimisé pour cela. De plus, JIMAGE ne peut être utilisé qu'au moment de l'exécution. JIMAGE en est encore à ses débuts. Il y a très peu d'informations disponibles sur les développeurs; peut-être que d'autres seront exposés plus tard.

Création d'images personnalisées

Java 9 fournit le jlink outil pour créer des images d'exécution spécifiques à la plate-forme. Les images personnalisées contiennent des modules spécifiques à l'application et les modules requis de la plate-forme. Étant donné que la taille de l'image d'exécution alias JRE est réduite au strict minimum, l'image de l'application avec le JRE est également minimale. Il regroupe le JRE en une seule unité de livraison avec le programme. Le jlink l'outil est situé dans /bin répertoire du JDK9 répertoire installé. Il existe plusieurs options disponibles associées à cet outil qui peuvent être utilisées en fonction des besoins. La description peut être obtenue en utilisant –help option disponible avec le jlink commande. Ici, il est extrait pour plus de commodité, ou vous pouvez taper jlink –help dans la ligne de commande pour obtenir la liste suivante.

Utilisation :

jlink <options> --module-path <modulepath>
   --add-modules <module>[,<module>...]

Un exemple simple

Ici, nous allons parcourir un programme très simple du début à la fin de la création d'une image d'exécution d'une application Java. Nous supposerons que JDK9 est correctement installé et le PATH et JAVA_HOME variable d'environnement sont définies de manière appropriée. Dans mon cas, il est installé et configuré comme suit (sur une plate-forme Linux) :

• JDK9 répertoire installé /usr/lib/jvm/java-9-oracle
• CHEMIN est défini sur /usr/lib/jvm/java-9-oracle/bin
• JAVA_HOME est défini sur /usr/lib/jvm/java-9-oracle

Étape 1

Créez un répertoire nommé /Home/SampleProject et un src répertoire à l'intérieur (par exemple, /Home/SampleProject/src ).

Étape 2

Créez un répertoire nommé org.app.test à l'intérieur du src répertoire (par exemple, /Home/SampleProject/src/org.app.test ).

Étape 3

Maintenant, dans org.app.test répertoire, créez un fichier nommé module-info.java . Et saisissez le contenu suivant :

module org.app.test{
   requires javafx.controls;
   exports org.app.test;
}

Étape 4

Maintenant, créez un répertoire nommé org, app, test l'un dans l'autre (par exemple, org.app.test/org/app/test ) puis créez un fichier nommé MyApplication.java à l'intérieur du test répertoire et saisissez le contenu suivant :

package org.app.test;

import javafx.application.Application;
import javafx.scene.control.Alert;
import javafx.scene.control.ButtonType;
import javafx.stage.Stage;

public class MyApplication extends Application{

   public static void main(String[] args) {
      Application.launch(args);
   }

   @Override
   public void start(Stage stage) throws Exception {

      Alert alert = new Alert(Alert.AlertType.INFORMATION);
      alert.setTitle("Congratulation!");
      alert.setHeaderText("You did it. The application is
         running.
      Press OK to close");
      alert.setContentText("You have successfully created a
         custom image");
      alert.showAndWait().ifPresent(rs -> {
         if (rs == ButtonType.OK) {
            System.out.println("Pressed OK.");
         }
      });
   }
}

Étape 5

Créer un /Home/SampleProject/mods annuaire. Ici, nous allons enregistrer le code compilé. Compilez le code source comme suit. Le répertoire de travail actuel est /Home/SampleProject .

javac -d mods --module-source-path src
src/org.app.test/module-info.java
src/org.app.test/org/app/test/MyApplication.java

Étape 6

Maintenant, créons le fichier JAR et stockons-le dans la lib répertoire (tel que /Home/SampleProject/lib ) comme suit :

jar --create --file lib/org.app.test.jar
--main-class org.app.test.MyApplication
-C mods/org.app.test .

Étape 7

Pour tester, exécutez l'application comme suit :

java --module-path lib -m org.app.test

Étape 8

Maintenant, créons le fichier JMOD et enregistrons-le dans le jmods répertoire (par exemple, Home/SampleProject/jmods ):

jmod create --class-path lib/org.app.test.jar
   jmods/org.app.test.jmod

Étape 9

Enfin, créons l'image personnalisée en utilisant la commande suivante :

jlink --module-path /usr/lib/jvm/java-9-oracle/jmods/:jmods
--add-modules org.app.test
--launcher runapp=org.app.test
--output dist

Cela créera un dossier nommé dist qui contient tout ce qui est nécessaire pour exécuter l'application. Le programme, avec le nom du lanceur donné comme runapp , est contenu dans dist/bin annuaire. Double-cliquez dessus pour exécuter.

Figure 1 : Le programme est en cours d'exécution

C'est tout.

Conclusion

Reportez-vous à la documentation appropriée pour une description détaillée de chacune des options de commande utilisées dans cet article. Essayez un programme simple et construisez-le du début à la fin. Cela renforcerait la confiance nécessaire pour expérimenter un programme un peu plus compliqué, comme utiliser plus d'un module et gérer leurs dépendances. JDK9 a permis aux développeurs de préparer son bagage d'exécution pour qu'il ne soit rempli que des modules nécessaires. C'est incroyable et excellent, quelque chose que la plupart d'entre nous attendaient de Java depuis longtemps. Une application Java peut désormais ignorer les bagages qu'elle devait transporter pour une raison apparemment minime et devenir une plate-forme optimisée dans la distribution.