Was ist ein benutzerdefiniertes Runtime-Image in Java 9?

Java 9 führte die Idee modularer Runtime-Images mit Project Jigsaw ein und löste offiziell das Problem, Java Runtime als monolithische Artefakte zu versenden. Monolithische Runtime-Images verbrauchten nicht nur viel Speicher, sondern verringerten auch die Gesamtleistung der darauf ausgeführten Anwendung. Wir können jetzt eine kundenspezifische Teilmenge von JRE packen, basierend auf den individuellen Bedürfnissen der Anwendungen, die darauf laufen, und ihre Effizienz um ein Vielfaches steigern. Dieser Artikel wirft einen ganzheitlichen Blick auf diese mit Java 9 eingeführte Funktion benutzerdefinierter Laufzeit-Images.

Ein Überblick

Die Wirkung der Idee, mit Java 9 ein modulares Runtime-Image zu erstellen, ist enorm. Es öffnet die Tür für eine kundenspezifische Anwendung direkt von der Plattform, auf der es ausgeführt wird. Die Java-Plattform hat ihre Funktionalität mit jeder neuen Version erweitert. Es ist keine Überraschung, dass die Laufzeit irgendwann ein monolithisches Artefakt sein und Speicher und Leistung stark belasten wird. Aus diesem Grund fordern Entwickler seit langem einen Ausweg aus diesem Problem. Außerdem verwenden die meisten Programme die Java-Plattform nicht vollständig. Wenn ein Programm hinsichtlich Leistung und Speichernutzung optimiert werden kann, warum kann dann nicht auch die Plattform, auf der es läuft, angepasst werden? Java 8 unternahm den ersten Schritt und versuchte, einige Aspekte davon mit Compact Profiles zu implementieren . Java 9 hat es weiterentwickelt und eine Möglichkeit implementiert, Runtime-Images ohne Einschränkungen wie Compact Profiles zu erstellen auferlegt. Beim Packen von Runtime-Images wurde ein ganzheitlicher Ansatz verfolgt. Die Plattform selbst ist modularisiert, um diese Funktion zu ermöglichen. In Module gepackter Anwendungscode kann mit benutzerdefinierten Laufzeitabbildern ausgeliefert werden, die nur die Plattformmodule enthalten, die von der Anwendung verwendet werden. Somit kann ein Anwendungsprogramm ein einzelnes gebündeltes Artefakt sein, das die benutzerdefinierte JRE enthält. Dies steigert sicherlich die Leistung und gewährt eine Startzeit mit weniger Speicherbedarf. Wenn die Anwendung in der Cloud läuft, verringern diese die Netzwerküberlastung und die Downloadzeit erheblich.

Kompaktes Profil

Obwohl Java 9 das Konzept des Compact Profile überwunden hat Mit Java 8 eingeführt, ist es oft hilfreich, den erreichten Meilenstein zu verstehen und zu schätzen. In gewisser Weise nährte Java 9 die Idee und verbesserte das Konzept eines Compact Profile auf ganzheitlichere Weise.

Ein Kompaktes Profil definiert Teilmengen der Java SE-Plattform-API, die die statische Größe der Java-Laufzeit reduzieren können. Diese Idee zielt im Wesentlichen darauf ab, auf ressourcenbeschränkten Geräten zu arbeiten, die kleinere Speicherkapazitäten haben, wie z. B. ein eingebettetes Gerät. Grundsätzlich gibt es drei Profile, genannt compact1 , compact2 und compact3 . Jedes höher nummerierte Profil ist eine Obermenge seines niedriger nummerierten Profils. Das bedeutet, dass compact1 ist eine richtige Teilmenge von compact2 , compact2 ist eine richtige Teilmenge von compact3 und compact3 , ist wiederum eine richtige Teilmenge der Full-Stack-Java-8-SE-API.

Referenzen:

• Kompakte Profile, Java SE 8-Dokumentation
• Java SE Embedded 8 Compact-Profile – Übersicht
• Eine Einführung in Java 8 Compact-Profile

Wir stellen JIMAGE vor

JIMAGE ist ein spezielles Dateiformat, das mit Java 9 eingeführt wurde, um benutzerdefinierte Runtime-Images zu speichern. Dieses Dateiformat ist für Leistung und Speicherung optimiert. Das Dateiformat fungiert im Wesentlichen als Container für JDK-Ressourcen, -Klassen und -Module und indiziert sie für eine schnelle Suche und ein schnelleres Laden von Klassen. Im Gegensatz zu anderen Dateiformaten wie JARs und JMODs wird JIMAGE selten von Entwicklern verwendet, da es sich auf JDK-Interna bezieht, außer wenn man ein benutzerdefiniertes Runtime-Image erstellen möchte. Das Laden von Klassen ist mit JIMAGE schneller als mit JARs oder JMODs, da es speziell dafür optimiert ist. Außerdem kann JIMAGE nur zur Laufzeit verwendet werden. JIMAGE steckt noch in den Kinderschuhen. Es sind nur sehr wenige Entwicklerinformationen verfügbar; vielleicht wird später noch mehr aufgedeckt.

Benutzerdefinierte Bilder erstellen

Java 9 liefert den jlink Tool zum Erstellen plattformspezifischer Runtime-Images. Benutzerdefinierte Images enthalten anwendungsspezifische Module und die erforderlichen Module der Plattform. Da die Größe des Runtime-Images, auch bekannt als JRE, auf das Nötigste reduziert ist, ist das Anwendungs-Image zusammen mit der JRE ebenfalls minimal. Es bündelt die JRE als einzelne Liefereinheit zusammen mit dem Programm. Der jlink Das Tool befindet sich im Verzeichnis /bin Verzeichnis des JDK9 installiertes Verzeichnis. Es stehen mehrere Optionen zur Verfügung, die mit diesem Tool verbunden sind und je nach Anforderung verwendet werden können. Die Beschreibung kann über die –Hilfe abgerufen werden Option verfügbar mit dem jlink Befehl. Hier wird es der Einfachheit halber extrahiert, oder Sie können jlink –help eingeben in der Befehlszeile, um die folgende Liste zu erhalten.

Verwendung:

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

Ein einfaches Beispiel

Hier gehen wir von Anfang bis Ende durch ein sehr einfaches Programm, wie man ein Runtime-Image einer Java-Anwendung erstellt. Wir gehen davon aus, dass JDK9 korrekt installiert ist und der PATH und JAVA_HOME Umgebungsvariable entsprechend gesetzt sind. In meinem Fall wird es wie folgt installiert und eingestellt (auf einer Linux-Plattform):

• JDK9 installiertes Verzeichnis /usr/lib/jvm/java-9-oracle
• PFAD ist auf /usr/lib/jvm/java-9-oracle/bin eingestellt
• JAVA_HOME ist auf /usr/lib/jvm/java-9-oracle eingestellt

Schritt 1

Erstellen Sie ein Verzeichnis namens /Home/SampleProject und ein src Verzeichnis darin (zum Beispiel /Home/SampleProject/src ).

Schritt 2

Erstellen Sie ein Verzeichnis namens org.app.test innerhalb der src Verzeichnis (als Beispiel /Home/SampleProject/src/org.app.test ).

Schritt 3

Jetzt innerhalb von org.app.test erstellen Sie eine Datei mit dem Namen module-info.java . Und geben Sie den folgenden Inhalt ein:

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

Schritt 4

Erstellen Sie nun ein Verzeichnis namens org, app, test ineinander (z. B. org.app.test/org/app/test ) und erstellen Sie dann eine Datei mit dem Namen MyApplication.java innerhalb des Tests Verzeichnis und geben Sie den folgenden Inhalt ein:

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.");
         }
      });
   }
}

Schritt 5

Erstellen Sie ein /Home/SampleProject/mods Verzeichnis. Hier speichern wir den kompilierten Code. Kompilieren Sie den Quellcode wie folgt. Das aktuelle Arbeitsverzeichnis ist /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

Schritt 6

Lassen Sie uns nun die JAR-Datei erstellen und in der lib speichern Verzeichnis (z. B. /Home/SampleProject/lib ) wie folgt:

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

Schritt 7

Führen Sie die Anwendung zum Testen wie folgt aus:

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

Schritt 8

Lassen Sie uns nun die JMOD-Datei erstellen und in jmods speichern Verzeichnis (zum Beispiel Home/SampleProject/jmods ):

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

Schritt 9

Lassen Sie uns schließlich das benutzerdefinierte Image mit dem folgenden Befehl erstellen:

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

Dadurch wird ein Ordner namens dist erstellt die alles enthält, was zum Ausführen der Anwendung erforderlich ist. Das Programm, dessen Launcher-Name als runapp angegeben ist , ist in dist/bin enthalten Verzeichnis. Doppelklicken Sie darauf, um es auszuführen.

Abbildung 1: Das Programm läuft

Das ist alles.

Schlussfolgerung

Eine detaillierte Beschreibung zu jeder der in diesem Artikel verwendeten Befehlsoptionen finden Sie in der entsprechenden Dokumentation. Probieren Sie ein einfaches Programm aus und erstellen Sie es von Anfang bis Ende. Dies würde das nötige Selbstvertrauen aufbauen, um mit einem etwas komplizierteren Programm zu experimentieren, z. B. mehr als ein Modul zu verwenden und mit ihren Abhängigkeiten umzugehen. JDK9 hat Entwicklern die Möglichkeit gegeben, ihr Laufzeitpaket so vorzubereiten, dass es nur mit den notwendigen Modulen gefüllt wird. Das ist erstaunlich und exzellent, etwas, was die meisten von uns schon lange von Java erwartet haben. Eine Java-Anwendung kann jetzt den Ballast abschütteln, den sie scheinbar ohne Grund tragen musste, und in der Verteilung plattformoptimiert werden.