install4j の新機能

デフォルトでは、キャッシュはユーザーごとのキャッシュディレクトリに保存されます。LinuxとUnixでは$XDG_CACHE_HOME/install4j/aotまたは~/.cache/install4j/aot、macOSでは~/Library/Caches/install4j/aot、Windowsでは%LOCALAPPDATA%\install4j\aotです。カスタムのベースパスはランチャーウィザードで設定できます。キャッシュファイル名には、アプリケーションのビルドとJavaランタイムから導出されたキーが含まれるため、キャッシュはアプリケーションの更新後やJavaランタイムの変更後に自動的に再生成されます。以前のビルドのキャッシュは自動的にクリーンアップされ、アンインストーラーはインストールのキャッシュを削除します。

install4j IDE自体もAOTキャッシュを使用するようになり、現在では2倍以上の速さで起動します。

次の4つのアクションが提供されます：

• 「Read value from a YAML file」は、パスで指定された位置の値を読み取り、インストーラー変数に保存します。スカラー値はYAMLの型を保持します。また、マッピングはオプションで、最上位エントリごとに1つのインストーラー変数へ展開できるため、YAMLファイルのセクションから設定フォームを簡単に初期化できます。
• 「Count entries in a YAML file」は、リストまたはマッピングのエントリ数を数えて、その結果をインストーラー変数に保存します。
• 「Modify YAML files」は、1つ以上のYAMLファイル内の指定したパスにある値を変更、挿入、または削除します。編集はテキストレベルで行われるため、コメントと書式は保持されます。これに読み取りアクションが展開する変数とその「Overlay installer variables」オプションを組み合わせると、スクリプトなしで完全な読み取り・変更・書き込みサイクルが実現します。
• 「Write YAML file」は、YAMLファイルに値を書き込みます。ファイルは必要に応じて作成または上書きされます。

すべてのアクションは、共通のパス構文でノードを指定します。$.keyはマッピングのキー、$['key']はドットや特殊文字を含むキー、$[0]はリストのインデックスを指定します。セグメントは組み合わせることができます。たとえば$.servers[0].hostのようになります。複数のYAMLドキュメントを含むファイルは、ドキュメントインデックスによってサポートされます。

SBOMの生成は、「General Settings->Media File Options」ステップで設定します。2つの独立した出力が利用できます：

• 外部SBOMは、各メディアファイルの隣にJSON形式とXML形式で書き出されます。たとえばmyapp_windows-x64_1_0.exeという名前のメディアファイルの場合、ファイル名はmyapp_windows-x64_1_0.exe.install4j_runtime.cdx.jsonとmyapp_windows-x64_1_0.exe.install4j_runtime.cdx.xmlになるため、リリースと一緒にセキュリティスキャナーにアップロードできます。
• 埋め込みSBOMは、ディストリビューションツリー内の設定可能なパスに、インストール内容の一部として配置されます。こちらもJSONまたはXML形式です。そのパスにファイルが存在しない場合は、install4jがランタイムのみを対象とするSBOMをそこに配置します。

埋め込みSBOMのパスが既存のCycloneDX SBOM（たとえば、独自のビルドがアプリケーション向けに生成したもの）を指している場合、install4jはそのSBOMを、install4jランタイムコンポーネントとその依存関係グラフで拡張します。既存の内容はそのまま保持され、BOMバージョンがインクリメントされるため、インストール後のアーティファクトには単一の完全なSBOMが含まれることになります。CycloneDX仕様のバージョン1.2から1.7までがサポートされています。

MSIXはMSIとは完全に独立しています。MSIの場合、install4jが生成するのは、install4jが生成したインストーラーを包むラッパーだけです。これは、スクリーン、アクション、スクリプトといったinstall4jの概念をMSIモデルにシームレスにマッピングできないためです。一方MSIXは宣言的な形式であるため、サービス、ファイル関連付け、スタートアップタスクなどの概念はマニフェストエントリに直接変換されます。

MSIXパッケージは、.msixファイルをダブルクリックするか、PowerShellでAdd-AppxPackageを実行することでインストールされます。インストール時には、install4jのインストーラーウィザードは実行されません。

このメディアファイルタイプを配布するにはコード署名が必須です。署名されていないMSIXパッケージは、Windowsの開発者モードでしかインストールできないためです。

MSIX固有の設定はすべて、メディアファイルウィザードの専用サブステップで行います。「MSIX options」ステップでは、パッケージID名、パッケージバージョン、テスト済みの最小および最大Windowsバージョンを設定します。ランチャーをサインインランチャーとして設定することもできます。サインインランチャーはユーザーのログオン時に自動的に実行され、ユーザーは後からWindowsの「スタートアップアプリ」設定で無効にできます。

パッケージアイコンは、「Package icon」サブステップでカスタマイズします。このアイコンはWindowsのインストールダイアログに表示されます。背景色を設定できるため、透明部分を含むアイコンにも不透明なタイルが与えられます。スタートメニューとタスクバーには、ランチャーウィザードで設定されたアイコンが使用されます。

サービスは、生成されたサービスランチャーから選択され、マニフェストを通じてWindowsサービスとして登録されます。スタートアップの種類とサービスアカウントは、「Services」サブステップでランチャーごとに設定します。

ファイル関連付けは、1つ以上のファイル拡張子をランチャーに結び付けます。こうしたファイルをダブルクリックすると、アプリケーションが開くようになります。関連付けごとに、説明、オプションのMIMEタイプ、カスタムアイコンを設定できます。

URLスキームハンドラーも同じように宣言できます。これにより、myapp://のようなカスタムスキームがランチャーにルーティングされるようになります。どちらも「File associations and URL handlers」サブステップで設定します。

App URIハンドラーを使用すると、ランチャーが特定のホスト向けの通常のhttps://リンクを処理できるようになります。一致するリンクが開かれると、Windowsはブラウザーの代わりにアプリケーションにルーティングできます。Webサイトの同意なしにそのリンクを関連付けることはできないため、ホスト側は、お使いのパッケージを記載した生成済みのwindows-app-web-link.jsonファイルを/.well-known/の下で公開する必要があります。

アプリ実行エイリアスにより、選択したランチャーが実行ファイル名でユーザーのPATH上に公開され、コマンドプロンプトや「ファイル名を指定して実行」ダイアログから名前で呼び出せるようになります。エイリアスのスコープはパッケージに限定されており、パッケージと一緒に削除されます。エイリアスは、「Applications on PATH」サブステップで選択します。

自動アップデートには、install4jのアップデートアーキテクチャではなく、Windowsに組み込まれたApp Installer機構が使用されます。必要な.appinstallerファイルはinstall4jが生成し、そのホストURLをWindowsが定期的にチェックすることで、新しいパッケージバージョンがバックグラウンドでインストールされます。ホスティングURLと、チェック頻度やユーザーに確認するかどうかといったアップデートの動作は、「Auto-update」サブステップで設定します。

プロジェクトに設定されたすべての言語は、マニフェストで自動的に宣言されます。

スキルは自己完結型のナレッジパッケージです。プロジェクトファイルのスキーマ、利用可能なすべてのBeanクラス（スクリーン、アクション、フォームコンポーネント、スクリーンスタイルとウィジェットスタイル）のカタログ、実行可能なサンプルプロジェクト、install4j API、完全なドキュメントが、一般的なワークフローの手順とあわせてAIが扱いやすい形式で1つにまとめられています。これにより、アシスタントは正確な情報に基づいて検証でき、推測に頼る必要がありません。

対応するアシスタントは、install4jに関連するタスクを与えると、スキルを自動的に読み込みます。たとえば、helloサンプルに、インストール済みのバージョンを検出して2回目のインストールの前に確認を表示するスタートアップチェックを追加するよう依頼すると、アシスタントは適切なレジストリAPIを見つけ、新しいアクションをプロジェクトファイルに挿入し、プロジェクトが引き続きコンパイルできることを確認します。

スキルをインストールするには、ツールバーの「Install AI Skill」ボタンをクリックします。ダイアログから、AIエージェントのスキルディレクトリに書き込むことができます。対応するエージェントは、Claude Code、Claude Desktop、Cursor、Codex CLI、Gemini CLI、OpenCode、Junieです。

グローバルにインストールすればマシン上のすべてのプロジェクトで利用でき、プロジェクトごとにインストールした場合は、エージェントがそのプロジェクトから実行されているときにのみ利用できます。スキルはお使いのinstall4jのバージョンに合わせて生成されるため、そのスキーマ、Beanカタログ、サンプルは常にインストール済みのコンパイラと一致します。

XMLエディターでスキーマを.install4jファイルに関連付けると、編集時にオートコンプリート、インラインドキュメント、検証が利用できるようになります。さらに、コマンドラインからコンパイルする際にプロジェクトファイルがスキーマに対して検証されるようになったため、構造的なエラーを正確なメッセージとともに早期に検出できます。

セッションは、いずれかのセッションビルダーで開始します。生成されたインストーラーをテストするにはInstallerSessionBuilder.forMediaFile(...)、アンインストーラーをテストするにはUninstallerSessionBuilder.forInstallation(...)、アップデートダウンローダーなどのカスタムインストーラーアプリケーションにはInstallerApplicationSessionBuilder.forInstallation(...)を使用します。ビルダーのオプションには、タイムアウト、追加のコマンドライン引数、システムプロパティ、作業ディレクトリ、ログファイル、およびブレークポイントデバッグを容易にするためにインストーラーをインプロセスで実行するデバッグモードがあります。

セッション内では、IDを指定してスクリーンを待ち受け、「Next」「Previous」「Cancel」「Finish」ボタンでナビゲートし、フォームコンポーネントとダイアログ用の厳密に型付けされたハンドルを操作します。最後に、インストーラー変数、インストールディレクトリ、ログ、終了コードを検証します。

InstallerSession session = InstallerSessionBuilder
    .forMediaFile(new File("media/myApp_windows-x64.exe"))
    .installationDirectory(targetDirectory)
    .start();

session.waitForScreenId("welcome").nextScreen();

// Accept the license, then fill in a custom form screen
session.currentScreen().checkBox("acceptCheckBox").setSelected(true);
session.currentScreen().nextScreen();
session.currentScreen().textField("port").setText("8443");
session.currentScreen().nextScreen();

// Modal dialogs can be handled when they appear
session.alert().clickYes();

session.currentScreen().finish();

// Verify the outcome after the installer has exited
int exitCode = session.awaitExit(Duration.ofMinutes(2));
assertEquals(0, exitCode);

Kotlinユーザーのために、APIをより自然に記述できる拡張関数も用意されています。useSession { }ブロックはセッションを開始して自動的にクローズし、onScreenやonAlertのようなヘルパーはスクリーンやダイアログ上でコードブロックを実行し、session["name"]アクセサーはインストーラー変数を読み取ります。

InstallerSessionBuilder
    .forMediaFile(File("media/myApp_windows-x64.exe"))
    .useSession {
        onScreen("welcome") { nextScreen() }
        onCurrentScreen {
            checkBox("acceptCheckBox").setSelected(true)
            nextScreen()
        }
        onAlert { clickYes() }
        onCurrentScreen { finish() }
        awaitExit()
    }

Test APIは、com.install4j:install4j-testとしてMaven Centralで公開されており、インストールのresourceディレクトリにinstall4j-test.jarとして同梱されています。

これらのGUIテストは、CIでヘッドレス実行することもできます。GitHub ActionsランナーのようにディスプレイのないLinuxでは、インストーラーのサブプロセスが自動的にxvfb-runと軽量ウィンドウマネージャーでラップされるため、インストーラーは仮想フレームバッファに描画され、物理的な画面なしでテストが実行されます。マシンに必要なのはxvfb-runと、サポートされているウィンドウマネージャー（metacity、mutter、openbox、fluxbox、marco）のいずれかだけです。

Java 25以降でANSI対応のターミナル上でインストーラーを実行すると、コンソールモードはモダンでインタラクティブなUIを描画するようになりました。

• 成功メッセージとエラーメッセージが際立つカラー出力。

  
• パーセント表示付きのライブプログレスバー。ステータス行と詳細行がスクロールアウトせずにその場で更新されます。長いファイルパスは途中が省略され、先頭と末尾が常に見えるようになります。

  
• 所要時間が不明な処理のためのスピナー。

  
• 矢印キーで操作する単一選択リスト。オプションメニューやはい/いいえ、OK/キャンセルの確認に使用されます。

  
• チェックボックスリストからの複数選択。

  
• テキスト入力とマスク表示のパスワード入力、およびタブ補完付きのファイル・ディレクトリ選択プロンプト。

  
• ライセンス契約書などの長いテキストのための組み込みページャー。オプションで、ユーザーに末尾までスクロールさせることもできます。

  

古いJavaバージョンで実行している場合や、出力をファイルにリダイレクトしたり別のプロセスにパイプしたりするなど、十分な機能を持つターミナルがない場合には、リッチレンダラーは自動的にプレーンなコンソールにフォールバックします。インストーラーに-J-Dinstall4j.plainConsole=trueを渡すことで、プレーンレンダラーを強制することもできます。

この機能により、install4j IDEをすべてのOpenJDK系ランタイムで、すべてのHiDPI解像度のLinux上で実行できるようになりました。以前は、HiDPI解像度のLinuxでサポートされていたのはJetBrainsランタイムだけでした。