Réglages du mode avancé de Protector4J

Le mode avancé permet de fixer soi-même l'étendue de la protection, les options de compatibilité et les options propres à chaque type d'application. La première fois que vous traitez une nouvelle application, commencez par le mode simple, ou lancez une analyse de compatibilité depuis la page des options avancées et ajustez à partir de son résultat.

Cette page développe la section consacrée au mode avancé du Guide de l'interface graphique. Pour décider quelles classes laisser sans protection, consultez Compatibilité et étendue de la protection ; pour écrire la commande automatisée équivalente, la Référence de la ligne de commande.

1. Passer en mode avancé

1. Choisissez le type d'application et le JAR ou WAR d'entrée.
2. Choisissez la version de Java à embarquer et au moins une plate-forme cible.
3. Dans Mode, sélectionnez Avancé — personnalisez les options vous-même.
4. Cliquez sur Suivant pour ouvrir la page des options avancées.

Si vous êtes déjà sur la page de vérification de la sortie, cliquez sur Personnaliser... pour revenir aux options avancées. Après vos modifications, retournez à la page de sortie et vérifiez que le récapitulatif les reflète.

La version de Java et les plates-formes cibles ne se modifient pas depuis la page des options avancées ; revenez pour cela à la page d'entrée. Une tâche multi-plates-formes produit une sortie distincte par plate-forme, et leurs répertoires vlxjre ne sont pas interchangeables.

2. Options communes

Les quatre types d'application partagent cette section, même si certains réglages ne concernent que certains types. Le chiffrement de la bibliothèque ne produit pas de scripts de démarrage et n'a donc pas d'options JVM ; son réglage de suffixe sert à proposer et harmoniser le nom du fichier de sortie.

Les options propres à chaque type :

« Aucune exclusion » signifie que toutes les classes d'application de ce type sont protégées par défaut. Cela ne veut pas dire que les dépendances tierces le sont aussi : BOOT-INF/lib pour Spring Boot et WEB-INF/lib pour Tomcat restent hors protection.

Suffixe d'archive

Choisir jar ne change que le nom ; le contenu reste du P4JX. Il ne s'ouvre pas avec les outils ZIP ou JAR ordinaires et ne se charge pas dans un JRE standard. Pour le chiffrement de la bibliothèque, ce réglage bascule le suffixe du fichier de sortie entre .p4jx et .jar ; si vous saisissez vous-même un autre suffixe, votre nom de fichier est conservé.

Option équivalente :

--archive-suffix p4jx
--archive-suffix jar

Désactiver le JIT pour les méthodes protégées

Désactiver le JIT pour les méthodes protégées tient ces méthodes à l'écart du compilateur JIT, ce qui réduit la quantité de code machine compilé exposé. Le code de calcul intensif peut en pâtir sensiblement. Ce réglage ne concerne que les méthodes protégées et ne bascule pas toute la JVM en mode interprété.

Option équivalente :

--no-jit

Superposition ZIP pour scanners

La superposition n'expose que des ressources publiques, des répertoires et les ébauches de métadonnées des classes protégées — jamais le corps réel des méthodes. Elle existe pour que les outils lisant directement le répertoire central du ZIP continuent de fonctionner. Elle ne remplace pas la disposition fat de Spring Boot et n'aide pas lorsqu'une archive est analysée depuis un flux mémoire avec ZipInputStream ou JarInputStream.

Option équivalente :

--zip-overlay scanner

Options de démarrage JVM

Saisissez une option complète par ligne, par exemple :

-Xms512m
-Xmx2g
-Dfile.encoding=UTF-8

Chaque ligne est une option : n'en mettez jamais deux sur la même. Les options sont écrites dans les scripts de démarrage macOS, Linux et Windows, et pour Tomcat également sur son chemin de démarrage. Le chiffrement de la bibliothèque ne produit pas de scripts de démarrage : le champ y est désactivé. Des exemples plus complets par plate-forme figurent dans Options de démarrage JVM.

En ligne de commande, l'option se répète :

--jvm-option -Xms512m --jvm-option -Xmx2g

3. L'analyse de compatibilité et ses recommandations

Pour les quatre types, Analyse de compatibilité... examine l'entrée courante. Si vous acceptez le résultat, l'outil intègre à vos réglages les recommandations propres à ce type, principalement :

• ajouter des classes qui devraient rester sans protection ;
• activer la superposition ZIP pour scanners ;
• ajuster le suffixe d'archive ;
• activer JavaFX et WebView pour une application Java ou Spring Boot ;
• choisir la disposition pour Spring Boot ;
• choisir Tomcat 9 ou 10.1.

Le chiffrement de la bibliothèque n'applique que les recommandations de superposition ZIP et de suffixe. Il est conçu pour protéger toutes les classes du JAR d'entrée et n'accepte pas d'exclusions : si l'analyse trouve quelque chose qui doit rester sans protection — classes JNI ou natives, par exemple —, le rapport vous invite à déplacer ces classes dans un JAR ordinaire ou à passer à un mode d'empaquetage acceptant la protection sélective.

Après avoir accepté les recommandations, vous pouvez continuer à modifier. L'analyse conserve les règles d'exclusion déjà en place et ne désactive pas un JavaFX que vous avez activé simplement parce qu'elle n'en a pas détecté. Annuler la boîte de dialogue n'applique rien.

Les risques au niveau du code signalés dans le rapport — agents, JNI, chargeurs de classes maison, bytecode modifié à l'exécution — ne se règlent généralement pas en changeant un réglage. Servez-vous de Compatibilité et étendue de la protection pour déplacer les frontières de votre code, puis testez pour de bon.

4. Options de l'application Java

Classe principale

Laissée vide, la Main-Class est lue dans le manifeste du JAR d'entrée. Ne saisissez un nom de classe complet que si le manifeste n'a pas de classe principale ou si vous voulez la remplacer — par exemple com.example.Main.

Option équivalente : --main com.example.Main.

Classes à exclure

Par défaut, toutes les classes de l'application sont protégées. Les classes et paquets listés ici restent sans protection, ce qui convient aux DTO, aux entités, aux classes de configuration, aux classes passerelles JNI et à tout ce qu'un framework améliore ou qui doit lire son propre bytecode réel. La syntaxe est décrite plus bas, dans « Étendue de la protection et règles d'exclusion ».

Runtime JavaFX

Pour une application JavaFX simple, cochez Inclure JavaFX dans le runtime empaqueté. Pour WebView, trois choix :

• Automatique (détecter javafx.scene.web) : inclus seulement si javafx.scene.web est détecté ;
• Inclure : intègre toujours fx-webkit ;
• Exclure : ne l'intègre jamais.

WebView ajoute environ 40 Mo. L'interface télécharge les composants correspondant à votre version de Java et à votre plate-forme cible ; pour désigner un répertoire JavaFX local, passez par la ligne de commande.

Options équivalentes : --javafx, --javafx-webview, --no-javafx-webview. Automatique n'a pas d'option propre, car l'empaqueteur décide d'après les références de l'application elle-même.

5. Options de Spring Boot

Classe principale

Laissée vide, Start-Class est lue dans le manifeste. Saisissez un nom de classe complet pour la remplacer.

Option équivalente : --main com.example.Application.

Disposition

Si l'analyse recommande clairement fat, ne forcez pas p4jx-fat en espérant que la superposition ZIP compense. Les détails de chaque disposition figurent dans Protéger les applications Spring Boot.

Options équivalentes : --layout p4jx-fat, --layout fat, --layout separate.

Protéger les JAR de dépendances…

Les dépendances de BOOT-INF/lib ne sont pas protégées par défaut. Ne retenez que vos propres dépendances à code fermé ; ne chiffrez pas les paquets de frameworks tiers comme Spring, Tomcat, les bibliothèques de journalisation ou les pilotes de bases de données. Les JAR signés ne peuvent pas être sélectionnés, car les modifier romprait leur signature.

Retenir une dépendance protège toutes ses classes, mais vous pouvez toujours vous servir de Classes à exclure pour en laisser certaines sans protection. Les trois dispositions Spring Boot acceptent la protection des dépendances.

Option équivalente : --protect-lib 'company-core.jar,company-domain.jar'. La ligne de commande accepte également des motifs glob ; l'interface enregistre les noms exacts des JAR retenus.

Classes à exclure et JavaFX

Le fonctionnement est identique à celui d'une application Java. Les règles d'exclusion s'appliquent aussi bien aux classes de l'application qu'aux JAR de dépendances retenus pour protection. Une application de bureau Spring Boot peut elle aussi intégrer JavaFX et WebView depuis l'onglet Runtime JavaFX.

6. Options de Tomcat

Version de Tomcat

• Si le WAR utilise javax.servlet.*, choisissez Tomcat 9 · javax.
• S'il utilise jakarta.servlet.*, choisissez Tomcat 10.1 · jakarta.

Tomcat 10.1 exige Java 11 ou une version ultérieure. En cas de doute, lancez une analyse de compatibilité. Si l'application emploie à la fois javax et jakarta, ne forcez pas de version : réglez d'abord le conflit de dépendances.

Le mode avancé ne présélectionne aucune version : il faut accepter la recommandation de l'analyse ou en choisir une pour continuer. Options équivalentes : --tomcat-version 9 ou --tomcat-version 10 ; la ligne de commande accepte aussi auto.

Chemin de contexte

Saisissez le chemin de déploiement en commençant par /, par exemple /app. Laissé vide, /app est employé. Lors de l'ajout d'une application à un répertoire de sortie Tomcat existant, le chemin ne doit pas entrer en conflit avec une application déjà présente.

Option équivalente : --context /app.

Classes à exclure

Par défaut, les classes d'application situées sous WEB-INF/classes sont protégées, et WEB-INF/lib ne l'est pas. Servlets, filtres, écouteurs, DTO, classes de configuration, entités, classes passerelles JNI et tout ce que le conteneur doit améliorer sont normalement à exclure.

7. Étendue de la protection et règles d'exclusion

En mode avancé, l'interface protège par défaut toutes les classes de l'application, et vous tracez la frontière avec le framework grâce à Classes à exclure. Trois formes de règles sont acceptées :

com.example.SecretService   cette classe uniquement
com.example.service.*       ce paquet uniquement, sans les sous-paquets
com.example.service.**      ce paquet et tous ses sous-paquets

Choisissez des classes dans l'arborescence avec Choisir..., ou saisissez-les avec Ajouter.... Sélectionner un paquet couvre par défaut ses sous-paquets ; .* limite au paquet lui-même. Pour Spring Boot, l'arborescence affiche aussi les JAR de dépendances retenus pour protection.

L'agencement recommandé est le suivant : frontière publique ou entrée du framework → façade ou interface ordinaire → implémentation centrale protégée. Ne chiffrez pas toutes les dépendances tierces et tous les points d'entrée du framework dans le seul but d'élargir la surface protégée en apparence.

8. Exporter, réutiliser et vérifier une dernière fois

Exporter les paramètres... exporte un fichier de tâche p4j-task.yml modifiable à la main. Il consigne les options telles qu'elles ont été résolues, mais jamais l'adresse e-mail ni le mot de passe du compte. Vous pourrez rétablir la tâche ensuite avec Charger un fichier de tâche, en haut de la fenêtre ; cette même entrée lit toujours les p4j-encrypt-run.sh et .bat exportés par les versions précédentes.

Sur la page de sortie, vérifiez au minimum :

• le fichier d'entrée, le type d'application, la version de Java et toutes les plates-formes cibles ;
• le suffixe d'archive, le réglage du JIT, la superposition pour scanners et les options JVM ;
• JavaFX et WebView, la disposition Spring Boot, ou la version de Tomcat et le chemin de contexte ;
• les JAR de dépendances retenus pour protection et toutes les règles d'exclusion ;
• le répertoire de sortie et la création éventuelle d'un sous-répertoire p4jx-xxxx.

Une fois le paquet produit, utilisez son script de démarrage sur chaque plate-forme cible pour vérifier le démarrage, le balayage du framework, la sérialisation, la réflexion, le chargement des ressources et vos parcours métier essentiels. Des options avancées correctement réglées signifient seulement que la tâche était bien configurée : cela ne remplace pas la vérification du produit fini.