Journal des modifications

6.0.19 2026-08-15

Avertissement plus clair sur la licence d'essai lors du chiffrement sans compte

• Lorsqu'aucun identifiant de compte n'est fourni, l'avertissement de la CLI indique désormais clairement que l'application protégée utilisera une licence d'essai et ne s'exécutera que pendant 7 jours, et renvoie vers https://protector4j.com pour l'achat d'une licence. Auparavant, l'avertissement mentionnait seulement « une licence d'essai » sans expliquer ce que cela signifiait pour l'application.
• L'interface graphique affiche le même avertissement dans une boîte de dialogue avant le démarrage du chiffrement, avec trois choix : Acheter, Poursuivre la tâche et Annuler la tâche. Le bouton d'achat ouvre la page d'achat de la région serveur actuellement sélectionnée, de sorte que les utilisateurs de la région .cn ne sont pas renvoyés vers le site .com.

Arguments de démarrage pour lancer l'interface graphique depuis d'autres outils

• L'interface graphique accepte désormais des arguments de démarrage : p4j-ui [--task-file <file>] [<input-file>]. Un fichier de tâche suit le flux d'import habituel jusqu'à la page de confirmation finale. Un simple chemin d'entrée est prérempli dans une nouvelle tâche : un fichier .war sélectionne automatiquement le flux Tomcat, tandis qu'un fichier .jar s'arrête à la page de choix du type d'application, car un JAR peut être une application Java, une application Spring Boot ou une bibliothèque. C'est l'interface d'intégration destinée aux outils externes tels que les greffons d'IDE ; les arguments à tiret inconnus sont ignorés, de sorte que le lancement de l'interface graphique sans argument se comporte exactement comme avant.

Chiffrement de bibliothèque autonome marqué comme en développement

• Le chiffrement de bibliothèque autonome n'est pas encore disponible dans la ligne 6.x et est désormais clairement signalé comme tel : la carte correspondante de l'interface graphique est grisée avec le badge « En développement », et la commande CLI encode se termine avec un message explicatif au lieu de démarrer une tâche. Cette fonctionnalité sera proposée dans une prochaine version.

6.0.18 2026-08-13

Prise en charge des JAR multi-versions dans la disposition Spring Boot p4jx-fat

• Correction d'un problème où, dans la disposition Spring Boot p4jx-fat, les dépendances multi-versions étaient toujours chargées depuis leur version de base. Lors du dépaquetage d'un JAR imbriqué de BOOT-INF/lib, le chargeur de classes enregistrait les entrées sous leur nom littéral ; les classes situées sous META-INF/versions/ n'étaient donc jamais retenues et le repli sur la version de base s'appliquait systématiquement. Symptôme concret : avec Spring Framework 7.0.5, VirtualThreadDelegate était résolu vers le stub de la version de base, qui lève inconditionnellement une UnsupportedOperationException ; une application exécutée sur JDK 25 avec spring.threads.virtual.enabled=true ne démarrait donc pas. De nombreuses dépendances très répandues sont livrées sous forme de JAR multi-versions, si bien que d'autres chemins de code spécifiques à une version étaient touchés de la même manière.
• Le chargeur de classes résout désormais les entrées multi-versions au chargement, en retenant la version la plus élevée prise en charge par le JDK en cours d'exécution, et l'empaqueteur applique la même résolution lorsqu'il construit l'index de ressources fat, de sorte que l'index et le chargeur s'accordent toujours sur l'entrée retenue. Les deux autres dispositions, fat et separate, n'ont jamais été concernées : elles conservent les dépendances sous forme de fichiers JAR ordinaires que la JVM ouvre elle-même.

6.0.17 2026-08-13

Correction du démarrage des applications protégées sous des chemins Windows contenant des caractères non ASCII

• Correction d'un problème empêchant les applications protégées de démarrer sous Windows lorsque leur chemin contenait des caractères non ASCII, par exemple chinois. Selon l'endroit où le chemin était mal interprété, le démarrage échouait soit avec l'erreur d'archive E816, soit avec un échec de déchiffrement se manifestant par un ClassFormatError. Le runtime ouvrait l'archive et normalisait les chemins octet par octet ; un caractère codé dans une page de codes héritée dont le deuxième octet vaut justement 0x5C — la barre oblique inverse — était donc coupé en deux, et sa fin était lue comme un séparateur de répertoire. En GBK, de nombreux caractères chinois courants sont codés ainsi. Les chemins composés uniquement de caractères ASCII n'ont jamais été affectés.
• Sous Windows, le runtime convertit désormais les chemins en caractères larges via la page de codes ANSI du système avant d'ouvrir les fichiers et avant de calculer l'empreinte du runtime, exactement comme le JDK d'origine ouvre les fichiers depuis toujours. Seul le chemin de code Windows a changé ; Linux et macOS se comportent comme auparavant. Les cinq lignes JDK ont été reconstruites avec ce correctif : JDK 25, 21 et 17 en VLX 1.0.22, JDK 11 en VLX 1.0.20 et JDK 8 en VLX 1.0.13.

6.0.16 2026-08-10

Correction de l'empaquetage sous Windows pour les cibles Linux et macOS

• Correction d'un échec d'empaquetage sous Windows lorsque la plateforme cible est Linux ou macOS. L'extraction du runtime fourni signalait Failed to extract P4JX runtime alors que le runtime avait en réalité été extrait correctement. Windows ne peut pas créer de liens symboliques sans élévation de privilèges, et les runtimes Linux et macOS en contiennent un peu plus d'une centaine sous legal/ — des textes de licence que jlink fait pointer vers java.base au lieu de les dupliquer. La commande tar livrée avec Windows traite cela comme un avertissement mais renvoie tout de même un code de sortie non nul, que l'encodeur interprétait comme un échec définitif avant de supprimer le runtime extrait. L'empaquetage sous Windows pour une cible Windows n'a jamais été affecté, car les runtimes Windows ne contiennent aucun lien symbolique.
• Le traitement des archives ne dépend plus de la commande tar de la plateforme. L'encodeur lit et extrait désormais lui-même les runtimes .tar.gz et les ressources JavaFX, ce qui rend le comportement identique sous Windows, Linux et macOS. Les permissions des fichiers, y compris le bit d'exécution du lanceur, proviennent de l'archive elle-même et non du système de fichiers hôte. Sous Windows, les liens symboliques de licence sont ignorés : ils n'ont aucune fonction à l'exécution et ne font pas partie de l'empreinte du runtime, si bien que les applications protégées sous Windows se déchiffrent exactement comme avant.

6.0.15 2026-08-08

Corrections de la boîte de dialogue de mise à jour

• La boîte de dialogue « Nouvelle version » s’ouvre désormais à une taille fixe et raisonnable au lieu de s’étendre sur tout l’écran lorsque le journal des modifications est long.
• Ajout de « Rechercher des mises à jour » dans la barre d’outils, pour vérifier à tout moment la présence d’une nouvelle version, et pas seulement au démarrage.

6.0.14 2026-08-07

Chiffrement inline des constantes de chaîne, désormais par défaut

• Un mode de protection des chaînes en inline a été ajouté : il réécrit les instructions ldc de chargement de chaîne en un appel à une méthode de déchiffrement synthétique propre à la classe, ce qui retire entièrement du pool de constantes le texte en clair d'une constante de chaîne. Le texte en clair n'entre plus dans la SymbolTable au chargement de la classe, n'apparaît sur le tas que lorsque ce code s'exécute réellement, et les chaînes inutilisées restent chiffrées. Le texte chiffré voyage dans le corps de la classe et est couvert par le chiffrement par méthode existant. Il s'agit d'une transformation de bytecode purement côté encodeur : le format d'archive et le runtime restent inchangés et cela fonctionne sur chaque ligne JDK prise en charge sans mise à jour du runtime.
• La protection des chaînes est désormais une option unique à trois modes — Aucun, Standard (pool de constantes V72) et Inline — et Inline est la valeur par défaut pour chaque type d'application, y compris Tomcat. Elle a été validée de bout en bout sur des servlets ordinaires, de la logique métier à base de switch sur chaînes, et des classes de servlet JSP précompilées par JspC. L'option CLI est --encrypt-strings none|constant|inline, et l'interface graphique propose le même choix.
• Une méthode qui ne peut pas être réécrite — une interface dans un ancien format de fichier de classe, une méthode proche de la limite de 64 Ko, ou un cas limite rare de sérialisation — revient à la couche V72 standard, de sorte que le résultat n'est jamais plus faible qu'auparavant.

Démarrage plus rapide de Spring Boot p4jx-fat

• Le chargeur de classes Spring Boot en pure-fat lit désormais son index de ressources imbriquées à la demande plutôt que d'emblée, réduisant le travail de démarrage des grandes applications p4jx-fat.

Identifiants de compte depuis les variables d'environnement

• Les commandes encode, javaapp, springboot et tomcat ainsi que le mode fichier de tâche peuvent désormais lire l'e-mail et le mot de passe du compte depuis P4JX_ACCOUNT_EMAIL et P4JX_ACCOUNT_PASSWORD (ou P4JX_ACCOUNT_PASSWORD_MD5), utilisés uniquement lorsque l'option de ligne de commande correspondante est absente, afin qu'un fichier de tâche exporté reste sans identifiants.

6.0.13 2026-08-05

Correction de démarrage pour les applications protégées qui utilisent javax.lang.model

• Correction de NoClassDefFoundError: javax/lang/model/SourceVersion au démarrage des applications protégées dont les frameworks référencent l'API javax.lang.model — notamment Spring Data JPA, dont le repository AOT processor accède à SourceVersion lors de l'initialisation du conteneur. Le module java.compiler, précédemment retiré du runtime fourni, est désormais de nouveau inclus. Il s'agit d'un module purement API sans implémentation de compilateur, si bien que ToolProvider.getSystemJavaCompiler() renvoie toujours null et que jdk.compiler reste absent — la surface de protection est inchangée.
• Les runtimes JDK 17, 21 et 25 sont reconstruits en VLX 1.0.21, et JDK 11 en VLX 1.0.19, tous porteurs du module java.compiler restauré. JDK 8 n'est pas concerné, car il n'a pas de système de modules et fournit déjà ces classes.

6.0.12 2026-08-02

Prise en charge de JxBrowser 9 et correction d'un plantage des applications protégées qui lèvent une NullPointerException

• Les applications protégées peuvent désormais intégrer JxBrowser 9. --native-compat jxbrowser sélectionne l'une des neuf versions du catalogue intégré, de 9.0.0 à 9.3.1, sur sept plateformes avec Java 17, 21 et 25. L'environnement d'exécution n'accorde l'autorisation d'attachement de thread qu'à la bibliothèque IPC officielle dont le SHA-256 est enregistré pour la version choisie, et vérifie à nouveau le module appelant au moment où un thread s'attache réellement. Les chemins, empreintes et noms de bibliothèque ne sont jamais acceptés depuis la ligne de commande. Sous macOS 26, utilisez JxBrowser 9.0.1 ou une version ultérieure : TeamDev y a corrigé un plantage de Chromium à la création du moteur, et 9.0.0 plante également sur un JDK ordinaire.
• Correction d'une ClassFormatError dans les applications protégées qui lèvent une NullPointerException. Le correctif de 6.0.9 supprimait le message NPE détaillé de la JVM méthode par méthode, ce qui s'est révélé insuffisant : cette fonction analyse le corps des méthodes comme du bytecode standard, et une fois que P4JX les a transformées, aucun indicateur par méthode ne peut garantir que cette analyse reste valide. L'environnement d'exécution désactive désormais ce message de manière inconditionnelle. Le type d'exception, la pile d'appels et tout message fourni par l'application restent inchangés. Les environnements d'exécution JDK 17, 21 et 25 sont reconstruits en VLX 1.0.20 ; JDK 11 n'est pas concerné et reste en VLX 1.0.18, JDK 8 reste en VLX 1.0.12.
• java -version indique maintenant la version de l'environnement d'exécution VLX, ce qui permet d'identifier l'environnement fourni sans le décompresser.
• Les deux champs de version de l'EXE Windows sont désormais validés avant le début de l'empaquetage, au lieu d'échouer en cours de route. Windows stocke chaque composant sous forme d'entier non signé sur 16 bits : chacun des un à quatre nombres séparés par des points doit donc être compris entre 0 et 65535. Laisser les champs vides signifie toujours 0.0.0.0.

6.0.11 2026-07-27

Lanceurs Windows natifs pour les applications protégées

• Ajout de la génération facultative d'EXE Windows natifs pour les packages Java App, les trois dispositions Spring Boot et les packages Tomcat. Des lanceurs console et GUI sont disponibles pour Windows x64, x86 et ARM64, tandis que les scripts de lancement existants restent présents dans chaque package.
• Ajout de réglages CLI et graphiques pour le nom du fichier EXE, le mode, l'icône et les métadonnées de version Windows. Les tâches multiplateformes ne génèrent un EXE que pour les cibles Windows sélectionnées, et les réglages sont conservés dans la version 2 de p4j-task.yml ; les fichiers de tâches de version 1 restent lisibles.
• Intégration du lanceur JExeKit entièrement Win32 avec le vlxjre fourni, le classpath exact et les arguments JVM. Avant de démarrer Java, les lanceurs refusent les chemins sortant du package, les substitutions par points d'analyse et les options non sûres d'agent ou de boot classpath.
• Les modèles JExeKit sont intégrés uniquement sous forme de ressources .jxt chiffrées par AES-GCM et ne sont déchiffrés qu'en mémoire lors de la génération. Chaque lanceur généré porte une signature Ed25519 de statut production sur son bloc de paramètres ; les modifications de l'icône, de la version, du manifeste et des paramètres sont terminées avant la signature Authenticode finale de l'utilisateur.

6.0.10 2026-07-27

Chargement plus rapide des dépendances Tomcat sans modifier la structure du WAR

• Correction de forts ralentissements au démarrage de Tomcat dus à la relecture et au calcul du hachage de l'intégralité d'un JAR imbriqué protégé sous WEB-INF/lib à chaque chargement de classe. VLX 1.0.17 vérifie désormais une seule fois chaque JAR imbriqué scellé, met en cache sa provenance authentifiée dans la VM et continue de valider chaque classe demandée par rapport à l'index de classes chiffré.
• Suppression de la solution provisoire qui extrayait et montait web-libs. Les fichiers WEB-INF/lib/*.jar restent dans l'archive .p4jx protégée, ce qui préserve la structure WAR d'origine et l'isolation des applications. Les runtimes VLX 1.0.17 pour JDK 11, 17, 21 et 25 sont publiés pour 24 combinaisons de plateformes prises en charge. JDK 8 conserve son chemin ZIP overlay existant et reste sur VLX 1.0.11.
• Correction de l'analyse de compatibilité du fichier module-info.class de l'application. Les descripteurs de module ne contiennent aucun corps de méthode ; ils sont donc automatiquement exclus du chiffrement tout en restant lisibles par les outils d'analyse de descripteurs.
• Les commandes CLI exportées par l'interface graphique peuvent désormais placer --java-version, --target-platform et --create-new-folder après les arguments du packager sous la forme d'un suffixe continu. La forme préfixée existante reste prise en charge.

6.0.9 2026-07-25

Correction d'un plantage pour les applications chiffrées affichant des NullPointerException

• Correction d'un plantage de la JVM pouvant survenir lorsqu'une méthode protégée levait une NullPointerException implicite et que l'application lisait son message ou affichait sa trace de pile. La fonction de « détail NPE utile » du runtime tentait de reconstruire le texte « because ... is null » à partir du bytecode chiffré de la méthode, accédait à une mémoire invalide et faisait planter la VM (observé avec des applications JavaFX FXML). Les méthodes protégées ignorent désormais ce message détaillé et reviennent à une NullPointerException standard ; le type d'exception, la trace de pile et tout message fourni par l'application ne sont pas affectés.
• Les runtimes pour JDK 17, 21 et 25 sont reconstruits en VLX 1.0.16 avec cette correction. JDK 11 n'est pas concerné car la fonction de NPE utile n'existe pas avant JDK 14 et reste en VLX 1.0.15 ; JDK 8 reste en VLX 1.0.11.

6.0.8 2026-07-24

Runtimes Tomcat téléchargés à la demande et valeurs par défaut sûres pour la production

• Correction de l'échec de l'encodeur autoprotégé publié lors de l'empaquetage des WAR Tomcat, car les classes Tomcat contenues dans app.p4jx n'étaient plus visibles comme un JAR physique du classpath. Tomcat 9.0.107 et 10.1.53 sont désormais des artefacts R2/COS immuables et versionnés, sélectionnés selon l'espace de noms Servlet, téléchargés à la première utilisation, mis en cache localement et vérifiés par rapport à un SHA-256 exact et au manifeste des JAR. Les caches altérés sont supprimés puis téléchargés de nouveau.
• Les JAR publics de WEB-INF/lib sont désormais déployés comme ressources Web physiques, isolées par application et liées par hachage. Spring n'a ainsi plus à relire et vérifier l'archive imbriquée pour chaque classe au démarrage.
• Les nouvelles compilations utilisent désormais par défaut le point de terminaison de licence de production https://protector4j.com. Le point de terminaison interne http://10.10.10.16:16002 n'est utilisé que si P4JX_LICENSE_MODE=dev ou -PlicenseMode=dev est explicitement sélectionné.

6.0.7 2026-07-24

Dépendances Tomcat imbriquées et classes dynamiques fiables

• Correction des échecs des WAR Tomcat protégés lors du chargement de classes ou de services depuis WEB-INF/lib/*.jar. Protector4J scelle désormais dans app.p4jx les métadonnées SHA-256 exactes des JAR et des classes imbriqués ; les dépendances inconnues, remplacées ou altérées restent rejetées.
• Correction des échecs de Spring CGLIB et Hibernate Byte Buddy sous JDK 11, causés par l'utilisation d'un marqueur de source propre à JDK 11 par MethodHandles.Lookup#defineClass. La confiance dynamique exige toujours une provenance de classe appelante ou de chargeur vérifiée par la VM ; les chaînes de marqueur, noms de classes, chemins, packages et CodeSource n'accordent aucune confiance.
• Publication des runtimes VLX 1.0.15 pour JDK 11, 17, 21 et 25 sur 24 combinaisons de plateformes prises en charge. Tous ont réussi les contrôles stricts L1-L5, notamment FXML réel, Swing/AWT, le chargement de dépendances Tomcat imbriquées et les cas négatifs de provenance et d'altération. JDK 8 reste en VLX 1.0.11.

6.0.6 2026-07-22

Provenance fiable des définitions de classes

• Correction des échecs de démarrage des applications JavaFX FXML protégées : MethodUtil définit son auxiliaire Trampoline, dont la provenance a été vérifiée par la VM, via defineClass(byte[]). La confiance ne se propage désormais qu'à partir de la provenance de classe ou de chargeur vérifiée par la VM, et non depuis les noms de classes, les chemins, les packages ou les chaînes CodeSource.
• Ajout d'une couverture FXML réelle avec fx:controller, éléments de propriété, injection du Controller et démarrage de WebView, ainsi que des régressions pour les définitions dynamiques fiables, la propagation à deux niveaux, les sources inconnues, les JAR non autorisés et le remplacement de noms protected class.
• Publication des runtimes VLX 1.0.14 pour JDK 11, 17, 21 et 25. JDK 8 reste en VLX 1.0.11.

6.0.5 2026-07-21

Intégrité de l'environnement d'exécution natif JavaFX

• Correction des échecs de démarrage de JavaFX WebView sous Windows (Graphics Device initialization failed / No toolkit found) en plaçant les DLL JavaFX empaquetées dans vlxjre/bin et en alignant la recherche de bibliothèques natives du lanceur.
• La liste d'autorisation chiffrée dans app.p4jx couvre désormais les bibliothèques natives externes. Les fichiers natifs JavaFX doivent correspondre aux valeurs SHA-256 exactes, quel que soit leur chemin, et Glass revérifie le fichier réellement chargé ; les fichiers inconnus ou altérés sont rejetés.
• Publication de nouveaux environnements d'exécution Protector4J pour JDK 11, 17, 21 et 25. Les combinaisons de plateformes JavaFX prises en charge ont réussi L5.1-L5.4, qui couvrent le démarrage de WebView et le rejet des modules JAR, de jdk.jsobject et des bibliothèques natives Glass altérés.

6.0.4 2026-07-21

Intégrité des modules externes et compatibilité du runtime JavaFX

• La confiance basée sur le chemin pour les modules externes a été supprimée. Chaque JAR de module externe doit désormais correspondre exactement à une entrée SHA-256 de la liste d’autorisation intégrée dans app.p4jx ; les fichiers non reconnus ou altérés sont rejetés quel que soit leur emplacement.
• La détection automatique de la fermeture des dépendances à partir de JavaFX module-info.class et l’admission contrôlée des modules JavaFX et JDK épinglés ont été ajoutées, notamment javafx.media et jdk.jsobject.
• Les problèmes de démarrage de JavaFX WebView ainsi que les erreurs E818 / ClassFormatError après la création de la couche de démarrage ont été corrigés sur les versions JDK et plateformes prises en charge grâce aux nouveaux runtimes P4JX.

6.0.3 2026-07-20

Compatibilité du module JavaFX WebView

• Correction de la résolution du module facultatif jdk.jsobject pour les runtimes P4JX pris en charge et reconstruits à partir de la même version JDK/VLX. Un runtime compatible n’est plus rejeté uniquement parce que l’image complète lib/modules contient des octets différents.
• La sélection des artefacts par série JDK et plateforme, la validation exacte du SHA-256 et du nom du module, ainsi que la revérification des dépendances après l’installation sont conservées.

6.0.2 2026-07-20

Compatibilité JavaFX WebView

• Correction des échecs de démarrage de JavaFX WebView en regroupant javafx.media avec javafx.web et en résolvant automatiquement le module jdk.jsobject correspondant exactement à P4JX lorsqu’il est absent d’un runtime allégé.
• Ajout du téléchargement de modules facultatifs, épinglés par SHA-256 et liés à la version, à la plateforme et au runtime, depuis le service public régional. Les runtimes qui contiennent déjà le module ignorent le téléchargement.

6.0.1 2026-07-20

Compatibilité JavaFX

• Correction des échecs de démarrage des fat JAR qui intègrent des classes du runtime JavaFX. L’application automatique des règles de compatibilité laisse désormais non chiffrés les espaces de noms de l’API, de l’implémentation et du pont JNI JavaFX intégrés, évitant ainsi une double attribution avec les modules JavaFX fournis.
• Amélioration des diagnostics de compatibilité et des conseils multilingues pour les applications intégrant un runtime JavaFX.

6.0.0 2026-07-20

Protector4J 6.0 est une version majeure reposant sur une architecture de protection entièrement repensée, et non une simple mise à jour incrémentale de la série 5.x.

Architecture et protection

• Refonte de l’architecture fondamentale de Protector4J et introduction du nouveau moteur de protection P4JX.
• Ajout de près de 100 mesures de protection couvrant la génération des archives, le chargement des classes, l’exécution, l’anti-débogage et l’intégrité des artefacts.
• Renforcement considérable de la résistance à la rétro-ingénierie. La nouvelle architecture vise à rendre le piratage à court terme extrêmement difficile, même avec des outils avancés d’analyse assistée par IA.
• Renforcement des demandes de licence, des téléchargements de runtimes, de la vérification des artefacts et de la sécurité des installateurs multiplateformes.

Expérience produit

• Prise en charge de JDK 8, 11, 17, 21 et 25, avec des processus graphiques de packaging pour les applications Java, JavaFX, Spring Boot et Tomcat.
• Ajout de l’analyse de compatibilité, du chiffrement sélectif des classes, de la protection des JAR de dépendances, de l’importation/exportation des tâches YAML et des générations par lots pour plusieurs plateformes cibles.
• Refonte de l’interface de bureau, désormais disponible en 11 langues avec mémorisation du choix de langue.

Notes de migration

L’utilisation de Protector4J 6.0 diffère sensiblement des versions précédentes. Avant de l’utiliser, consultez à nouveau la documentation la plus récente, puis reconstruisez et migrez dès que possible vos applications chiffrées vers la version 6.0 afin de bénéficier d’une protection renforcée.

Télécharger Protector4J 6.0

Versions précédentes