Änderungsprotokoll

6.0.19 2026-08-15

Deutlicherer Hinweis auf die Testlizenz beim Verschlüsseln ohne Konto

• Wenn keine Kontoanmeldedaten angegeben sind, sagt die CLI-Warnung jetzt klar, dass die geschützte Anwendung eine Testlizenz verwendet und nur 7 Tage lang läuft, und verweist für den Lizenzkauf auf https://protector4j.com. Zuvor erwähnte die Warnung nur „eine Testlizenz", ohne zu erklären, was das für die Anwendung bedeutet.
• Die GUI zeigt denselben Hinweis vor dem Start der Verschlüsselung in einem Dialog mit drei Auswahlmöglichkeiten: Kaufen, Aufgabe fortsetzen und Aufgabe abbrechen. Die Kaufen-Schaltfläche öffnet die Kaufseite der aktuell gewählten Serverregion, sodass Nutzer der .cn-Region nicht auf die .com-Seite geleitet werden.

Startargumente zum Öffnen der GUI aus anderen Werkzeugen

• Die GUI akzeptiert jetzt Startargumente: p4j-ui [--task-file <file>] [<input-file>]. Eine Aufgabendatei durchläuft den normalen Importablauf direkt bis zur abschließenden Bestätigungsseite. Ein einfacher Eingabepfad wird in eine neue Aufgabe vorausgefüllt: Eine .war-Datei wählt automatisch den Tomcat-Ablauf, während eine .jar-Datei auf der Seite zur Auswahl des Anwendungstyps stehen bleibt, denn ein JAR kann eine Java-Anwendung, eine Spring-Boot-Anwendung oder eine Bibliothek sein. Dies ist die Integrationsschnittstelle für externe Werkzeuge wie IDE-Plugins; unbekannte Argumente mit Bindestrich werden ignoriert, sodass sich der Start der GUI ohne Argumente exakt wie bisher verhält.

Eigenständige Bibliotheksverschlüsselung als in Entwicklung markiert

• Die eigenständige Bibliotheksverschlüsselung ist in der 6.x-Linie noch nicht verfügbar und wird jetzt klar als solche gekennzeichnet: Die entsprechende Karte in der GUI ist ausgegraut und trägt das Abzeichen „In Entwicklung", und der CLI-Befehl encode beendet sich mit einer erklärenden Meldung, statt eine Aufgabe zu starten. Die Funktion wird in einer künftigen Version bereitgestellt.

6.0.18 2026-08-13

Unterstützung für Multi-Release-JARs im Spring-Boot-Layout p4jx-fat

• Behoben: Im Spring-Boot-Layout p4jx-fat wurden Multi-Release-Abhängigkeiten stets aus ihrer Basisversion geladen. Beim Entpacken eines verschachtelten JARs aus BOOT-INF/lib legte der Klassenlader die Einträge unter ihren wörtlichen Namen ab, sodass Klassen unterhalb von META-INF/versions/ nie ausgewählt wurden und immer der Rückfall auf die Basisversion griff. Ein konkretes Symptom: Mit Spring Framework 7.0.5 wurde VirtualThreadDelegate auf den Stub der Basisversion aufgelöst, der bedingungslos eine UnsupportedOperationException wirft; eine Anwendung auf JDK 25 mit spring.threads.virtual.enabled=true startete deshalb nicht. Viele verbreitete Abhängigkeiten werden als Multi-Release-JARs ausgeliefert, sodass weitere versionsspezifische Codepfade genauso betroffen waren.
• Der Klassenlader löst Multi-Release-Einträge jetzt beim Laden auf und wählt die höchste Version, die das laufende JDK unterstützt. Der Packager wendet dieselbe Auflösung beim Aufbau des Fat-Ressourcenindex an, sodass Index und Klassenlader sich immer darüber einig sind, welcher Eintrag gewinnt. Die beiden anderen Layouts, fat und separate, waren nie betroffen, da sie Abhängigkeiten als gewöhnliche JAR-Dateien belassen, die die JVM selbst öffnet.

6.0.17 2026-08-13

Startfehler geschützter Anwendungen unter Windows-Pfaden mit Nicht-ASCII-Zeichen behoben

• Behoben: Geschützte Anwendungen starteten unter Windows nicht, wenn ihr Pfad Nicht-ASCII-Zeichen enthielt, etwa chinesische Schriftzeichen. Je nachdem, an welcher Stelle der Pfad falsch gelesen wurde, schlug der Start entweder mit dem Archivfehler E816 fehl oder mit einem Entschlüsselungsfehler, der als ClassFormatError auftrat. Die Laufzeitumgebung öffnete das Archiv und normalisierte Pfade byteweise, sodass ein in einer älteren Codepage kodiertes Zeichen, dessen zweites Byte zufällig 0x5C – der Backslash – ist, in der Mitte auseinandergerissen und dessen Rest als Verzeichnistrenner gelesen wurde. In GBK sind viele alltägliche chinesische Zeichen genau so kodiert. Pfade, die ausschließlich aus ASCII-Zeichen bestehen, waren nie betroffen.
• Unter Windows wandelt die Laufzeitumgebung Pfade jetzt über die ANSI-Codepage des Systems in Wide Characters um, bevor sie Dateien öffnet und bevor sie den Laufzeit-Fingerabdruck berechnet – genau so, wie das originale JDK Dateien seit jeher öffnet. Geändert wurde nur der Windows-Codepfad; Linux und macOS verhalten sich unverändert. Alle fünf JDK-Linien wurden mit der Korrektur neu gebaut: JDK 25, 21 und 17 auf VLX 1.0.22, JDK 11 auf VLX 1.0.20 und JDK 8 auf VLX 1.0.13.

6.0.16 2026-08-10

Behobenes Packaging unter Windows für Linux- und macOS-Ziele

• Ein Fehler beim Packaging unter Windows mit Linux oder macOS als Zielplattform wurde behoben. Beim Entpacken der mitgelieferten Runtime erschien Failed to extract P4JX runtime, obwohl die Runtime tatsächlich korrekt entpackt worden war. Unter Windows lassen sich symbolische Links nur mit erhöhten Rechten anlegen, und die Linux- und macOS-Runtimes enthalten unter legal/ etwas mehr als hundert davon — Lizenztexte, die jlink auf java.base verweist, statt sie zu duplizieren. Der mit Windows ausgelieferte Befehl tar behandelt das als Warnung, gibt aber dennoch einen Exit-Code ungleich null zurück, was der Encoder als endgültigen Fehlschlag las und die entpackte Runtime anschließend löschte. Packaging unter Windows für ein Windows-Ziel war nie betroffen, da die Windows-Runtimes überhaupt keine symbolischen Links enthalten.
• Die Archivverarbeitung hängt nicht mehr vom tar-Befehl der jeweiligen Plattform ab. Der Encoder liest und entpackt .tar.gz-Runtimes und JavaFX-Bestandteile nun selbst, sodass sich das Verhalten unter Windows, Linux und macOS identisch verhält. Dateiberechtigungen einschließlich des Ausführungsbits des Starters stammen aus dem Archiv selbst und nicht aus dem Dateisystem des Hosts. Unter Windows werden die Lizenz-Symlinks übersprungen: Sie haben keine Funktion zur Laufzeit und sind nicht Teil des Runtime-Fingerprints, sodass unter Windows geschützte Anwendungen genau wie bisher entschlüsselt werden.

6.0.15 2026-08-08

Korrekturen am Update-Dialog

• Der Dialog „Neue Version“ öffnet sich jetzt in einer festen, angemessenen Größe, anstatt bei einem langen Changelog den gesamten Bildschirm auszufüllen.
• In der Symbolleiste wurde „Nach Updates suchen“ hinzugefügt, sodass Sie jederzeit und nicht nur beim Start nach einer neueren Version suchen können.

6.0.14 2026-08-07

Inline-Verschlüsselung von String-Konstanten, jetzt Standard

• Ein Inline-String-Schutzmodus wurde hinzugefügt, der ldc-String-Ladebefehle in einen Aufruf einer synthetischen, klassenspezifischen Entschlüsselungsmethode umschreibt, sodass der Klartext einer String-Konstante vollständig aus dem Konstantenpool entfernt wird. Der Klartext gelangt beim Laden der Klasse nicht mehr in die SymbolTable, erscheint nur dann auf dem Heap, wenn dieser Code tatsächlich ausgeführt wird, und ungenutzte Strings bleiben verschlüsselt. Der Chiffretext wird im Klassenrumpf mitgeführt und durch die bestehende methodenweise Verschlüsselung geschützt. Dies ist eine reine encoderseitige Bytecode-Transformation: Archivformat und Laufzeit bleiben unverändert und es funktioniert auf jeder unterstützten JDK-Linie ohne Laufzeit-Update.
• Der String-Schutz ist jetzt eine einzige Option mit drei Modi – Keine, Standard (Konstantenpool V72) und Inline – und Inline ist die Voreinstellung für jeden Anwendungstyp, einschließlich Tomcat. Er wurde durchgängig an gewöhnlichen Servlets, String-switch-Geschäftslogik und JspC-vorkompilierten JSP-Servlet-Klassen validiert. Der CLI-Schalter lautet --encrypt-strings none|constant|inline, und die GUI bietet dieselbe Auswahl.
• Eine Methode, die nicht umgeschrieben werden kann – eine Schnittstelle in einem alten Klassendateiformat, eine Methode nahe der 64-KB-Grenze oder ein seltener Serialisierungs-Grenzfall – fällt auf die Standard-V72-Schicht zurück, sodass das Ergebnis nie schwächer als zuvor ist.

Schnellerer Start von Spring Boot p4jx-fat

• Der Pure-Fat-Spring-Boot-Klassenlader liest seinen verschachtelten Ressourcenindex jetzt bei Bedarf statt im Voraus und reduziert so den Startaufwand großer p4jx-fat-Anwendungen.

Kontoanmeldedaten aus Umgebungsvariablen

• Die Befehle encode, javaapp, springboot und tomcat sowie der Aufgabendatei-Modus können die Konto-E-Mail und das Passwort jetzt aus P4JX_ACCOUNT_EMAIL und P4JX_ACCOUNT_PASSWORD (oder P4JX_ACCOUNT_PASSWORD_MD5) lesen. Sie werden nur verwendet, wenn die entsprechende Befehlszeilenoption fehlt, sodass eine exportierte Aufgabendatei frei von Anmeldedaten bleibt.

6.0.13 2026-08-05

Startkorrektur für geschützte Anwendungen, die javax.lang.model verwenden

• NoClassDefFoundError: javax/lang/model/SourceVersion beim Start geschützter Anwendungen behoben, deren Frameworks die javax.lang.model-API referenzieren – allen voran Spring Data JPA, dessen Repository-AOT-processor während der Container-Initialisierung auf SourceVersion zugreift. Das Modul java.compiler, das zuvor aus der gebündelten Runtime entfernt worden war, ist nun wieder enthalten. Es ist ein reines API-Modul ohne Compiler-Implementierung, sodass ToolProvider.getSystemJavaCompiler() weiterhin null zurückgibt und jdk.compiler weiterhin fehlt – die Schutzoberfläche bleibt unverändert.
• Die Runtimes für JDK 17, 21 und 25 wurden auf VLX 1.0.21 und JDK 11 auf VLX 1.0.19 neu gebaut, alle mit dem wiederhergestellten Modul java.compiler. JDK 8 ist nicht betroffen, da es kein Modulsystem besitzt und diese Klassen bereits bereitstellt.

6.0.12 2026-08-02

Unterstützung für JxBrowser 9 und Absturzbehebung für geschützte Anwendungen, die eine NullPointerException auslösen

• Geschützte Anwendungen können jetzt JxBrowser 9 einbetten. --native-compat jxbrowser wählt eine der neun im Katalog enthaltenen Versionen von 9.0.0 bis 9.3.1 aus und deckt sieben Plattformen unter Java 17, 21 und 25 ab. Die Laufzeitumgebung erteilt die Thread-Attach-Berechtigung nur der offiziellen IPC-Bibliothek, deren SHA-256 für die gewählte Version hinterlegt ist, und prüft das aufrufende Modul erneut, sobald ein Thread tatsächlich attacht. Pfade, Hashes und Bibliotheksnamen werden niemals von der Kommandozeile übernommen. Verwenden Sie unter macOS 26 JxBrowser 9.0.1 oder neuer: TeamDev hat in dieser Version einen Chromium-Absturz beim Erstellen der Engine behoben, und 9.0.0 stürzt dort auch mit einem normalen JDK ab.
• ClassFormatError in geschützten Anwendungen behoben, die eine NullPointerException auslösen. Die Korrektur aus 6.0.9 unterdrückte die ausführliche NPE-Meldung der JVM pro Methode, was sich als unzureichend erwies: Diese Funktion analysiert Methodenrümpfe als Standard-Bytecode, und nach der Transformation durch P4JX kann kein Flag auf Methodenebene belegen, dass diese Analyse gültig bleibt. Die Laufzeitumgebung deaktiviert die ausführliche Meldung nun bedingungslos. Ausnahmetyp, Stacktrace und von der Anwendung gesetzte Meldungen bleiben unverändert. Die Laufzeitumgebungen für JDK 17, 21 und 25 wurden auf VLX 1.0.20 neu gebaut; JDK 11 ist nicht betroffen und bleibt bei VLX 1.0.18, JDK 8 bleibt bei VLX 1.0.12.
• java -version gibt jetzt den VLX-Laufzeit-Build aus, sodass sich eine mitgelieferte Laufzeitumgebung ohne Entpacken identifizieren lässt.
• Die beiden Versionsfelder für die Windows-EXE werden nun vor dem Start des Paketierens geprüft, statt mittendrin fehlzuschlagen. Windows speichert jede Komponente als vorzeichenlose 16-Bit-Ganzzahl, daher muss jede der ein bis vier durch Punkte getrennten Zahlen zwischen 0 und 65535 liegen. Leere Felder bedeuten weiterhin 0.0.0.0.

6.0.11 2026-07-27

Native Windows-Starter für geschützte Anwendungen

• Die optionale Erzeugung nativer Windows-EXE-Dateien wurde für Java-App-Pakete, alle drei Spring-Boot-Layouts und Tomcat-Pakete ergänzt. Konsolen- und GUI-Starter stehen für Windows x64, x86 und ARM64 bereit; die vorhandenen Startskripte bleiben in jedem Paket enthalten.
• CLI und GUI bieten neue Einstellungen für EXE-Dateiname, Modus, Symbol und Windows-Versionsmetadaten. Bei Aufgaben für mehrere Plattformen wird eine EXE nur für ausgewählte Windows-Ziele erzeugt. Die Einstellungen werden in Version 2 von p4j-task.yml gespeichert; Aufgabendateien der Version 1 bleiben lesbar.
• Der reine Win32-Starter JExeKit wurde mit der paketierten vlxjre, dem exakten Klassenpfad und den JVM-Argumenten integriert. Vor dem Java-Start lehnen die Starter Pfade außerhalb des Pakets, Ersetzungen über Reparse Points sowie unsichere Agent- oder Boot-Classpath-Optionen ab.
• JExeKit-Vorlagen werden ausschließlich als AES-GCM-verschlüsselte .jxt-Ressourcen eingebettet und zur Erzeugung nur im Arbeitsspeicher entschlüsselt. Jeder erzeugte Starter trägt eine Ed25519-Signatur mit Produktionsstatus über seinem Parameterblock; Änderungen an Symbol, Version, Manifest und Parametern sind vor der abschließenden Authenticode-Signatur des Benutzers abgeschlossen.

6.0.10 2026-07-27

Schnelleres Laden von Tomcat-Abhängigkeiten bei erhaltener WAR-Struktur

• Starke Verzögerungen beim Tomcat-Start wurden behoben. Zuvor wurde beim Laden jeder Klasse das gesamte geschützte, verschachtelte JAR unter WEB-INF/lib erneut gelesen und gehasht. VLX 1.0.17 prüft nun jedes versiegelte verschachtelte JAR nur einmal, speichert dessen authentifizierte Herkunft innerhalb der VM zwischen und gleicht weiterhin jede angeforderte Klasse mit dem verschlüsselten Klassenindex ab.
• Die vorübergehende Behelfslösung zum Entpacken und Einbinden von web-libs wurde entfernt. WEB-INF/lib/*.jar verbleibt im geschützten .p4jx-Archiv, wodurch die ursprüngliche WAR-Struktur und die Anwendungsisolierung erhalten bleiben. VLX-1.0.17-Laufzeiten wurden für JDK 11, 17, 21 und 25 in 24 unterstützten Plattformkombinationen veröffentlicht. JDK 8 behält seinen bisherigen ZIP-overlay-Pfad und verbleibt bei VLX 1.0.11.
• Die Kompatibilitätsprüfung für die anwendungseigene module-info.class wurde korrigiert. Moduldeskriptoren enthalten keine Methodenkörper und werden daher automatisch von der Verschlüsselung ausgeschlossen, bleiben für Deskriptorwerkzeuge jedoch lesbar.
• In von der GUI exportierten CLI-Befehlen können --java-version, --target-platform und --create-new-folder nun als zusammenhängender Suffix hinter den Packager-Argumenten angegeben werden. Die bisherige Präfixform wird weiterhin unterstützt.

6.0.9 2026-07-25

Absturzbehebung für verschlüsselte Anwendungen, die NullPointerExceptions ausgeben

• Ein JVM-Absturz wurde behoben, der auftreten konnte, wenn eine geschützte Methode eine implizite NullPointerException auslöste und die Anwendung deren Meldung las oder den Stacktrace ausgab. Die Funktion für "hilfreiche NPE-Details" der Laufzeit versuchte, den Text "because ... is null" aus dem verschlüsselten Bytecode der Methode zu rekonstruieren, griff dabei auf ungültigen Speicher zu und brachte die VM zum Absturz (beobachtet bei JavaFX-FXML-Anwendungen). Geschützte Methoden überspringen die Detailmeldung nun und fallen auf eine normale NullPointerException zurück; Ausnahmetyp, Stacktrace und eine von der Anwendung bereitgestellte Meldung bleiben unberührt.
• Die Laufzeiten für JDK 17, 21 und 25 wurden mit dieser Korrektur auf VLX 1.0.16 neu erstellt. JDK 11 ist nicht betroffen, da die Funktion für hilfreiche NPE-Details vor JDK 14 nicht existiert, und bleibt auf VLX 1.0.15; JDK 8 bleibt auf VLX 1.0.11.

6.0.8 2026-07-24

Bedarfsgeladene Tomcat-Laufzeiten und produktionssichere Standardwerte

• Ein Fehler wurde behoben, durch den der veröffentlichte selbstgeschützte Encoder keine Tomcat-WARs paketieren konnte, weil die Tomcat-Klassen in app.p4jx nicht mehr als physisches Klassenpfad-JAR sichtbar waren. Tomcat 9.0.107 und 10.1.53 werden nun als unveränderliche, versionierte R2/COS-Artefakte anhand des Servlet-Namensraums ausgewählt, bei der ersten Verwendung heruntergeladen, lokal zwischengespeichert und anhand eines exakten SHA-256-Werts sowie des JAR-Manifests geprüft. Manipulierte Cache-Dateien werden verworfen und erneut heruntergeladen.
• Öffentliche WEB-INF/lib-JARs werden jetzt pro Anwendung getrennt als hashgebundene physische Webressourcen bereitgestellt. Dadurch entfällt beim Spring-Start das wiederholte Lesen und Prüfen verschachtelter Archive für jede Klasse.
• Neue Builds verwenden nun standardmäßig den Produktionsendpunkt https://protector4j.com für Lizenzen. Der interne Endpunkt http://10.10.10.16:16002 wird nur verwendet, wenn P4JX_LICENSE_MODE=dev oder -PlicenseMode=dev ausdrücklich ausgewählt wurde.

6.0.7 2026-07-24

Verschachtelte Tomcat-Abhängigkeiten und vertrauenswürdige dynamische Klassen

• Fehler beim Laden von Klassen oder Diensten aus WEB-INF/lib/*.jar durch geschützte Tomcat-WARs wurden behoben. Protector4J versiegelt nun exakte SHA-256-Metadaten der verschachtelten JARs und Klassen in app.p4jx; unbekannte, ausgetauschte oder manipulierte Abhängigkeiten werden weiterhin abgelehnt.
• Fehler von Spring CGLIB und Hibernate Byte Buddy unter JDK 11 wurden behoben, die durch den JDK-11-spezifischen Quellmarker von MethodHandles.Lookup#defineClass entstanden. Dynamisches Vertrauen erfordert weiterhin eine von der VM geprüfte Herkunft der aufrufenden Klasse oder des Loaders; Marker-Zeichenketten, Klassennamen, Pfade, Paketnamen und CodeSource gewähren kein Vertrauen.
• VLX-1.0.15-Laufzeiten für JDK 11, 17, 21 und 25 wurden für 24 unterstützte Plattformkombinationen veröffentlicht. Alle haben die strengen L1-L5-Prüfungen bestanden, einschließlich echtem FXML, Swing/AWT, dem Laden verschachtelter Tomcat-Abhängigkeiten sowie negativen Herkunfts- und Manipulationsfällen. JDK 8 bleibt bei VLX 1.0.11.

6.0.6 2026-07-22

Vertrauenswürdige Herkunft für Klassendefinitionen

• Startfehler geschützter JavaFX-FXML-Anwendungen wurden behoben: MethodUtil definiert den von der VM geprüften Trampoline-Helfer über defineClass(byte[]). Vertrauen wird nun nur aus von der VM geprüfter Klassen- oder Loader-Herkunft weitergegeben, nicht aus Klassennamen, Pfaden, Paketnamen oder CodeSource-Zeichenketten.
• Es wurde echte FXML-Abdeckung mit fx:controller, Property-Elementen, Controller-Injektion und WebView-Start ergänzt, außerdem Regressionen für vertrauenswürdige dynamische Definitionen, zweistufige Weitergabe, unbekannte Quellen, nicht autorisierte JARs und den Austausch von protected class-Namen.
• VLX 1.0.14-Laufzeiten für JDK 11, 17, 21 und 25 wurden veröffentlicht. JDK 8 bleibt bei VLX 1.0.11.

6.0.5 2026-07-21

Integrität der nativen JavaFX-Laufzeit

• Startfehler von JavaFX WebView unter Windows (Graphics Device initialization failed / No toolkit found) wurden behoben, indem die paketierten JavaFX-DLLs in vlxjre/bin abgelegt und die Suche des Launchers nach nativen Bibliotheken angepasst wurde.
• Die verschlüsselte Allowlist in app.p4jx wurde auf externe native Bibliotheken erweitert. Native JavaFX-Dateien müssen unabhängig vom Pfad exakt den SHA-256-Werten entsprechen, und Glass überprüft die tatsächlich geladene Datei erneut; unbekannte oder manipulierte Dateien werden abgelehnt.
• Aktualisierte Protector4J-Laufzeiten für JDK 11, 17, 21 und 25 wurden veröffentlicht. Die unterstützten JavaFX-Plattformkombinationen haben L5.1-L5.4 bestanden; geprüft wurden der WebView-Start sowie die Ablehnung manipulierter Modul-JARs, jdk.jsobject und nativer Glass-Bibliotheken.

6.0.4 2026-07-21

Integrität externer Module und JavaFX-Laufzeitkompatibilität

• Das pfadbasierte Vertrauen für externe Module wurde entfernt. Jedes externe Modul-JAR muss jetzt exakt mit einem in app.p4jx eingebetteten SHA-256-Allowlist-Eintrag übereinstimmen; unbekannte oder manipulierte Dateien werden unabhängig von ihrem Speicherort abgelehnt.
• Die automatische Erkennung der Abhängigkeitsauflösung aus JavaFX module-info.class sowie die kontrollierte Zulassung festgelegter JavaFX- und JDK-Module wurden hinzugefügt, einschließlich javafx.media und jdk.jsobject.
• JavaFX-WebView-Startfehler sowie E818- / ClassFormatError-Fehler nach dem Aufbau der Boot-Layer wurden mit den neu veröffentlichten P4JX-Laufzeitumgebungen für alle unterstützten JDK-Versionen und Plattformen behoben.

6.0.3 2026-07-20

Kompatibilität des JavaFX-WebView-Moduls

• Die Auflösung des optionalen Moduls jdk.jsobject wurde für unterstützte P4JX-Laufzeiten korrigiert, die aus derselben JDK/VLX-Version neu erstellt wurden. Eine kompatible Laufzeit wird nicht mehr allein deshalb abgelehnt, weil das vollständige lib/modules-Abbild andere Bytes enthält.
• Die Auswahl nach JDK-Reihe und Plattform, die exakte Prüfung von Modul-SHA-256 und Modulname sowie die erneute Prüfung des Abhängigkeitsabschlusses nach der Installation bleiben erhalten.

6.0.2 2026-07-20

JavaFX-WebView-Kompatibilität

• Startfehler von JavaFX WebView wurden behoben, indem javafx.media zusammen mit javafx.web paketiert und bei Bedarf das exakt zum P4JX-Laufzeitabbild passende Modul jdk.jsobject automatisch aufgelöst wird.
• Optionale Module können nun SHA-256-fixiert und an Version, Plattform und Laufzeit gebunden vom regionalen öffentlichen Download-Dienst geladen werden. Laufzeiten, die das Modul bereits enthalten, überspringen den Download.

6.0.1 2026-07-20

JavaFX-Kompatibilität

• Startfehler bei Fat JARs mit eingebetteten JavaFX-Laufzeitklassen wurden behoben. Die automatische Kompatibilitätsanwendung lässt nun die Namensräume der eingebetteten JavaFX-API, Implementierung und JNI-Brücke unverschlüsselt und vermeidet so eine doppelte Klassenzuordnung mit den paketierten JavaFX-Modulen.
• Die Kompatibilitätsdiagnose und die mehrsprachigen Hinweise für Anwendungen mit eingebetteten JavaFX-Laufzeiten wurden verbessert.

6.0.0 2026-07-20

Protector4J 6.0 ist ein Hauptrelease mit vollständig neu gestalteter Schutzarchitektur und kein gewöhnliches inkrementelles Update der 5.x-Reihe.

Architektur und Schutz

• Die grundlegende Architektur von Protector4J wurde neu gestaltet und die neue P4JX-Schutz-Engine eingeführt.
• Nahezu 100 Schutzmaßnahmen wurden über Archiverstellung, Klassenladen, Laufzeitausführung, Anti-Debugging und Artefaktintegrität hinweg ergänzt.
• Die Hürde für Reverse Engineering wurde erheblich erhöht. Die neue Architektur soll kurzfristiges Knacken selbst mit fortschrittlichen KI-gestützten Analysewerkzeugen äußerst schwierig machen.
• Lizenzanfragen, Runtime-Downloads, Artefaktprüfung und die Sicherheit plattformübergreifender Installationspakete wurden verstärkt.

Produkterlebnis

• JDK 8, 11, 17, 21 und 25 werden unterstützt, mit grafischen Paketierungsabläufen für Java-, JavaFX-, Spring Boot- und Tomcat-Anwendungen.
• Kompatibilitätsprüfung, selektive Klassenverschlüsselung, Schutz abhängiger JAR-Dateien, Import und Export von YAML-Aufgaben sowie Stapel-Builds für mehrere Zielplattformen wurden hinzugefügt.
• Die Desktop-Oberfläche wurde neu gestaltet und unterstützt 11 Sprachen sowie dauerhaft gespeicherte Spracheinstellungen.

Hinweise zur Migration

Protector4J 6.0 unterscheidet sich in der Verwendung deutlich von früheren Versionen. Lesen Sie vor der Verwendung bitte die aktuelle Dokumentation erneut und erstellen und migrieren Sie Ihre verschlüsselten Anwendungen möglichst bald mit 6.0 neu, um vom stärkeren Schutz zu profitieren.

Protector4J 6.0 herunterladen

Frühere Versionen