Kompatibilitätsprüfung und Schutzumfang

P4JX verschlüsselt die Implementierungen von Methoden geschützter Klassen und erlaubt es ausschließlich dem mitgelieferten VLX JRE, diese zur Laufzeit zu lesen. Um einen guten Schutzeffekt mit der Kompatibilität zum Framework zu vereinen, wird empfohlen, nur die Kernbusiness-Implementierungen zu schützen; Framework-Eingänge, DTOs/Entitäten, Klassen, die dynamisch vom Framework erzeugt oder geändert werden müssen, sowie Drittanbieter-Abhängigkeiten sollen nicht geschützt werden.

1. Zuerst eine Kompatibilitätsprüfung durchführen

Nur scannen, keine Ausgabe:

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

Scannen und konservative Empfehlungen anwenden:

p4j springboot app.jar dist --compat-apply

Explizite Benutzeroptionen haben Vorrang vor automatischen Empfehlungen. Die Scans sind statische heuristische Analysen – ein Bericht mit “Es ist eine Überprüfung erforderlich.” bedeutet nicht unbedingt einen fehlgeschlagenen Anwendungsversuch; ein fehlerfreier Bericht ersetzt jedoch keine Regressionstests auf der Zielplattform.

Wenn die Scanergebnisse Codeanpassungen erfordern

Wenn der GUI-Bericht Es ist eine Aktion erforderlich. anzeigt (im englischen Interface ACTION REQUIRED), bedeutet dies: Der Benutzer muss den Quellcode der Anwendung ändern.; solche Probleme lassen sich nicht durch Anpassung der Paketierungsparameter lösen. Der Bericht listet die konkreten Klassen und Methoden auf, die geändert werden müssen, und gibt Empfehlungen zur Behandlung dieser Probleme.

  • Lese von der Speicherung aus ZIP/JAR ein: Ersetzen Sie ByteArrayInputStream durch Dateibasierte Leseverfahren wie Files.newInputStream(Path), FileInputStream, ZipFile oder JarFile.
  • Klasse aus der ursprünglichen Byte-Definition: Rufen Sie nicht direkt ClassLoader#defineClass auf Klassen mit Schutz auf – verwenden Sie stattdessen Class.forName() oder ClassLoader.loadClass(), damit die Klassenzuladung während des Laufs von P4JX erfolgt.

Nach der Anpassung des Quellcodes soll der JAR/WAR neu kompiliert werden, um erneut eine Kompatibilitätsprüfung durchzuführen. Erst wenn im Bericht keine Probleme mehr aufgeführt werden, wird das geschützte Paket erstellt.

2. Empfohlenes Schutzmodell

Öffentliche Grenze/Rahmen-Eingang → gewöhnliche facade oder Schnittstelle → geschützte Kernimplementierung

Beispiel:

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

3. Klassen, die in der Regel nicht geschützt werden sollten

  • Controller, Servlet, Filter, Listener, Advice;
  • Spring Configuration, AOT/CGLIB-verstärkte Objekte;
  • Jackson DTOs, Records, JPA Entities, Serialisierungsmodelle;
  • Klassen für JNI/SWT/native-Brücken;
  • Klassen, die durch Agenten, ORM-Systeme, Mock-Objekte, Hot-Reloading oder benutzerdefinierte ClassLoader umgeschrieben/erneut definiert wurden;
  • Drittanbieter-Frameworks und Open-Source-Abhängigkeiten;
  • Klassen, die das eigentliche class-Bytecode lesen müssen.

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

Laufumgebung

  • Geschützte Anwendungen müssen das mitgelieferte VLX JRE verwenden;
  • Starten per JPMS -m-Verfahren sowie Starten aus einer einzigen Quelldatei sind nicht unterstützt;
  • Ordinäre JAR-Dateien im classpath müssen vom Paketierer registriert werden und dürfen nicht während der Bereitstellung willkürlich hinzugefügt werden;
  • Ungeschützte, gewöhnliche Anwendungen sollten nicht mit dem VLX JRE ausgeführt werden.

Debugging und Agent

  • JVMTI-, JDWP-Debugger, Performance-Analyse-Tools, Couverture-Messungen sowie die meisten APM-Agenten werden nicht unterstützt;
  • -javaagent, -agentlib, Hot-Reloading sowie Klassenerneuerung werden nicht unterstützt;
  • Verarbeitungen, die eine Bytecode-Interpolation erfordern, müssen vor der Kompilierung abgeschlossen werden.

Startoptimierung

  • CDS, AppCDS und AOT werden nicht unterstützt;
  • ZGC sowie ShenandoahGC gehören nicht zum Unterstützungsrahmen des P4JX-Laufzeitumfelds.

5. Klassenergebnisse und Scanner

Beim Lesen der von .class geschützten Klassenressourcen erhält man lediglich Metadaten-Stubs: Der Klassennamen, die Signatur sowie die Anmerkungen bleiben erhalten, doch der eigentliche Methodeninhalt fehlt.

  • Durch herkömmliches Reflection können Metadaten gelesen werden, doch der ursprüngliche Bytecode kann nicht rekonstruiert werden;
  • Tools zur eigenständigen Analyse physischer ZIP-Dateien sehen standardmäßig keinen Inhalt von P4JX – man kann stattdessen --zip-overlay scanner ausprobieren;
  • Classpath-Scanner wie ClassGraph oder Reflections benötigen in Spring Boot möglicherweise --layout fat;
  • Die Verarbeitung von P4JX aus Speicher oder Netzwerkströmen mit ZipInputStream/JarInputStream ist nicht unterstützt;
  • Die zipfs-View ist nur für Leszwecke vorgesehen; Archivdateien können nicht geändert werden.

6. Archivierungsverhalten

  • Die Endung .jar bedeutet nicht, dass es sich um ein gewöhnliches JAR handelt; der Inhalt bleibt weiterhin P4JX;
  • Multi-Release JARs werden bei der Kodierung je nach Ziel-Java-Version entpackt;
  • Die ursprüngliche JAR-Signierung sowie die Zertifikatssemantik werden nicht beibehalten; bei Bedarf muss das endgültige Produkt extern signiert werden;
  • Die erzeugten P4JX-Dateien dürfen nicht geändert, erneut komprimiert oder zusammengeführt werden.