Windows EXEランチャーの生成

パッケージ化時に、保護されたアプリケーション用のネイティブなWindowsランチャーを生成できます。これは純粋なWin32実行ファイルで、ダブルクリックするだけでアプリケーションが実行され、ユーザーは事前にJavaをインストールする必要もなく、run.batを見る必要もありません。

EXEはオプションで、デフォルトでは生成されません。有効にすると、生成されるパッケージには元のrun.sh / run.command / run.batも同時に保持され、2つの起動方法は完全に同じアーカイブ形式、クラスパス、メインクラス、およびJVMパラメータを使用します。

1. 適用範囲

Windows対象プラットフォームを少なくとも1つ選択する必要があります。LinuxまたはmacOSプラットフォームも同時に選択してもタスクは失敗しません。これらのプラットフォーム用のサブパッケージは通常通り生成されますが、EXEは含まれず、元の起動スクリプトが引き続き使用されます。すべての対象プラットフォームがWindowsでない場合、タスクは直接エラーとなります。

2. GUI操作

1. 入力ファイルと対象プラットフォームを選択するページでWindowsアプリケーション用EXEファイル（x64/x86/ARM64）の作成にチェックを入れ、Windows対象プラットフォームを少なくとも1つ選択してください。
2. このスイッチはシンプルモードと高度なモードの分岐点の前にあるため、どちらのモードでもEXEを生成できます。
3. チェックを入れると、ファイル名、起動子モード、アイコン、Windowsバージョン情報を入力するためのWindows EXE起動ツールというページが追加で表示されます。チェックを入れない場合は、直接最終確認ページに進みます。
4. EXEを有効にすると、JVM起動パラメータ入力欄はこの起動画面にのみ表示され、同じパラメータに対する複数の入力手段が生じるのを防ぎます。入力されたパラメータはEXEと起動スクリプトの両方に記録されます。
5. 最終確認画面には、実際にEXEが生成されるプラットフォームや、入力された起動画面のフィールドが一覧表示されます。

3. CLIの例

最もシンプルな形式で、--windows-exeのみが必要です。

p4j --target-platform windows-x64 javaapp app.jar dist --windows-exe

ファイル名とウィンドウモードを指定する場合：

p4j --target-platform windows-x64 javaapp app.jar dist \
  --windows-exe \
  --exe-name MyApp.exe \
  --exe-mode gui \
  --exe-icon assets/app.ico

Windowsの3つのアーキテクチャを一度に生成し、完全なバージョンリソースを記入する場合：

p4j --target-platform windows-x64,windows-x86,windows-aarch64 \
  springboot app.jar dist \
  --windows-exe \
  --exe-name MyService \
  --exe-file-version 1.4.2.0 \
  --exe-product-version 1.4.2.0 \
  --exe-company 'Example Inc.' \
  --exe-product 'Example Service' \
  --exe-description 'Example background service' \
  --exe-copyright 'Copyright (C) 2026 Example Inc.'

Tomcatパッケージも対応しており、生成されるEXEは内蔵されたTomcatをフロントエンドとして起動します。

p4j --target-platform windows-x64 tomcat app.war dist --context /demo --windows-exe

4. パラメータの説明

--exe-*のいずれかのオプションを選択するだけで自動的にEXEの生成が有効になるため、別途--windows-exeを指定する必要はありません。

ファイル名は単なるファイル名のみでなければならず、/、\、またはディレクトリ部分を含んではいけません。.exeのサフィックスがない場合は自動的に付加されます。

2つのバージョン番号フィールドの規則は同じで、1から4つのセグメントを英字のピリオドで区切った数字で、各セグメントの値は0から65535の範囲です。例えば1.0.0.1のようになります。Windowsでは各セグメントが16ビットの無符号整数として保存されるため、v1.0や1.0-betaのように文字やスペースが含まれる形式は受け付けられません。空欄の場合は0.0.0.0とみなされます。これら2つのフィールドはパッケージ作成が開始される前にチェックされ、作成途中でエラーが発生することはありません。

5. 出力構造

Java Applicationを例にすると、EXEと起動スクリプトはパッケージのルートディレクトリに並んで存在します。

dist/
├── MyApp.exe             # 新たに追加されたWindows起動ツール
├── app.p4jx
├── vlxjre/
├── lib/
├── run.sh
├── run.command
├── run.bat
└── README.md

パッケージ内のREADME.mdは、生成されたEXEファイル名をリストアップし、コード署名に関するヒントも表示します。

6. 実行動作

EXEが存在するディレクトリこそがアプリケーションのルートディレクトリです。起動ツールは、ルートディレクトリ内にあるランタイム、アーカイブ、クラスパス、作業ディレクトリのみを受け付けます。パッケージ外を指すパスや、シンボリックリンクやジョインポイントで置き換えられたパスは拒否され、プロセスは起動しません。これにより、パッケージ全体を移動したり名前を変更したりできますが、EXEだけを別途コピーして使用することはできません。

EXEのJVMパラメータはパッケージング時に固定され、パラメータブロックと共に署名され、実行時に検証されるため、デプロイ後には変更できません。APP_JAVA_OPTSはrun.batに対してのみ有効で、EXEはこれを読み取りません。EXEのJVMパラメータを変更する必要がある場合は、再パッケージングが必要です。

同じ理由から、-javaagent、-agentlib、-agentpath、-Xbootclasspath、--patch-moduleはEXEの起動パラメータとして書き込むことが許可されていません。--jvm-optionを使用してこれらのパラメータを渡すと、パッケージングが直接失敗します。

7. コード署名

Protector4Jは生成されたEXEに発行者の署名を追加せず、またどのようなAuthenticode資格情報にもアクセスしません。アイコン、バージョンリソース、起動パラメータなど、PEファイルに加えられるあらゆる変更はパッケージング段階で行われるため、署名処理は最後に行うべきです。

1. パッケージングを完了し、EXEが正常にアプリケーションを起動できることを確認します。
2. 自分の証明書を使用してAuthenticode署名を行い、RFC3161タイムスタンプを追加します。
3. Windowsの/paポリシーを使用して署名の検証を行います。

署名が完了したら、このPEファイルを改変しないでください。いかなる変更も署名を無効にしてしまいます。アイコンやバージョン番号を変更する必要がある場合は、再パッケージングしてから再度署名してください。

8. タスクファイルのフィールド

エクスポートされるp4j-task.ymlはバージョン2を使用し、EXEを有効にした場合は以下のフィールドが保存されます。バージョン1のタスクファイルも引き続き正常に読み取れます。

windowsExe: true
exeName: MyApp.exe
exeMode: console
exeIcon: assets/app.ico
exeFileVersion: 1.4.2.0
exeProductVersion: 1.4.2.0
exeCompany: Example Inc.
exeProduct: Example Service
exeDescription: Example background service
exeCopyright: Copyright (C) 2026 Example Inc.

9. よくある質問

完全なCLIオプションについてはCLIパラメータの参考情報を、GUIガイドの流れについてはGUI利用ガイドをご覧ください。