変更履歴

6.0.20 2026-08-22

保護されたアプリケーションのランダムなクラッシュ（サポート対象のすべての JDK ラインが対象）

同梱ランタイムの不具合を修正しました。保護されたアプリケーションが起動から数分〜1 日のあいだにランダムに停止することがありました。JIT コンパイラが最適化コードを破棄してインタプリタフレームを再構築する際、ランタイムがメソッド呼び出し命令のオペランドを復号せずにメモリから直接読み取り、その無意味な値を定数プールキャッシュの添字として使っていたためです。報告された症状は parameter_size を含む JVM 致命的エラーですが、同じ不具合はエラーを出さずに無関係なメモリを破壊することもありました。ホットパスが強く最適化されるアプリケーションほど影響を受けやすい状態でした。
同種の不具合を 5 つの JDK ラインすべてで洗い出したところ、保護されたメタデータを復号せずに読み書きしている箇所がさらに 5 つ見つかりました。うち 2 つは内部の整合性チェックが JVM をランダムに停止させるもの、1 つはクラスリンク時の競合で、クラスの準備が完了する前に無効な定数プールポインタを返す可能性がありました。いずれも本リリースのランタイムで修正済みです。
修正はエンコーダではなく同梱ランタイム側にあるため、既存の保護されたアプリケーションは本リリースで再度エンコードする必要があります。

`p4jx-fat` レイアウトで Spring Boot 4 アプリケーションが JDK 25 上で起動しない

p4jx-fat レイアウトがマルチリリース依存関係を誤った Java バージョンで解決していた問題を修正しました。パッケージャはコマンドラインで選択されたランタイムトレイン（--jre-home のみを渡した場合は 21 にフォールバック）を使っており、実際に同梱するランタイムのバージョンを使っていませんでした。そのため JDK 25 ランタイム向けにパッケージすると、META-INF/versions/22 以上のエントリがすべて破棄されていました。Spring Framework 7 では JDK 24 バリアントにのみ含まれる ClassFileMetadataReaderFactory が失われ、すべての Spring Boot 4 アプリケーションが NoClassDefFoundError で起動に失敗していました。fat と separate の 2 つのレイアウトは、依存関係を通常の JAR ファイルのまま JVM に開かせるため、影響を受けていません。

コマンドラインの `encode` コマンドが再び利用可能に

6.0.19 では GUI で単体ライブラリ暗号化を開発中として表示しましたが、意図せずコマンドラインの encode コマンドまで遮断していました。この遮断を解除し、encode は以前どおり動作します。GUI 側の「開発中」バッジはそのまま残るため、そちらに変更はありません。

Windows ARM64 はターゲットプラットフォームから除外

windows-aarch64 のサポートを取り下げました。GUI の選択肢から外れ、--target-platform windows-aarch64 は拒否され、EXE ランチャーも生成されず、対応する同梱ランタイムも公開されません。ARM 版 Windows では OS 内蔵のエミュレーションで windows-x64 パッケージを実行できます。現在のサポート対象は、Apple シリコンおよび Intel の macOS、ARM64 および x64 の Linux、x64 および x86 の Windows です。

6.0.19 2026-08-15

アカウント未ログインで暗号化する際の試用ライセンス通知を明確化

アカウント資格情報が指定されていない場合、CLI の警告は、保護されたアプリケーションが試用ライセンスで動作し 7 日間しか実行できないことを明確に伝え、ライセンス購入先として https://protector4j.com を案内するようになりました。従来の警告は「試用ライセンス」とだけ述べ、それがアプリケーションにとって何を意味するかを説明していませんでした。
GUI では暗号化を開始する前に同じ内容をダイアログで表示し、「購入」「タスクを続行」「タスクをキャンセル」の 3 つの選択肢を提供します。購入ボタンは現在選択中のサーバーリージョンに対応する購入ページを開くため、.cn リージョンを選んだユーザーが .com サイトへ送られることはありません。

外部ツールから GUI を起動するための起動引数

GUI が起動引数 p4j-ui [--task-file <file>] [<input-file>] を受け付けるようになりました。タスクファイルを渡すと通常のインポートフローを経て最終確認ページまで直行します。通常の入力パスを渡すと新しいタスクに事前入力され、.war は自動的に Tomcat フローへ進み、.jar はアプリケーション種別の選択ページで停止します。JAR は Java アプリケーション、Spring Boot アプリケーション、ライブラリのいずれでもあり得るためです。これは IDE プラグインなどの外部ツール向けの連携インターフェースであり、未知のハイフン付き引数は無視されるため、引数なしで GUI を起動したときの動作は従来とまったく同じです。

単体ライブラリ暗号化を開発中として明示

単体ライブラリ暗号化は 6.x 系ではまだ利用できないため、その旨を明示するようにしました。GUI の該当カードはグレーアウトされ「開発中」バッジが付き、CLI の encode コマンドは説明メッセージを出力して終了し、タスクを開始しません。この機能は今後のリリースで提供予定です。

6.0.18 2026-08-13

Spring Boot の p4jx-fat レイアウトでマルチリリース JAR に対応

Spring Boot の p4jx-fat レイアウトで、マルチリリース依存関係が常にベースバージョンから読み込まれていた問題を修正しました。ネストされた BOOT-INF/lib の JAR を展開する際、クラスローダーはエントリを文字どおりの名前で保持していたため、META-INF/versions/ 配下のクラスが選ばれることはなく、常にベースバージョンにフォールバックしていました。具体的な症状として、Spring Framework 7.0.5 では VirtualThreadDelegate がベースバージョンのスタブに解決され、そのスタブは無条件に UnsupportedOperationException を送出するため、JDK 25 上で spring.threads.virtual.enabled=true を有効にしたアプリケーションが起動できませんでした。広く使われている多くの依存関係がマルチリリース JAR として配布されており、バージョン固有の他のコードパスも同様に影響を受けていました。
クラスローダーは読み込み時にマルチリリースのエントリを解決し、実行中の JDK が対応する最も高いバージョンを選ぶようになりました。パッケージャーも fat リソースインデックスを構築する際に同じ解決規則を適用するため、どのエントリが有効かについてインデックスとローダーの判断が常に一致します。他の 2 つのレイアウト fat と separate は影響を受けたことがありません。これらは依存関係を通常の JAR ファイルのまま保持し、JVM 自身が開くためです。

6.0.17 2026-08-13

非 ASCII 文字を含む Windows のパスで保護済みアプリケーションが起動しない問題の修正

Windows 上でアプリケーションのパスに日本語や中国語などの非 ASCII 文字が含まれる場合に、保護済みアプリケーションが起動しない問題を修正しました。パスのどこで誤読されたかに応じて、アーカイブエラー E816 が発生するか、復号の失敗が ClassFormatError として現れていました。ランタイムはアーカイブのオープンとパスの正規化をバイト単位で行っていたため、レガシーなコードページで 2 バイト目がちょうど 0x5C（円記号・バックスラッシュ）になる文字が途中で分断され、その後半がディレクトリ区切り文字として読まれていました。GBK では日常的に使われる漢字の多くがこの並びになります。ASCII 文字だけで構成されたパスが影響を受けることはありませんでした。
Windows ではランタイムがファイルを開く前とランタイムフィンガープリントを計算する前に、システムの ANSI コードページを用いてパスをワイド文字へ変換するようになりました。これは純正 JDK が従来から行っているファイルの開き方と同じです。変更したのは Windows の処理経路のみで、Linux と macOS の動作は従来どおりです。5 つの JDK ラインすべてをこの修正込みで再ビルドしました。JDK 25、21、17 は VLX 1.0.22、JDK 11 は VLX 1.0.20、JDK 8 は VLX 1.0.13 です。

6.0.16 2026-08-10

Windows で Linux・macOS 向けにパッケージングすると失敗する問題を修正

Windows 上でターゲットプラットフォームを Linux または macOS にしてパッケージングすると失敗する問題を修正しました。同梱ランタイムの展開時に Failed to extract P4JX runtime と表示されますが、実際にはランタイムは正しく展開されていました。Windows でシンボリックリンクを作成するには権限の昇格が必要で、Linux と macOS のランタイムには legal/ 配下に百数十個のシンボリックリンクが含まれています。これらは jlink が重複を避けるために java.base を指すようにしたライセンス文書です。Windows に同梱されている tar コマンドはリンクを作成できないことを警告として扱いますが、それでも終了コードは非ゼロを返すため、エンコーダーはこれを致命的な失敗と判断し、展開済みのランタイムを削除していました。Windows 上で Windows 向けにパッケージングする場合は影響を受けません。Windows のランタイムにはシンボリックリンクが一つも含まれていないためです。
アーカイブの処理はプラットフォームの tar コマンドに依存しなくなりました。エンコーダーが .tar.gz のランタイムと JavaFX 素材を自前で読み取り、展開するため、Windows・Linux・macOS で挙動が完全に一致します。ファイルのパーミッション（ランチャーの実行ビットを含む）は、ホストのファイルシステムではなくアーカイブ自体から取得します。Windows ではライセンスのシンボリックリンクをスキップします。これらはランタイムとして何の機能も持たず、ランタイムフィンガープリントにも含まれないため、Windows で保護したアプリケーションの復号動作は従来とまったく同じです。

6.0.15 2026-08-08

更新ダイアログの修正

「新しいバージョン」ダイアログが、変更履歴が長い場合に画面全体に広がらず、固定された適切なサイズで開くようになりました。
ツールバーに「アップデートを確認」を追加し、起動時だけでなくいつでも新しいリリースを確認できるようになりました。

6.0.14 2026-08-07

文字列定数のインライン暗号化（デフォルトに）

文字列を読み込む ldc 命令を、クラスごとに合成した復号メソッドの呼び出しへ書き換えるインライン文字列保護モードを追加しました。文字列定数の平文は定数プールから完全に削除されます。平文はクラスロード時に SymbolTable へ入らず、そのコードが実際に実行されたときにのみヒープ上に現れ、使用されない文字列は暗号化されたままです。暗号文はクラス本体に格納され、既存のメソッド単位の暗号化で保護されます。これは純粋にエンコーダ側のバイトコード変換であり、アーカイブ形式もランタイムも変わらず、サポートするすべての JDK ラインでランタイムを更新せずに機能します。
文字列保護は 1 つのオプションで 3 モード（なし、標準（定数プール V72）、インライン）に統合され、インラインは Tomcat を含むすべてのアプリケーション種別のデフォルトになりました。通常のサーブレット、文字列 switch の業務ロジック、JspC でプリコンパイルされた JSP サーブレットクラスでエンドツーエンド検証済みです。CLI フラグは --encrypt-strings none|constant|inline で、GUI でも同じ選択肢を提供します。
書き換えできないメソッド（古いクラスファイル形式のインターフェース、64 KB 上限に近いメソッド、まれなシリアライズの境界ケース）は標準の V72 層にフォールバックするため、結果が以前より弱くなることはありません。

Spring Boot p4jx-fat の起動が高速化

純 fat レイアウトの Spring Boot クラスローダーが、ネストされたリソースインデックスを一括ではなくオンデマンドで読み込むようになり、大規模な p4jx-fat アプリケーションの起動処理を削減します。

環境変数からのアカウント資格情報

encode、javaapp、springboot、tomcat の各コマンドとタスクファイルモードで、アカウントのメールアドレスとパスワードを P4JX_ACCOUNT_EMAIL と P4JX_ACCOUNT_PASSWORD（または P4JX_ACCOUNT_PASSWORD_MD5）から読み取れるようになりました。対応するコマンドラインオプションが無い場合にのみ使用されるため、エクスポートしたタスクファイルに資格情報が含まれません。

6.0.13 2026-08-05

`javax.lang.model` を使用する保護対象アプリケーションの起動修正

フレームワークが javax.lang.model API を参照する保護対象アプリケーションで、起動時に NoClassDefFoundError: javax/lang/model/SourceVersion が発生する問題を修正しました。代表的なのは Spring Data JPA で、そのリポジトリ AOT processor がコンテナ初期化中に SourceVersion を参照します。以前は同梱ランタイムから除外していた java.compiler モジュールを、再び含めるようにしました。これはコンパイラ実装を持たない API 専用モジュールのため、ToolProvider.getSystemJavaCompiler() は引き続き null を返し、jdk.compiler も含まれないままです。保護面に変化はありません。
JDK 17、21、25 のランタイムを VLX 1.0.21 に、JDK 11 を VLX 1.0.19 に再ビルドし、いずれも復元された java.compiler モジュールを含みます。JDK 8 はモジュールシステムを持たず、これらのクラスをもともと提供しているため影響を受けません。

6.0.12 2026-08-02

JxBrowser 9 のサポートと、NullPointerException を送出する保護対象アプリケーションのクラッシュ修正

保護対象アプリケーションに JxBrowser 9 を組み込めるようになりました。--native-compat jxbrowser は組み込みカタログの 9 バージョン（9.0.0〜9.3.1）から 1 つを選択し、Java 17、21、25 上の 7 プラットフォームに対応します。ランタイムは、選択したバージョンに対して SHA-256 が登録されている公式 IPC ライブラリにのみスレッド attach 権限を与え、実際にスレッドが attach する時点で呼び出しモジュールを再検証します。パス、ハッシュ、ライブラリ名をコマンドラインから受け取ることはありません。macOS 26 では JxBrowser 9.0.1 以降を使用してください。TeamDev は同バージョンで Engine 作成時の Chromium クラッシュを修正しており、9.0.0 は通常の JDK でも同様にクラッシュします。
保護対象アプリケーションが NullPointerException を送出した際に ClassFormatError が発生する問題を修正しました。6.0.9 の修正は JVM の詳細 NPE メッセージをメソッド単位で抑止するものでしたが、不十分でした。この機能はメソッド本体を標準バイトコードとして解析するため、P4JX が変換した後では、解析が有効であることをメソッド単位のフラグで証明することはできません。ランタイムは詳細メッセージを無条件に無効化するようになりました。例外の型、スタックトレース、アプリケーションが指定したメッセージには影響しません。JDK 17、21、25 のランタイムは VLX 1.0.20 に再ビルドされます。JDK 11 はこの問題の影響を受けず VLX 1.0.18 のまま、JDK 8 は VLX 1.0.12 のままです。
java -version が VLX ランタイムのビルドを表示するようになり、展開しなくても同梱ランタイムを識別できます。
Windows EXE の 2 つのバージョン項目を、パッケージ処理の途中で失敗させるのではなく、開始前に検証するようにしました。Windows は各要素を符号なし 16 ビット整数として保持するため、ドット区切りの 1〜4 個の数値はいずれも 0〜65535 の範囲である必要があります。項目を空のままにした場合は従来どおり 0.0.0.0 になります。

6.0.11 2026-07-27

保護されたアプリケーション向けのネイティブ Windows ランチャー

Java App パッケージ、Spring Boot の 3 種類すべてのレイアウト、および Tomcat パッケージで、ネイティブ Windows EXE を任意に生成できるようになりました。Windows x64、x86、ARM64 向けにコンソール版と GUI 版を用意し、既存の起動スクリプトも各パッケージに引き続き含まれます。
EXE のファイル名、モード、アイコン、Windows バージョンメタデータを指定する CLI および GUI 設定を追加しました。マルチプラットフォームタスクでは、選択した Windows ターゲットにだけ EXE を生成します。設定はバージョン 2 の p4j-task.yml に保持され、バージョン 1 のタスクファイルも引き続き読み込めます。
純粋な Win32 ランチャーである JExeKit を、同梱の vlxjre、厳密なクラスパス、および JVM 引数と統合しました。Java を起動する前に、パッケージ外へ出るパス、再解析ポイントによる置換、安全でないエージェントまたはブートクラスパスのオプションを拒否します。
JExeKit テンプレートは AES-GCM で暗号化した .jxt リソースとしてのみ組み込まれ、生成時にメモリ上だけで復号されます。生成される各ランチャーのパラメータブロックには production 状態の Ed25519 署名が付き、アイコン、バージョン、マニフェスト、パラメータの変更は、ユーザーが最後に行う Authenticode 署名より前に完了します。

6.0.10 2026-07-27

WAR 構造を維持した高速な Tomcat 依存関係の読み込み

クラスを読み込むたびに、保護された WEB-INF/lib 内のネスト JAR 全体を再読み込みしてハッシュを計算していたため、Tomcat の起動が著しく遅くなる問題を修正しました。VLX 1.0.17 では、密封された各ネスト JAR を一度だけ検証し、認証済みの生成元情報を VM 内にキャッシュしたうえで、要求された各クラスを暗号化クラスインデックスと照合し続けます。
一時的な web-libs の展開およびマウントによる回避策を削除しました。WEB-INF/lib/*.jar は保護された .p4jx アーカイブ内に保持され、元の WAR 構造とアプリケーション分離を維持します。JDK 11、17、21、25 向けの VLX 1.0.17 ランタイムを、対応する 24 のプラットフォーム構成に公開しました。JDK 8 は従来の ZIP overlay 経路を維持し、VLX 1.0.11 のままです。
アプリケーションの module-info.class に対する互換性スキャンを修正しました。モジュール記述子にはメソッド本体がないため、自動的に暗号化対象から除外され、記述子ツールからは引き続き読み取れます。
GUI が出力する CLI コマンドでは、--java-version、--target-platform、--create-new-folder をパッケージャー引数の後ろに連続した接尾オプションとして配置できるようになりました。従来の接頭形式も引き続き使用できます。

6.0.9 2026-07-25

暗号化アプリが NullPointerException を出力する際のクラッシュ修正

保護されたメソッドが暗黙的な NullPointerException をスローし、アプリケーションがそのメッセージを読み取ったりスタックトレースを出力したりした際に発生し得た JVM クラッシュを修正しました。ランタイムの「役立つ NPE 詳細」機能が、メソッドの暗号化されたバイトコードから "because ... is null" というテキストを復元しようとして無効なメモリを参照し、VM をクラッシュさせていました（JavaFX FXML アプリケーションで確認）。保護されたメソッドでは詳細メッセージをスキップし、標準の NullPointerException にフォールバックするようになりました。例外の型、スタックトレース、アプリケーションが指定したメッセージには影響しません。
JDK 17、21、25 のランタイムを本修正とともに VLX 1.0.16 に再ビルドしました。「役立つ NPE 詳細」機能は JDK 14 より前には存在しないため JDK 11 は影響を受けず、VLX 1.0.15 のままです。JDK 8 は VLX 1.0.11 のままです。

6.0.8 2026-07-24

オンデマンドの Tomcat ランタイムと本番環境向けの安全な既定値

app.p4jx 内の Tomcat クラスが物理的なクラスパス JAR として見えなくなったため、公開済みの自己保護エンコーダーで Tomcat WAR をパッケージ化できない問題を修正しました。Tomcat 9.0.107 と 10.1.53 は、Servlet 名前空間に応じて選択される不変かつバージョン付きの R2/COS アーティファクトになりました。初回使用時にダウンロードしてローカルにキャッシュし、正確な SHA-256 と JAR マニフェストを検証します。改ざんされたキャッシュは破棄して再ダウンロードします。
公開される WEB-INF/lib JAR は、アプリケーションごとに分離され、ハッシュでバインドされた物理 Web リソースとして配置されるようになりました。これにより、Spring の起動時にクラスごとに入れ子のアーカイブを繰り返し読み取って検証する処理を回避します。
新しいビルドでは、本番ライセンスエンドポイント https://protector4j.com が既定値になりました。内部エンドポイント http://10.10.10.16:16002 は、P4JX_LICENSE_MODE=dev または -PlicenseMode=dev を明示的に選択した場合にのみ使用されます。

6.0.7 2026-07-24

Tomcat のネストされた依存関係と信頼済み動的クラス

保護された Tomcat WAR が WEB-INF/lib/*.jar からクラスまたはサービスを読み込む際の失敗を修正しました。Protector4J はネストされた JAR とクラスの正確な SHA-256 メタデータを app.p4jx に封印するようになり、未知、差し替え済み、または改ざん済みの依存関係は引き続き拒否されます。
JDK 11 の MethodHandles.Lookup#defineClass が JDK 11 固有のソースマーカーを使用することで発生していた Spring CGLIB と Hibernate Byte Buddy の失敗を修正しました。動的な信頼には引き続き VM が検証した呼び出し元クラスまたはローダーの由来が必要であり、マーカー文字列、クラス名、パス、パッケージ名、CodeSource が信頼を付与することはありません。
JDK 11、17、21、25 向けの VLX 1.0.15 ランタイムを、サポート対象の 24 プラットフォーム構成で公開しました。実際の FXML、Swing/AWT、Tomcat のネストされた依存関係の読み込み、由来と改ざんのネガティブケースを含む厳格な L1-L5 ゲートをすべて通過しています。JDK 8 は VLX 1.0.11 のままです。

6.0.6 2026-07-22

信頼されたクラス定義の由来伝播

保護された JavaFX FXML アプリケーションの起動失敗を修正しました。MethodUtil は、VM が由来を検証済みの Trampoline ヘルパーを defineClass(byte[]) で定義します。信頼は、クラス名、パス、パッケージ名、CodeSource 文字列ではなく、VM が検証したクラスまたはローダーの由来からのみ伝播します。
fx:controller、プロパティ要素、Controller 注入、WebView 起動を含む実際の FXML カバレッジを追加し、信頼済み動的定義、2 段階伝播、未知の由来、未承認 JAR、protected class 名の置換に対する回帰テストも追加しました。
JDK 11、17、21、25 向けの VLX 1.0.14 ランタイムを公開しました。JDK 8 は VLX 1.0.11 のままです。

6.0.5 2026-07-21

JavaFX ネイティブランタイムの完全性

パッケージ化された JavaFX DLL を vlxjre/bin に配置し、ランチャーのネイティブライブラリ検索を調整することで、Windows 上での JavaFX WebView の起動失敗（Graphics Device initialization failed / No toolkit found）を修正しました。
暗号化された app.p4jx の許可リストに外部ネイティブライブラリを追加しました。JavaFX ネイティブファイルはパスに関係なく正確な SHA-256 値と一致する必要があり、Glass が実際に読み込まれたファイルを再検証します。認識されないファイルや改ざんされたファイルは拒否されます。
JDK 11、17、21、25 向けに更新された Protector4J ランタイムを公開しました。サポート対象の JavaFX プラットフォーム構成は L5.1-L5.4 を通過し、WebView の起動に加えて、モジュール JAR、jdk.jsobject、Glass ネイティブライブラリの改ざん拒否も検証しました。

6.0.4 2026-07-21

外部モジュールの完全性と JavaFX ランタイム互換性

外部モジュールに対するパスベースの信頼処理を廃止しました。すべての外部モジュール JAR は app.p4jx に埋め込まれた正確な SHA-256 許可リストのエントリと一致する必要があり、場所に関係なく未認識または改ざんされたファイルは拒否されます。
JavaFX module-info.class からの依存関係閉包の自動検出と、javafx.media および jdk.jsobject を含む固定済み JavaFX / JDK モジュールの制御された許可を追加しました。
新たにリリースした P4JX ランタイムにより、対応する JDK バージョンとプラットフォーム全体で JavaFX WebView の起動、およびブートレイヤー構築後の E818 / ClassFormatError エラーを修正しました。

6.0.3 2026-07-20

JavaFX WebView モジュールの互換性

同じ JDK/VLX バージョンから再ビルドされた対応 P4JX ランタイムで、オプションの jdk.jsobject を解決できない問題を修正しました。完全な lib/modules イメージのバイトが異なるという理由だけで、互換性のあるランタイムを拒否しなくなりました。
JDK 系列とプラットフォーム別の成果物選択、モジュールの厳密な SHA-256 とモジュール名の検証、およびインストール後の依存関係閉包の再検証は維持されます。

6.0.2 2026-07-20

JavaFX WebView の互換性

javafx.media を javafx.web と一緒にパッケージ化し、削減されたランタイムにモジュールが含まれない場合は P4JX に正確に一致する jdk.jsobject を自動解決することで、JavaFX WebView の起動エラーを修正しました。
SHA-256 で固定され、バージョン、プラットフォーム、ランタイムに関連付けられたオプションモジュールを、地域別の公開ダウンロードサービスから取得できるようにしました。モジュールを既に含むランタイムはダウンロードをスキップします。

6.0.1 2026-07-20

JavaFX の互換性

JavaFX ランタイムクラスを内包する fat JAR の起動エラーを修正しました。互換性ルールの自動適用により、内包された JavaFX API、実装、JNI ブリッジの名前空間は暗号化されず、同梱された JavaFX モジュールとのクラス所有権の重複を回避します。
JavaFX ランタイムをシェーディングしたアプリケーション向けの互換性診断と多言語ガイダンスを改善しました。

6.0.0 2026-07-20

Protector4J 6.0 は、5.x シリーズの通常の追加更新ではなく、保護アーキテクチャを全面的に再設計したメジャーリリースです。

アーキテクチャと保護

Protector4J の基盤アーキテクチャを再設計し、新しい P4JX 保護エンジンを導入しました。
アーカイブ生成、クラスローディング、ランタイム実行、アンチデバッグ、成果物の整合性など、各層に約 100 の保護対策を追加しました。
リバースエンジニアリングの障壁を大幅に高めました。高度な AI 支援分析ツールを使用した場合でも、短期間での解析を極めて困難にすることを目的とした新設計です。
ライセンス要求、ランタイムのダウンロード、成果物の検証、クロスプラットフォームインストーラーのセキュリティを強化しました。

製品体験

JDK 8、11、17、21、25 に対応し、Java、JavaFX、Spring Boot、Tomcat アプリケーション向けのグラフィカルなパッケージ化フローを提供します。
互換性スキャン、クラスの選択的暗号化、依存 JAR の保護、YAML タスクのインポート/エクスポート、複数ターゲットプラットフォームの一括ビルドを追加しました。
デスクトップインターフェースを再設計し、11 言語と永続的な言語設定に対応しました。