Kompatibilität und Schutzumfang

P4JX verschlüsselt die Methodenimplementierungen der geschützten Klassen und lässt sie zur Laufzeit nur von der mitgelieferten VLX JRE lesen. Damit Schutzwirkung und Framework-Kompatibilität zusammenpassen, sollten Sie nur die zentrale Geschäftslogik schützen und Framework-Einstiegspunkte, DTOs und Entitäten, Klassen, die das Framework zur Laufzeit erzeugt oder verändert, sowie Abhängigkeiten von Dritten außen vor lassen.

1. Führen Sie zuerst einen Kompatibilitätsscan aus

Nur scannen, ohne Ausgabe:

p4j javaapp app.jar --compat-scan
p4j springboot app.jar --compat-scan
p4j tomcat app.war --compat-scan

Scannen und die konservativen Empfehlungen anwenden:

p4j springboot app.jar dist --compat-apply

Von Ihnen ausdrücklich gesetzte Optionen haben immer Vorrang vor den automatischen Empfehlungen. Der Scan ist eine statische heuristische Analyse: Ein Eintrag „Prüfung erforderlich“ bedeutet nicht zwangsläufig, dass die Anwendung scheitert, und ein unauffälliger Bericht ersetzt keine Regressionstests auf der Zielplattform.

Wenn der Scan eine Codeänderung verlangt

Zeigt der GUI-Bericht ACTION REQUIRED, muss der Quellcode der Anwendung geändert werden; mit Paketierungsoptionen lässt sich das nicht lösen. Der Bericht nennt die betroffenen Klassen und Methoden und gibt eine dieser Empfehlungen:

  • ZIP oder JAR wird aus dem Speicher gelesen: Ersetzen Sie ByteArrayInputStream durch einen dateibasierten Weg wie Files.newInputStream(Path), FileInputStream, ZipFile oder JarFile.
  • Klasse wird aus rohen Bytes definiert: Rufen Sie ClassLoader#defineClass nicht direkt auf einer geschützten Klasse auf. Verwenden Sie stattdessen Class.forName() oder ClassLoader.loadClass() und überlassen Sie das Laden der P4JX-Runtime.

Bauen Sie das JAR oder WAR nach der Änderung neu und führen Sie den Kompatibilitätsscan erneut aus. Erzeugen Sie das Schutzpaket erst, wenn der Bericht dieses Problem nicht mehr aufführt.

2. Empfohlenes Schutzmodell

Öffentliche Grenze / Framework-Einstieg → gewöhnliche Fassade oder Schnittstelle → geschützte Kernimplementierung

Beispiel:

--protect 'com.example.service.impl.**' \
--exclude 'com.example.dto.**,com.example.config.**'

3. Klassen, die Sie normalerweise nicht schützen sollten

  • Controller, Servlets, Filter, Listener und Advice-Klassen;
  • Spring-Konfigurationsklassen sowie durch AOT oder CGLIB erweiterte Objekte;
  • Jackson-DTOs, Records, JPA-Entitäten und Serialisierungsmodelle;
  • JNI-, SWT- und andere native Brückenklassen;
  • Klassen, die ein Agent, ein ORM, eine Mocking-Bibliothek, ein Hot-Reload-Werkzeug oder ein eigener ClassLoader umschreibt oder neu definiert;
  • Frameworks von Dritten und Open-Source-Abhängigkeiten;
  • Klassen, die ihren eigenen echten Bytecode lesen müssen.

4. Nicht unterstützte oder eingeschränkte JVM-Funktionen

Laufzeitumgebung

  • Eine geschützte Anwendung muss mit der mitgelieferten VLX JRE laufen.
  • Der Start über die JPMS-Form -m und der Start aus einer einzelnen Quelldatei werden nicht unterstützt.
  • Gewöhnliche JARs im Klassenpfad müssen vom Packager registriert sein und lassen sich beim Deployment nicht frei ergänzen.
  • Führen Sie mit der VLX JRE keine ungeschützten Anwendungen aus.

Debugging und Agents

  • JVMTI, JDWP-Debugger, Profiler, Coverage-Werkzeuge und die meisten APM-Agents werden nicht unterstützt.
  • -javaagent, -agentlib, Hot Reload und das Neudefinieren von Klassen werden nicht unterstützt.
  • Bytecode-Weaving muss vor dem Encoding abgeschlossen sein.

Startoptimierung

  • CDS, AppCDS und AOT werden nicht unterstützt.
  • ZGC und Shenandoah GC liegen außerhalb des Umfangs der P4JX-Runtime.

5. Klassenressourcen und Scanner

Beim Lesen der .class-Ressource einer geschützten Klasse erhalten Sie einen Metadaten-Stub: Klassenname, Signaturen und Annotationen bleiben erhalten, die echten Methodenrümpfe fehlen.

  • Gewöhnliche Reflection kann die Metadaten lesen, den ursprünglichen Bytecode aber nicht wiederherstellen.
  • Werkzeuge, die das physische ZIP selbst auswerten, sehen standardmäßig nichts im P4JX-Archiv; versuchen Sie --zip-overlay scanner.
  • Klassenpfad-Scanner wie ClassGraph und Reflections benötigen unter Spring Boot unter Umständen --layout fat.
  • Das Auswerten eines P4JX-Archivs aus einem Speicher- oder Netzwerkstrom mit ZipInputStream oder JarInputStream wird nicht unterstützt.
  • Die zipfs-Sicht ist schreibgeschützt; das Archiv lässt sich darüber nicht verändern.

6. Verhalten des Archivs

  • Ein .jar-Suffix macht daraus kein gewöhnliches JAR — der Inhalt bleibt P4JX.
  • Multi-Release-JARs werden beim Encoding auf die Ziel-Java-Version reduziert.
  • Signaturen und Zertifikatssemantik des ursprünglichen JAR bleiben nicht erhalten; signieren Sie bei Bedarf das Endergebnis separat für die Verteilung.
  • Verändern, komprimieren oder verschmelzen Sie die erzeugten P4JX-Dateien nicht.