はじめに

IBM Application Modernization Accelerator(以下 AMA)が出す移行プランを IDE 上で実行できる拡張機能が IBM Application Modernization Accelerator Developer Tools(以下 AMA Developer Tools)です。次のような移行・アップグレードで必要なコード修正を支援します。

Tomcat、JBoss、WebLogic、WebSphere Application Server traditional(以下 tWAS)といった主要な Java ランタイムから Liberty への移行
Java のバージョンアップ
Java EE / Jakarta EE のアップグレード

VS Code、Eclipse、IntelliJ IDEA に対応していて、IDE 上で自動修正や手順ガイドに沿って作業を進められます。

今回はその一例として、JAX-RPC を使った tWAS 用のサンプルアプリを用意し、VS Code + AMA Developer Tools で次の移行ができるか試しました。

	移行前	移行後
ランタイム	WebSphere Application Server traditional 9.0.5.1	Liberty
Java SE	IBM Java 8	Java 25
Java EE / Jakarta EE	Java EE 7	Jakarta EE 10
Web サービス	JAX-RPC	JAX-WS(Jakarta XML Web Services)

結論

AMA Developer Tools は、Liberty への移行、Java のバージョンアップ、Java EE / Jakarta EE のアップグレードを 1 つの流れで進められるツールです。今回は tWAS のアプリで、この 3 つをまとめて試しました
移行プランを読み込むと、直すべき箇所が IDE 上で「自動修正」と「ユーザー主導の修正」に仕分けされて表示されます
javax.* から jakarta.* への置き換えや、WSSecurityHelper などの WebSphere 独自 API の置き換えは、「自動修正を実行」ボタンで適用できました
難所の JAX-RPC から JAX-WS への移行は、4 ステップのヘルパーが、WSDL・インターフェース・Bean の変換から、人が確認すべき項目の洗い出し、コンパイルまで順に案内してくれます
修正のあとに「リビルドして再分析」を押すと、問題が解消したことをその場で確認できます
指摘にはルールの説明と対象ファイルへのリンクがついていて、AMA の画面とエディターを行き来せずに作業できます

AMA Developer Tools を使うには適切なアクセスキーが必要です。画面右上の「アクセス・キー」から適用します。

検証環境

項目	内容
移行元の環境	RHEL 9 上の tWAS 9.0.5.1 / IBM Java 8
分析	AMA ディスカバリーツール(ama-discovery-5.0.1)と AMA
移行作業	VS Code + AMA Developer Tools
ビルド	Maven
移行先	Liberty(Java 25 は 25.0.0.10 以降で対応) / Java SE 25 / Jakarta EE 10

JAX-WS(xmlWS-4.0)は Jakarta EE 10 ではオプション扱いなので、Liberty では server.xml で明示的に有効にします。今回は AMA が出力した server.xml に入っていました。

サンプルアプリ

検証用に「Acme Inventory」という小さな在庫照会アプリを作りました。在庫データはメモリ上にあるだけで、DB は使いません。tWAS 上で、JAX-RPC のエンドポイントとクライアント経由の SOAP 呼び出しが動くことは確認してあります。

移行で引っかかるように、次のものを意図的に入れています。

分類	内容
JAX-RPC	`webservices.xml`、マッピングファイル、rpc/literal の WSDL、ハンドラー、`Stub` を使うクライアントなど
WebSphere 独自 API	`WSSecurityHelper`、`WsnInitialContextFactory`、`ResponseUtils`、`ibm-web-ext.xml` など
Java バージョンアップ	`Thread.stop()`、`new URL(String)`

全体の流れ

移行元のランタイム(今回は tWAS)上で AMA のディスカバリーツールを実行し、AMA で分析する
AMA から移行プランをダウンロードして、VS Code に読み込む
JAX-RPC から JAX-WS へ移行する
Liberty への移行、Java のバージョンアップ、Jakarta EE への移行(javax.* から jakarta.* への置き換えもここで行われます)
動作確認

1. 移行元のランタイム(tWAS)上で分析して AMA に取り込む

移行元のアプリが動いている環境(今回は tWAS)で、AMA のディスカバリーツールを実行します。

AMAの導入手順についてはこちらの記事をご参照ください。

完了すると zip ファイルが生成されるので、AMA にアップロードします。移行先には Java SE 25、Jakarta EE 10 を選びました。

分析の結果、想定どおりいくつか問題が検出されました。

JAX-RPC の項目にカーソルを合わせると、「JAX-RPC ソース移行ヘルパーが解決を支援する。AMA 開発者ツールで利用可能です」と表示されていました。この問題は AMA Developer Tools で対応できるようです。

2. 移行プランを VS Code に読み込む

AMA の画面から移行プランをダウンロードします。プランには server.xml、pom.xml、Containerfile などが含まれています。

VS Code でプロジェクト上のファイルを右クリックし、「Java アプリケーションのモダナイゼーション」→「Liberty へのモダナイゼーション」を選びます。

AMA Developer Tools の画面が開くので、先ほどの移行プランをアップロードします。

（移行プランがない場合でも、アプリケーションの分析は可能です。）

構成ファイルは server.xml だけを選びました。今回はコンテナ化しないので、Containerfile は選びません。

3. JAX-RPC から JAX-WS へ移行する

JAX-RPC が検出されると、自動修正を適用できる旨の画面が出ます。

JAX-RPC は Jakarta EE 9 で削除されています。そのため画面にも書かれているとおり、先に JAX-RPC から JAX-WS へ移行し、そのあとで javax.* から jakarta.* へ移行する順序になります。

「続行」を押すと、ツールが JAX-RPC のソースを調べて JAX-WS への変換を支援してくれます。

ヘルパーはプロジェクト内の WSDL ファイルを 1 つずつ処理します。このアプリで対象になったのは InventoryService.wsdl の 1 件です。

WSDL ごとに、次の 4 ステップがあります。

ステップ 1: 自動化を実行

「自動化を実行」を押すと、WSDL と関連する実装コードが JAX-WS 向けに変換されます。

ステップ 2: 手動更新

変換結果のうち、人が確認すべき項目が整理して表示されます。今回は 2 項目でした。

不要になった InventoryService_mapping.xml が自動で削除された、という通知(確認するだけ)
javax.xml.rpc.Service のクライアントが移行されなかった、という指摘(手で修正)

後者は、web.xml の service-interface を javax.xml.ws.Service に変え、クライアントのサーブレットで Stub を BindingProvider に置き換えるだけで済みました。Stub は Java EE 7 の API にあるため残してもコンパイルは通りますが、Liberty では実行時に失敗します。ツールも拾わないので、javax.xml.rpc を検索して残りがないか確認しておくと安全です。

ステップ 3: 新しく生成されたファイルを確認

JAXB のデータオブジェクトなどが生成されます。今回は ObjectFactory.java と package-info.java の 2 つで、何のために要るのかを確認して、どちらも残しました。

ステップ 4: アプリケーションをコンパイル

アプリをコンパイルして、残っている問題をエラーとして洗い出します。

今回は、ハンドラー(AuditHandler)とサービス実装(InventoryServiceImpl)でエラーが出ました。どちらも JAX-RPC 特有の書き方(ServiceLifecycle の init / destroy、throws RemoteException を前提にした例外など)が残っていた箇所です。エラーの行番号から原因がわかり、次のように直して解消しました。

ServiceLifecycle のメソッドを、@Resource(WebServiceContext の注入)と @PreDestroy に置き換え
RemoteException を WebServiceException に置き換え(JAX-RPC のインターフェースは java.rmi.Remote を継承して RemoteException を宣言しますが、生成された JAX-WS のインターフェースにはないため)
AuditHandler で、ツールが SOAPHandler に書き換えたあとも残っていた handlerInfo の参照を削除

コンパイルが通ってヘルパーの画面に戻ると、すべての自動化と手動更新が適用済みになっています。「ビルドして分析」でアプリケーションをビルドします。

ビルドが成功し、JAX-WS への移行が完了しました。「続行」を押して Liberty へのモダナイズに進みます。

4. Liberty への移行 / Java バージョンアップ / Jakarta EE への移行

ここからは、Liberty への移行、Java のバージョンアップ、Jakarta EE への移行にあたる作業を進めていきます。

自動修正

移行元の Java 8 / Java EE 7 から見て、直すべき箇所が一覧で表示されます。

自動修正できるものは「自動修正」タブにまとまっています。

自動修正ができる問題の一覧には、エラー 2 件、警告 1 件、情報 5 件が出ていました。エラーと警告は次の 3 つです。情報の 5 件は、Java SE 11 / 17 / 21 / 25 と Jakarta EE 10 についての一般的な注意です。

WSSecurityHelper.revokeSSOCookies() などの非推奨メソッドを使わない
InitialContext の JNDI プロパティをデフォルトにする
新しい Jakarta EE のパッケージ名を使うようにする(javax.* → jakarta.*)

「自動修正を実行」ボタンで修正を適用します。

すべての修正が適用されました。

たとえば LogoutServlet は、tWAS 独自の API から標準の Servlet API に置き換わりました。

LogoutServlet.java

-WSSecurityHelper.revokeSSOCookies(request, response);
+request.logout();

リビルドして再分析すると、これらの問題は解決済みになっていました。

ユーザー主導の修正

次に、人が内容を見て直す「ユーザー主導の修正」に進みます。今回は 2 件の問題(エラー)と 1 件の警告が見つかりました。

指摘	対象	対応
WebSphere Servlet API が新規の実装に置き換えられた	`EchoServlet`	`ResponseUtils.encodeDataString()` をやめて、HTML エスケープを自前で実装
ローカル以外のファイル URL に対する FTP フォールバックが無効化された	`StatusServlet`	`wsdlUrl` が http(s) で、ホスト名つきの file URL ではないことを確認。あわせて `new URL(wsdlUrl)` を `URI.create(wsdlUrl).toURL()` に変更
`Thread.stop()` などを避ける	`StatusServlet`	スレッドで強制終了する方式をやめて、接続と読み取りのタイムアウト設定に変更

修正してから再ビルドすると、問題が消えていることが確認できました。

追加情報

「追加情報」タブには、クラウドへ移行するときに確認しておきたい観点が、ルールの説明つきで並びます。

今回は次の 3 項目が表示されました。自分のアプリに当てはめて確認したところ、いずれも対応は不要でした。チェックリストとして使える形で出てくるのは便利です。

指摘	対応	理由
リモート Web サービス	不要	呼び出し先は同じアプリ内のサービスで、クラウド移行で届かなくなる外部サービスではない
クラウドへのアクセスに使う URL のホストとポートの検証	不要	エンドポイントはリクエストから実行時に組み立てており、WSDL の `localhost:9080` は使われない
Docker コンテナー内のアプリケーション構成の処理	不要	今回はコンテナ化しない

レポート

「レポート」タブからは、分析レポート、テクノロジーレポート、インベントリレポートの 3 つを開けます。

分析レポート：移行時に修正が必要な問題と、OpenRewriteで自動修正できる項目・手動対応が必要な項目を確認するレポートです。

テクノロジーレポート：アプリで使用しているJava EE技術が、Libertyなどの移行先で利用可能かを確認するレポートです。

インベントリレポート：アプリに含まれるServlet、JSP、EJBなどの数や構成を確認し、移行・テストの規模を見積もるレポートです。

5. 動作確認

必要な修正が終わったのでビルドすると、tWAS で動いていた Java 8 / Java EE 7 のサンプルアプリが、Liberty / Java 25 / Jakarta EE 10 のアプリとして動作していることが確認できました。

（表示はtWASと書いていますがちゃんとLibertyで動いています）

まとめ

AMA Developer Tools を使って、tWAS 上の Java 8 / Java EE 7 / JAX-RPC のアプリを、Liberty / Java 25 / Jakarta EE 10 / JAX-WS のアプリに移行できました。ランタイムの移行、Java のバージョンアップ、Java EE から Jakarta EE へのアップグレードを、同じ画面の同じ流れで進められたのが印象的でした。使ってみて良かった点は次のとおりです。

良かった点	今回の場面
直すべき箇所が仕分けされて出てくる	「自動修正」「ユーザー主導の修正」「追加情報」に分かれ、どこから手を付けるかが明確だった
機械的に直せるものはボタン 1 つで適用できる	`javax.` → `jakarta.`、`WSSecurityHelper` → `request.logout()`、JNDI 初期化の置き換え
難所の JAX-RPC → JAX-WS を手順に沿って進められる	4 ステップのヘルパーが、変換からコンパイルまで案内してくれた
人が判断すべき箇所に説明がついている	ルールの説明と対象ファイルへのリンクがあり、AMA の画面とエディターを行き来せずに直せた
直したことをその場で確認できる	「リビルドして再分析」で、指摘が解消したことを確認できた

JAX-RPC から JAX-WS への変換は、手作業だと WSDL の読み解きから始めることになります。それが、ヘルパーの案内に沿って進めるだけで、コンパイルが通るところまでたどり着けました。

最近は AI エージェントを使えば、ソースコードをあまり意識しなくても修正を進められるようになってきました。一方で、ミッションクリティカルなシステムや業務上重要なシステムでは、「何を、なぜ、どう変えたのか」を一つずつ確かめながら進めたい場面も多いと思います。

AMA Developer Tools では、機械的に直せる箇所はルールに沿って自動で変換されます。人の判断が必要な箇所は「ユーザー主導の修正」として、ルールの説明と対象ファイルへのリンクがついた状態で表示されます。どこを任せてよく、どこを自分で確かめるべきかが最初から分かれているので、変更内容を細かく確認しながらでも効率よく移行を進められます。

変更内容を一つずつ確かめながら、着実に Liberty への移行や Java・Jakarta EE のアップグレードを進めたい方には、ぜひ試していただければと思います。