Java 9 ha introdotto l'idea di immagini di runtime modulari con Project Jigsaw e ha ufficialmente risolto il problema della spedizione del runtime Java come artefatti monolitici. Le immagini di runtime monolitiche non solo erano pesanti per l'utilizzo della memoria, ma hanno anche rallentato le prestazioni complessive dell'applicazione in esecuzione su di esse. Ora possiamo confezionare un sottoinsieme personalizzato di JRE, in base alle esigenze individuali delle applicazioni che vengono eseguite su di esso e aumentare il loro collettore di efficienza. Questo articolo offre uno sguardo olistico a questa funzionalità delle immagini di runtime personalizzate introdotta con Java 9.
Una panoramica
L'impatto dell'idea di creare un'immagine di runtime modulare con Java 9 è enorme. Apre la porta per un'applicazione personalizzata direttamente dalla piattaforma su cui viene eseguita. La piattaforma Java ha incrementato le sue funzionalità con ogni nuova versione. Non è una sorpresa che a un certo punto il runtime sarà un artefatto monolitico e avrà un pesante tributo su memoria e prestazioni. Per questo motivo, gli sviluppatori richiedono da tempo una via d'uscita a questo problema. Inoltre, la maggior parte dei programmi non utilizza Java Platform nella sua interezza. Se un programma può essere ottimizzato per prestazioni e utilizzo della memoria, perché non è possibile personalizzare anche la piattaforma su cui viene eseguito? Java 8 ha fatto il primo passo e ha cercato di implementarne alcuni aspetti con Compact Profiles . Java 9 lo ha portato avanti e ha implementato un modo per personalizzare le immagini di runtime senza vincoli che Profili compatti imposto. È stato necessario un approccio olistico nel confezionamento delle immagini di runtime. La piattaforma stessa è modularizzata per abilitare questa funzione. Il codice dell'applicazione impacchettato nei moduli può essere spedito con immagini di runtime personalizzate che contengono solo i moduli della piattaforma utilizzati dall'applicazione. Pertanto, un programma applicativo può essere un singolo artefatto in bundle che include JRE personalizzato. Questo sicuramente sfrutta le prestazioni, garantendo un tempo di avvio con meno footprint di memoria. Se l'applicazione viene eseguita nel Cloud, questi riducono notevolmente il sovraccarico della rete e il tempo di download.
Profilo compatto
Sebbene Java 9 abbia superato il concetto di Profilo compatto introdotto con Java 8, è spesso utile comprendere e apprezzare il traguardo raggiunto. In un certo senso, Java 9 si è nutrito dell'idea e ha aggiornato il concetto di Profilo compatto in modo più olistico.
Un profilo compatto definisce sottoinsiemi dell'API della piattaforma Java SE che possono ridurre le dimensioni statiche del runtime Java. Questa idea è fondamentalmente mirata a lavorare su dispositivi con risorse limitate che hanno capacità di archiviazione inferiori, come un dispositivo incorporato. Esistono fondamentalmente tre profili, chiamati compact1 , compatto2 e compatto3 . Ogni profilo con numero più alto è un superset del profilo con numero più basso. Ciò significa che compatto1 è un sottoinsieme proprio di compact2 , compatto2 è un sottoinsieme proprio di compact3 e compatto3 , a sua volta, è un sottoinsieme appropriato dell'API Java 8 SE dello stack completo.
Riferimenti:
- Profili compatti, documentazione Java SE 8
- Panoramica di Java SE Embedded 8 Compact Profile
- Introduzione ai profili Java 8 Compact
Vi presentiamo JIMAGE
JIMAGE è un formato di file speciale introdotto con Java 9 per memorizzare immagini di runtime personalizzate. Questo formato di file è ottimizzato per prestazioni e archiviazione. Il formato del file funge fondamentalmente da contenitore per risorse, classi e moduli JDK e li indicizza per una ricerca rapida e un caricamento più rapido delle classi. A differenza di altri formati di file come JAR e JMOD, JIMAGE viene utilizzato raramente dagli sviluppatori in quanto si riferisce agli interni JDK tranne quando si desidera creare un'immagine di runtime personalizzata. Il caricamento delle classi è più veloce con JIMAGE rispetto a JAR o JMOD poiché è specificamente ottimizzato per questo. Inoltre, JIMAGE può essere utilizzato solo in fase di esecuzione. JIMAGE è ancora agli inizi. Sono disponibili pochissime informazioni sugli sviluppatori; forse ne verranno esposti altri in seguito.
Creazione di immagini personalizzate
Java 9 fornisce il jlink strumento per creare immagini di runtime specifiche della piattaforma. Le immagini personalizzate contengono moduli specifici dell'applicazione e i moduli richiesti della piattaforma. Poiché la dimensione dell'immagine di runtime, nota anche come JRE, è ridotta al minimo, anche l'immagine dell'applicazione insieme a JRE è minima. Raggruppa il JRE come un'unica unità di consegna insieme al programma. Il jlink strumento si trova in /bin directory del JDK9 directory installata. Sono disponibili diverse opzioni associate a questo strumento che possono essere utilizzate in base alle esigenze. La descrizione può essere ottenuta utilizzando il –help opzione disponibile con jlink comando. Qui viene estratto per comodità oppure puoi digitare jlink –help nella riga di comando per ottenere il seguente elenco.
Utilizzo:
jlink <options> --module-path <modulepath> --add-modules <module>[,<module>...]
| Opzione | Descrizione |
| –add-modules | Moduli root da risolvere |
| –servizi-bind | Collegamento nei moduli del fornitore di servizi e relative dipendenze |
| -c, –comprimi=<0|1|2>
–disable-plugin
–endian | Abilita la compressione delle risorse: Livello 0:nessuna compressione Livello 1:condivisione di stringhe costante Livello 2:CAP Disattiva il plug-in menzionato Ordine dei byte della jimage generata (default:native) |
| -h, –aiuto –ignora le informazioni sulla firma
–launcher
–limit-modules –list-plug-in | Stampa questo messaggio di aiuto Elimina un errore irreversibile quando i JAR modulari firmati sono collegati nell'immagine. I file relativi alla firma dei JAR modulari firmati non vengono copiati nell'immagine di runtime. Aggiungi un comando di avvio con il nome dato per il modulo e la classe principale, se specificata. Limita l'universo dei moduli osservabili. Elenca i plug-in disponibili. |
|
-p, –percorso-modulo –nessun file di intestazione –pagine-non-uomo
–output
–save-opts | Percorso modulo Escludi i file di intestazione di inclusione Escludi le pagine man Posizione del percorso di output Salva le opzioni jlink nel file specificato |
| -G, –strip-debug
–suggest-providers [ | Elimina le informazioni di debug Suggerisci provider che implementano i tipi di servizio forniti dal percorso del modulo |
| -v, –verboso –versione
@ | Abilita il tracciamento dettagliato Informazioni sulla versione Leggi le opzioni dal file |
Un semplice esempio
Qui, illustreremo un programma molto semplice dall'inizio alla fine di come creare un'immagine di runtime di un'applicazione Java. Assumiamo che JDK9 è installato correttamente e il PERCORSO e JAVA_HOME le variabili di ambiente sono impostate in modo appropriato. Nel mio caso, è installato e impostato come segue (su una piattaforma Linux):
- JDK9 directory installata /usr/lib/jvm/java-9-oracle
- PERCORSO è impostato su /usr/lib/jvm/java-9-oracle/bin
- JAVA_HOME è impostato su /usr/lib/jvm/java-9-oracle
Fase 1
Crea una directory denominata /Home/SampleProject e un sorgente directory al suo interno (ad esempio, /Home/SampleProject/src ).
Fase 2
Crea una directory denominata org.app.test all'interno di src directory (ad esempio, /Home/SampleProject/src/org.app.test ).
Fase 3
Ora, all'interno di org.app.test directory, crea un file chiamato module-info.java . E, digita i seguenti contenuti:
module org.app.test{
requires javafx.controls;
exports org.app.test;
}
Fase 4
Ora crea una directory denominata org, app, test uno dentro l'altro (ad esempio, org.app.test/org/app/test ) e quindi creare un file denominato MyApplication.java all'interno del test directory e digitare il seguente contenuto:
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.");
}
});
}
}
Fase 5
Crea un /Home/SampleProject/mods directory. Qui salveremo il codice compilato. Compila il codice sorgente come segue. L'attuale directory di lavoro è /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
Fase 6
Ora creiamo il file JAR e memorizziamolo nella lib directory (come /Home/SampleProject/lib ) come segue:
jar --create --file lib/org.app.test.jar --main-class org.app.test.MyApplication -C mods/org.app.test .
Passaggio 7
Per testare, eseguire l'applicazione come segue:
java --module-path lib -m org.app.test
Fase 8
Ora creiamo il file JMOD e lo salviamo in jmods directory (ad esempio, Home/SampleProject/jmods ):
jmod create --class-path lib/org.app.test.jar jmods/org.app.test.jmod
Fase 9
Infine, creiamo l'immagine personalizzata utilizzando il seguente comando:
jlink --module-path /usr/lib/jvm/java-9-oracle/jmods/:jmods --add-modules org.app.test --launcher runapp=org.app.test --output dist
Verrà creata una cartella denominata dist che contiene tutto ciò che è necessario per eseguire l'applicazione. Il programma, con il nome del programma di avvio dato come runapp , è contenuto in dist/bin directory. Fare doppio clic per eseguire.
Figura 1: Il programma è in esecuzione
Questo è tutto.
Conclusione
Fare riferimento alla documentazione appropriata per una descrizione dettagliata su ciascuna delle opzioni di comando utilizzate in questo articolo. Prova un semplice programma e costruiscilo dall'inizio alla fine. Ciò aumenterebbe la sicurezza necessaria per sperimentare un programma un po' più complicato, come usare più di un modulo e gestire le loro dipendenze. JDK9 ha consentito agli sviluppatori di preparare il proprio bagaglio di runtime da riempire solo con i moduli necessari. Questo è fantastico ed eccellente, qualcosa che la maggior parte di noi si aspettava da Java da molto tempo. Un'applicazione Java ora può scrollarsi di dosso il bagaglio che doveva trasportare per una ragione apparentemente minima e diventare una piattaforma ottimizzata nella distribuzione.
