Guide de Java Web Start

1. Vue d'ensemble

Cet article explique ce qu'est Java Web Start (JWS), comment le configurer côté serveur et comment créer une application simple.

Remarque: Le JWS a été supprimé du JDK Oracle à partir de Java 11. Vous pouvez également utiliser OpenWebStart.

2. Présentation

JWS est un environnement d'exécution fourni avec Java SE pour le navigateur Web du client et existe depuis la version 5 de Java.

Avec le téléchargement des fichiers JNLP (également appelés Java Network Launch Protocol) à partir du serveur Web, cet environnement nous permet d'exécuter à distance les packages JAR référencés par celui-ci.

En termes simples, le mécanisme charge et exécute les classes Java sur l'ordinateur d'un client avec une installation JRE régulière. Il permet également des instructions supplémentaires de Jakarta EE. Cependant, les restrictions de sécurité sont strictement appliquées par le JRE du client, avertissant généralement l'utilisateur des domaines non fiables, du manque de HTTPS et même des JAR non signés.

Depuis un site Web générique, on peut télécharger un fichier JNLP pour exécuter une application JWS. Une fois téléchargé, il peut être exécuté directement à partir d'un raccourci sur le bureau ou de Java Cache Viewer. Après cela, il télécharge et exécute les fichiers JAR.

Ce mécanisme peut être très utile pour fournir une interface graphique qui n'est pas basée sur le Web (sans HTML), comme une application de transfert de fichiers sécurisé, une calculatrice scientifique, un clavier sécurisé, un navigateur d'images local, etc.

3. Une application JNLP simple

Une bonne approche consiste à écrire une application et à la conditionner dans un fichier WAR pour les serveurs Web normaux. Tout ce dont nous avons besoin est d'écrire l'application souhaitée (généralement avec Swing) et de la conditionner dans un fichier JAR. Ce JAR doit ensuite, à son tour, être emballé dans un fichier WAR avec un JNLP qui référencera, téléchargera et exécutera normalement la classe Main de son application .

Il n'y a aucune différence avec une application Web standard emballée dans un fichier WAR, à l'exception du fait que nous avons besoin d'un fichier JNLP pour activer le JWS, comme cela sera démontré ci-dessous.

3.1. Application Java

Commençons par écrire une application Java simple:

public class Hello { public static void main(String[] args) { JFrame f = new JFrame("main"); f.setSize(200, 100); f.setLocationRelativeTo(null); f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); JLabel label = new JLabel("Hello World"); f.add(label); f.setVisible(true); } }

Nous pouvons voir que c'est une classe de Swing assez simple. En effet, rien n'a été ajouté pour le rendre compatible JWS.

3.2. Application Web

Tout ce dont nous avons besoin est de mettre en package JAR cet exemple de classe Swing dans un fichier WAR avec le fichier JNLP suivant:

   Hello Example       

Appelons-le hello.jndl et placez-le sous n'importe quel dossier Web de notre WAR. Le JAR et le WAR sont tous deux téléchargeables, nous n'avons donc pas à nous soucier de mettre le JAR dans un dossier lib .

L'adresse URL de notre JAR final est codée en dur dans le fichier JNLP, ce qui peut entraîner des problèmes de distribution. Si nous changeons de serveurs de déploiement, l'application ne fonctionnera plus.

Corrigeons cela avec un servlet approprié plus loin dans cet article. Pour l'instant, plaçons simplement le fichier JAR à télécharger dans le dossier racine en tant que index.html , et lions-le à un élément d'ancrage:

Launch

Définissons également la classe principale dans notre manifeste JAR . Cela peut être réalisé en configurant le plugin JAR dans le fichier pom.xml . De même, nous déplaçons le fichier JAR en dehors de WEB-INF / lib , car il est destiné au téléchargement uniquement, c'est-à-dire pas au chargeur de classe:

 org.apache.maven.plugins maven-jar-plugin ...   compile  jar      com.example.Hello     ${project.basedir}/target/jws     

4. Configurations spéciales

4.1. Les problèmes de sécurité

Pour exécuter une application, nous devons signer le JAR . La création d'un certificat valide et l'utilisation du plug-in JAR Sign Maven va au-delà de la portée de cet article, mais nous pouvons contourner cette politique de sécurité à des fins de développement, ou si nous avons un accès administratif à l'ordinateur de notre utilisateur.

Pour ce faire, nous devons ajouter l'URL locale (par exemple: // localhost: 8080 ) à la liste des exceptions de sécurité de l'installation JRE sur l'ordinateur sur lequel l'application sera exécutée. Il peut être trouvé en ouvrant le panneau de configuration Java (sous Windows, nous pouvons le trouver via le panneau de configuration) dans l'onglet Sécurité.

5. Le JnlpDownloadServlet

5.1. Algorithmes de compression

Il existe un servlet spécial qui peut être inclus dans notre WAR. Il optimise le téléchargement en recherchant la version compilée la plus compressée de notre fichier JAR si disponible, et corrige également la valeur de base de code codée en dur sur le fichier JLNP.

Puisque notre JAR sera disponible au téléchargement, il est conseillé de le conditionner avec un algorithme de compression, tel que Pack200, et de fournir le JAR normal et toute version compressée JAR.PACK.GZ ou JAR.GZ dans le même dossier afin que ce servlet puisse choisissez la meilleure option pour chaque cas.

Malheureusement, il n'existe pas encore de version stable d'un plugin Maven pour cet algorithme de compression, mais nous pouvons travailler avec l'exécutable Pack200 fourni avec le JRE (généralement installé sur le chemin {JAVA_SDK_HOME} / jre / bin / ).

Sans changer notre JNLP et en plaçant les versions jar.gz et jar.pack.gz du JAR dans le même dossier, le servlet choisit le meilleur une fois qu'il reçoit un appel d'un JNLP distant. Cela améliore l'expérience utilisateur et optimise le trafic réseau.

5.2. Substitution dynamique de base de code

Le servlet peut également effectuer des substitutions dynamiques pour les URL codées en dur dans le marque. En remplaçant le JNLP par le caractère générique, il délivre le même tag final rendu.

Le servlet fonctionne également avec les caractères génériques $$ codebase , $$ hostname , $$ name et $$ site , qui résoudront " // localhost: 8080 / jnlp-example / ", " localhost: 8080 ", " hello.jnlp " et « // localhost: 8080 » respectivement.

5.3. Ajout du servlet au chemin de classe

Pour ajouter le servlet, configurons un mappage de servlet normal pour les modèles JAR et JNLP à notre web.xml :

 JnlpDownloadServlet  jnlp.sample.servlet.JnlpDownloadServlet    JnlpDownloadServlet *.jar   JnlpDownloadServlet *.jnlp 

Le servlet lui-même est fourni dans un ensemble de JAR ( jardiff.jar et jnlp-servlet.jar ) qui se trouvent actuellement dans la section Démos et exemples de la page de téléchargement du SDK Java.

Dans l'exemple GitHub, ces fichiers sont inclus dans le dossier java-core-samples-lib et sont inclus en tant que ressources Web par le plugin Maven WAR:

 org.apache.maven.plugins maven-war-plugin ...     ${project.basedir}/java-core-samples-lib/   **/*.jar  WEB-INF/lib    

6. Réflexions finales

Java Web Start est un outil qui peut être utilisé dans des environnements (intranet) où il n'y a pas de serveur d'applications. Aussi, pour les applications qui doivent manipuler des fichiers utilisateur locaux.

Une application est livrée à l'utilisateur final par un simple protocole de téléchargement, sans dépendance ni configuration supplémentaire, à l'exception de certains problèmes de sécurité (HTTPS, JAR signé, etc.).

Dans l'exemple Git, le code source complet décrit dans cet article est disponible en téléchargement. Nous pouvons le télécharger directement depuis GitHub vers un OS avec Tomcat et Apache Maven. Après le téléchargement, nous devons exécuter la commande mvn install à partir du répertoire source et copier le fichier jws.war généré de la cible vers le dossier webapps de l'installation Tomcat.

Après cela, nous pouvons démarrer Tomcat comme d'habitude.

À partir d'une installation par défaut d'Apache Tomcat, l'exemple sera disponible à l'URL //localhost:8080/jws/index.html .