Protector4J Erweiterte Moduseinstellungen

Im erweiterten Modus legen Sie Schutzumfang, Kompatibilitätsoptionen und die Optionen des jeweiligen Anwendungstyps von Hand fest. Beginnen Sie bei einer neuen Anwendung im einfachen Modus oder führen Sie auf der Seite mit den erweiterten Optionen zuerst einen Kompatibilitätsscan aus und passen Sie anhand des Ergebnisses an.

Diese Seite vertieft den Abschnitt zum erweiterten Modus aus dem GUI-Leitfaden. Welche Klassen ungeschützt bleiben sollten, beschreibt Kompatibilität und Schutzumfang; den passenden automatisierten Befehl finden Sie in der CLI-Referenz.

1. In den erweiterten Modus wechseln

1. Wählen Sie den Anwendungstyp und das Eingabe-JAR oder -WAR.
2. Wählen Sie die mitgelieferte Java-Version und mindestens eine Zielplattform.
3. Wählen Sie unter Modus die Option Erweitert – Optionen selbst anpassen.
4. Klicken Sie auf Weiter, um die Seite mit den erweiterten Optionen zu öffnen.

Sind Sie bereits auf der Seite zur Ausgabeprüfung, gelangen Sie über Anpassen… zurück zu den erweiterten Optionen. Kehren Sie nach den Änderungen zur Ausgabeseite zurück und prüfen Sie, ob die Zusammenfassung sie widerspiegelt.

Java-Version und Zielplattformen lassen sich auf der Seite mit den erweiterten Optionen nicht ändern; kehren Sie dafür zur Eingabeseite zurück. Eine Aufgabe mit mehreren Plattformen erzeugt je Plattform eine eigene Ausgabe, deren vlxjre-Verzeichnisse nicht austauschbar sind.

2. Allgemeine Optionen

Alle vier Anwendungstypen teilen sich diesen Bereich, einzelne Einstellungen gelten jedoch nur für bestimmte Typen. Die Bibliotheksverschlüsselung erzeugt keine Startskripte und hat daher keine JVM-Startoptionen; ihre Einstellung zum Archivsuffix dient dazu, den Ausgabedateinamen vorzuschlagen und abzugleichen.

Die typspezifischen Optionen:

„Keine Ausschlüsse“ bedeutet, dass alle Anwendungsklassen dieses Typs standardmäßig geschützt werden. Es heißt nicht, dass auch Abhängigkeiten von Dritten geschützt würden: BOOT-INF/lib bei Spring Boot und WEB-INF/lib bei Tomcat bleiben standardmäßig ungeschützt.

Archivsuffix

Mit jar ändert sich nur der Dateiname; der Inhalt bleibt P4JX. Er lässt sich weder mit gewöhnlichen ZIP- oder JAR-Werkzeugen öffnen noch von einer Standard-JRE laden. Bei der Bibliotheksverschlüsselung wechselt diese Einstellung das Suffix der Ausgabedatei zwischen .p4jx und .jar; geben Sie selbst ein anderes Suffix ein, bleibt Ihr Dateiname unverändert.

Entsprechende CLI-Option:

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

JIT für geschützte Methoden deaktivieren

JIT für geschützte Methoden deaktivieren hält geschützte Methoden vom JIT-Compiler fern und verringert so den Umfang des offengelegten kompilierten Maschinencodes. Rechenintensiver Code kann dadurch deutlich langsamer werden. Die Einstellung betrifft nur geschützte Methoden und versetzt nicht die gesamte JVM in den Interpretermodus.

Entsprechende CLI-Option:

--no-jit

Scanner-ZIP-Overlay

Das Overlay legt nur öffentliche Ressourcen, Verzeichnisse und die Metadaten-Stubs geschützter Klassen offen — niemals die echten Methodenrümpfe. Es existiert, damit Werkzeuge weiterhin funktionieren, die das ZIP-Zentralverzeichnis direkt lesen. Es ersetzt nicht das Spring-Boot-Layout fat und hilft nicht, wenn ein Archiv mit ZipInputStream oder JarInputStream aus einem Speicherstrom ausgewertet wird.

Entsprechende CLI-Option:

--zip-overlay scanner

JVM-Startoptionen

Tragen Sie eine vollständige Option pro Zeile ein, zum Beispiel:

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

Jede Zeile ist eine Option — schreiben Sie niemals zwei in dieselbe Zeile. Die Optionen werden in die Startskripte für macOS, Linux und Windows geschrieben, bei Tomcat zusätzlich auf dessen Startpfad. Die Bibliotheksverschlüsselung erzeugt keine Startskripte; dort ist das Feld deaktiviert. Ausführlichere Beispiele je Plattform finden Sie unter JVM-Startoptionen.

Auf der CLI wiederholen Sie die Option:

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

3. Kompatibilitätsscan und seine Empfehlungen

Für alle vier Anwendungstypen untersucht Kompatibilitätsscan… die aktuelle Eingabe. Übernehmen Sie das Ergebnis, führt das Werkzeug die für diesen Typ passenden Empfehlungen mit Ihren aktuellen Einstellungen zusammen, im Wesentlichen:

• Klassen ergänzen, die ungeschützt bleiben sollten;
• das Scanner-ZIP-Overlay aktivieren;
• das Archivsuffix anpassen;
• JavaFX und WebView für eine Java-Anwendung oder Spring Boot aktivieren;
• das Layout für Spring Boot wählen;
• Tomcat 9 oder 10.1 wählen.

Die Bibliotheksverschlüsselung übernimmt nur die Empfehlungen zu Scanner-ZIP-Overlay und Archivsuffix. Sie ist darauf ausgelegt, jede Klasse im Eingabe-JAR zu schützen, und unterstützt keine Ausschlüsse. Findet der Scan etwas, das ungeschützt bleiben muss — etwa JNI- oder native Klassen —, empfiehlt der Bericht, diese Klassen in ein gewöhnliches JAR zu verschieben oder auf einen Paketierungsmodus mit selektivem Schutz zu wechseln.

Nach dem Übernehmen der Empfehlungen können Sie weiter bearbeiten. Der Scan bewahrt Ihre bestehenden Ausschlussregeln und schaltet ein von Ihnen aktiviertes JavaFX nicht ab, nur weil er selbst kein JavaFX erkannt hat. Brechen Sie den Dialog ab, wird nichts übernommen.

Risiken auf Codeebene im Bericht — Agents, JNI, eigene Klassenlader, zur Laufzeit veränderter Bytecode — lassen sich in der Regel nicht durch das Umlegen eines Schalters beheben. Verschieben Sie mithilfe von Kompatibilität und Schutzumfang die Grenzen in Ihrem Code und testen Sie anschließend in der Praxis.

4. Optionen für Java-Anwendungen

Hauptklasse

Bleibt das Feld leer, wird Main-Class aus dem Manifest des Eingabe-JAR gelesen. Tragen Sie einen vollqualifizierten Klassennamen nur ein, wenn das Manifest keine Hauptklasse enthält oder Sie sie überschreiben wollen — etwa com.example.Main.

Entsprechende CLI-Option: --main com.example.Main.

Auszuschließende Klassen

Standardmäßig wird jede Anwendungsklasse geschützt. Die hier aufgeführten Klassen und Pakete bleiben ungeschützt. Das passt zu DTOs, Entitäten, Konfigurationsklassen, JNI-Brückenklassen und allem, was ein Framework erweitert oder das seinen eigenen echten Bytecode lesen muss. Die Syntax beschreibt der Abschnitt „Schutzumfang und Ausschlussregeln“ weiter unten.

JavaFX-Runtime

Aktivieren Sie für eine reine JavaFX-Anwendung JavaFX in die paketierte Runtime aufnehmen. Für WebView haben Sie die Wahl:

• Automatisch (javafx.scene.web erkennen): nur aufnehmen, wenn javafx.scene.web erkannt wird;
• Einbeziehen: fx-webkit immer aufnehmen;
• Ausschließen: nie aufnehmen.

WebView vergrößert das Paket um rund 40 MB. Die GUI lädt die Komponenten passend zu Ziel-Java-Version und Plattform herunter; für ein lokales Offline-JavaFX-Verzeichnis nutzen Sie die CLI.

Entsprechende CLI-Optionen: --javafx, --javafx-webview, --no-javafx-webview. Automatisch hat keine eigene Option, da der Packager anhand der Referenzen der Anwendung entscheidet.

5. Optionen für Spring Boot

Hauptklasse

Bleibt das Feld leer, wird Start-Class aus dem Manifest gelesen. Zum Überschreiben tragen Sie einen vollqualifizierten Klassennamen ein.

Entsprechende CLI-Option: --main com.example.Application.

Layout

Empfiehlt der Kompatibilitätsscan ausdrücklich fat, erzwingen Sie nicht p4jx-fat in der Hoffnung, das ZIP-Overlay gleiche das aus. Einzelheiten zu den Layouts stehen unter Spring-Boot-Anwendungen schützen.

Entsprechende CLI-Optionen: --layout p4jx-fat, --layout fat, --layout separate.

Abhängigkeits-JARs schützen…

Abhängigkeiten in BOOT-INF/lib sind standardmäßig ungeschützt. Wählen Sie nur Ihre eigenen Closed-Source-Abhängigkeiten aus; verschlüsseln Sie keine Framework-Pakete von Dritten wie Spring, Tomcat, Logging-Bibliotheken oder Datenbanktreiber. Signierte JARs lassen sich nicht auswählen, da eine Änderung ihre Signatur zerstören würde.

Wählen Sie eine Abhängigkeit aus, werden alle darin enthaltenen Klassen geschützt; über Auszuschließende Klassen können Sie einzelne Klassen oder Pakete daraus dennoch ungeschützt lassen. Alle drei Spring-Boot-Layouts unterstützen den Schutz von Abhängigkeiten.

Entsprechende CLI-Option: --protect-lib 'company-core.jar,company-domain.jar'. Die CLI akzeptiert auch Glob-Muster; die GUI merkt sich die exakten Dateinamen der ausgewählten JARs.

Auszuschließende Klassen und JavaFX

Die Handhabung entspricht der bei einer Java-Anwendung. Ausschlussregeln gelten sowohl für die Anwendungsklassen als auch für die zum Schutz ausgewählten Abhängigkeits-JARs. Auch eine Spring-Boot-Desktop-Anwendung kann JavaFX und WebView über den Reiter JavaFX-Runtime einbinden.

6. Optionen für Tomcat

Tomcat-Version

• Nutzt das WAR javax.servlet.*, wählen Sie Tomcat 9 · javax.
• Nutzt es jakarta.servlet.*, wählen Sie Tomcat 10.1 · jakarta.

Tomcat 10.1 setzt Java 11 oder neuer voraus. Führen Sie im Zweifel einen Kompatibilitätsscan aus. Verwendet die Anwendung sowohl javax als auch jakarta, erzwingen Sie keine Version, sondern lösen Sie zuerst den Abhängigkeitskonflikt.

Der erweiterte Modus wählt keine Version vor: Sie müssen die Empfehlung des Scans übernehmen oder selbst eine wählen, bevor es weitergeht. Entsprechende CLI-Optionen: --tomcat-version 9 oder --tomcat-version 10; die CLI akzeptiert außerdem auto.

Kontextpfad

Tragen Sie den mit / beginnenden Deployment-Pfad ein, etwa /app. Bleibt das Feld leer, wird /app verwendet. Beim Anhängen einer Anwendung an ein vorhandenes Tomcat-Ausgabeverzeichnis darf der Kontextpfad nicht mit einer vorhandenen Anwendung kollidieren.

Entsprechende CLI-Option: --context /app.

Auszuschließende Klassen

Standardmäßig werden die Anwendungsklassen unter WEB-INF/classes geschützt, WEB-INF/lib dagegen nicht. Servlets, Filter, Listener, DTOs, Konfigurationsklassen, Entitäten, JNI-Brückenklassen und alles, was der Container erweitern muss, sollten Sie in der Regel ausschließen.

7. Schutzumfang und Ausschlussregeln

Im erweiterten Modus schützt die GUI standardmäßig jede Anwendungsklasse, und Sie ziehen die Grenze zum Framework über Auszuschließende Klassen. Es gibt drei Regelformen:

com.example.SecretService   nur diese Klasse
com.example.service.*       nur dieses Paket, ohne Unterpakete
com.example.service.**      dieses Paket und alle Unterpakete

Wählen Sie Klassen über Auswählen… aus dem Klassenbaum oder tragen Sie sie über Hinzufügen… von Hand ein. Die Auswahl eines Pakets umfasst standardmäßig auch dessen Unterpakete; mit .* beschränken Sie es auf das Paket selbst. Bei Spring Boot zeigt der Klassenbaum zusätzlich die zum Schutz ausgewählten Abhängigkeits-JARs.

Empfohlen ist folgende Anordnung: öffentliche Grenze oder Framework-Einstieg → gewöhnliche Fassade oder Schnittstelle → geschützte Kernimplementierung. Verschlüsseln Sie nicht sämtliche Abhängigkeiten Dritter und Framework-Einstiegspunkte, nur damit die geschützte Fläche größer aussieht.

8. Exportieren, wiederverwenden und abschließend prüfen

Über Parameter exportieren… exportieren Sie eine von Hand bearbeitbare Aufgabendatei p4j-task.yml. Sie hält die aufgelösten Optionen fest, niemals jedoch E-Mail-Adresse oder Kennwort des Kontos. Später stellen Sie die Aufgabe über Aufgabendatei laden oben im Fenster wieder her; dieser Weg liest auch weiterhin die von älteren Versionen exportierten p4j-encrypt-run.sh- und .bat-Skripte.

Prüfen Sie auf der Ausgabeseite mindestens:

• Eingabedatei, Anwendungstyp, Java-Version und alle Zielplattformen;
• Archivsuffix, JIT-Einstellung, Scanner-Overlay und JVM-Startoptionen;
• JavaFX und WebView, das Spring-Boot-Layout bzw. Tomcat-Version und Kontextpfad;
• die zum Schutz ausgewählten Abhängigkeits-JARs und sämtliche Ausschlussregeln;
• das Ausgabeverzeichnis und ob ein neues Unterverzeichnis p4jx-xxxx angelegt wird.

Prüfen Sie das fertige Paket anschließend auf jeder Zielplattform mit dem enthaltenen Startskript: Start, Framework-Scan, Serialisierung, Reflection, Laden von Ressourcen und Ihre zentralen Geschäftsabläufe. Korrekt gesetzte erweiterte Optionen bedeuten nur, dass die Aufgabe richtig konfiguriert war — sie ersetzen keine Prüfung des Endprodukts.