Protection des applications JavaFX

JavaFX peut être activé tant pour les applications Java classiques que pour les applications de bureau Spring Boot. Le runtime simplifié de P4JX ne comprend pas par défaut JavaFX, il doit donc être activé explicitement lors du packaging ou sur recommandation suite à une analyse de compatibilité.

1. Opérations GUI

  1. Pour les applications JavaFX classiques, sélectionnez Java Application sur la page de type d’application; pour les applications de bureau JavaFX utilisant un conteneur Spring, sélectionnez Spring Boot. Library Encryption ne génère qu’un archivage protégé et ne peut pas remplacer le packaging d’une application JavaFX.

    Choisissez Java Application ou Spring Boot

  2. Sélectionnez le JAR d’entrée, Version Java incluse et la plateforme cible, puis choisissez le mode simple ou le mode avancé. Les ressources JavaFX sont récupérées séparément pour chaque version de Java et chaque plateforme cible; les tâches multi-plateformes génèrent des fichiers de sortie indépendants les uns des autres.

    Sélectionnez l’entrée, la version Java, la plateforme cible et le mode

  3. Avec le mode simple, si le balayage de compatibilité détecte des références à javafx.* ou des dépendances JavaFX, il indiquera les raisons des ajustements dans les résultats du balayage et activera automatiquement JavaFX; en cas de détection de javafx.scene.web, WebView sera également inclus. Le balayage est une analyse heuristique statique; il convient de vérifier à nouveau le résumé concernant JavaFX une fois sur la page des résultats.

  4. Avec le mode avancé, cochez Bundle JavaFX into the packaged runtime dans l’onglet JavaFX runtime, puis sélectionnez une stratégie pour WebView:

    • Auto: Détermination automatique en fonction du fait que l’application fait ou non référence à javafx.scene.web ;
    • Include: inclusion obligatoire de WebView (fx-webkit);
    • Exclude: exclusion obligatoire de WebView.

    L’entrée pour une application Java ordinaire est la suivante:

    Sélectionnez le runtime JavaFX dans les paramètres avancés de l’application Java ordinaire

    Les applications de bureau Spring Boot utilisent l’onglet du même nom:

    Sélectionner le runtime JavaFX dans les paramètres avancés de Spring Boot

  5. Après avoir sélectionné le répertoire de sortie, vérifiez que JavaFX est indiqué comme intégré dans le résumé des paramètres et que l’état de WebView correspond aux attentes, puis cliquez sur Run protection. Une fois généré, utilisez le script de démarrage inclus dans le package pour valider les fenêtres, les FXML, les ressources CSS/images ainsi que WebView sur chaque plateforme cible.

Les ressources de WebView pèsent environ 40 MB; vous pouvez choisir Exclude pour réduire la taille du package lorsqu’elles ne sont pas utilisées. Les significations des autres paramètres dans l’interface avancée se trouvent dans Paramètres du mode avancé de Protector4J et Configuration de Spring Boot.

2. Obtention en ligne via CLI

p4j javaapp fx-app.jar dist --javafx

Spring Boot JavaFX:

p4j springboot fx-boot.jar dist --javafx

Inclusion ou exclusion obligatoire de WebView:

--javafx-webview
--no-javafx-webview

L’outil récupère les ressources correspondantes depuis les sites de téléchargement publics de la région actuelle, en fonction de la ligne de formation Java cible et de la plateforme. Aucune clé de stockage cloud n’a besoin d’être transmise au client, que ce soit pour le téléchargement de JavaFX ou de VLX JRE.

3. Ressources hors ligne

Le CLI prend en charge les dossiers locaux:

p4j javaapp fx-app.jar dist --javafx /opt/p4jx-fx

Le dossier peut contenir:

  • fx-core.tar.gz ainsi que fx-webkit.tar.gz facultatif; ou
  • Un arbre de fichiers JavaFX déplié, avec lib/ comme racine.

La GUI ne permet pas de sélectionner de dossier JavaFX local; utilisez le CLI pour les scénarios hors ligne.

4. FXML

Si l’application utilise FXMLLoader, l’analyse de compatibilité recommande d’activer le ZIP overlay du scanneur:

p4j javaapp fx-app.jar dist --javafx --zip-overlay scanner

Les ressources liées à FXML, la signature des contrôleurs ainsi que le balayage du framework nécessitent des tests de démarrage réels sur la plateforme cible.

5. Java 8 et Java 11+

  • Java 8 utilise jfxrt.jar/modèle de répertoire étendu; la génération de scripts n’exige généralement pas de paramètres de module.
  • Java 11+ utilise des JAR JavaFX modulaires; la génération de scripts définit automatiquement un module path spécifique ainsi que --add-modules.

Utilisez toujours les fichiers run.sh, run.command ou run.bat générés, et ne prenez pas l’intégralité de vlxjre/lib comme module path.

6. Détection automatique des limites

Le détecteur scanne ses propres références de classes et identifie JavaFX en se basant sur les noms des fichiers JAR dépendants. Il ne scanne pas en profondeur le bytecode de toutes les dépendances tierces afin d’éviter de confondre une intégration JavaFX optionnelle avec une utilisation réelle.

Si JavaFX est intégré de manière à ce que son nom ne soit pas reconnaissable au sein d’une dépendance, le balayage automatique peut manquer certains éléments; dans ce cas, utilisez explicitement --javafx.

7. Recommandations concernant le périmètre de protection

  • La question de savoir si les sous-classes de JavaFX Application, les contrôleurs FXML ainsi que les modèles d’attributs doivent faire l’objet d’une protection doit se baser sur les résultats obtenus après tests sur la version spécifique de Java cible.
  • Les classes de pontage permettant un accès direct JNI/native doivent rester des classes ordinaires.
  • Il convient d’abord utiliser le mode simple ou --compat-scan, puis de réaliser des tests de régression pour l’ouverture des fenêtres, le chargement des FXML, les ressources CSS/images, WebView ainsi que les bibliothèques natives de la plateforme.