Experience on Automatically Converting a C++ Monolith to Java EE

この論文は、80 万行の C++ モノリスを Java EE（WildFly）へ移行する際のアプローチや課題解決、および継続的な C++ 開発に対応するための Clang ツールを用いた自動変換手法についての実践経験を報告したものである。

要約

1. プロジェクトの背景：なぜこんなことをしたのか？

ある物流会社は、社内のあらゆるシステム（倉庫管理、印刷、輸送最適化など）を、昔ながらの**「C++」**という言語で動いていました。しかし、これには 3 つの問題がありました。

• 規模が巨大: 80 万行ものコード（本 800 冊分くらいの量）。
• 人材不足: C++ の職人は減り、Java の職人は多い。
• 開発の継続: 変換中に、新しい機能追加やバグ修正も C++ 側で続けなければならない。

そこで、「手作業で書き直すのは無理だ」と判断し、**「ボタン一つで C++ を Java に変える自動ツール（トランスパイラ）」**を作ることにしました。

2. 変換ツールの仕組み：「翻訳ロボット」の正体

このツールは、**「Clang」**という C++ の文法を完璧に理解する「頭脳」を使って動いています。

• 読み取り: C++ のコードを「構文木（AST）」という、木のような図に変換して理解します。
• 変換: その図を元に、Java のコードを生成します。
• テンプレート: 「C++ のこの部分は、Java ではこう書く」という**「型紙（テンプレート）」**を大量に持っています。例えば、C++ の「文字列結合」は、Java では「StringBuilder」という道具を使う、といったルールです。

3. 直面した「3 つの大きな壁」と解決策

C++ と Java は似ているようで、根本的に違う部分があり、ここが最大の難所でした。

壁①：「複数の親を持つ」問題（多重継承）

• C++ の状況: 一つのクラスが、複数の親クラスから能力を引き継げる（例：「犬」が「動物」かつ「ペット」の両方の性質を持つ）。
• Java の壁: Java は「一つの親しか持てない」ルールです。
• 解決策（変身術）:
  • データベース関連: 「親になる」のではなく、「道具として持つ」ように変えました（例：「犬は動物だ」→「犬は動物の服を着ている」）。
  • チェーン（命令連鎖）関連: 親から命令を受けるのではなく、**「指揮官（マネージャー）」と「兵士（リンク）」**が交代で命令を渡すように仕組みを変えました。
  • その他: どうしようもない数少ないケースは、人間が手作業で修正し、C++ が変わったらアラートが鳴るようにしました。

壁②：「列挙型（enum）」と「数字」の混同

• C++ の状況: 「色（赤、青）」という列挙型を、単なる「数字（0, 1）」として扱ったり、逆に数字を無理やり色に変えたりするのが自由でした。
• Java の壁: Java は厳格で、「数字を勝手に色に変える」ことは許しません。
• 解決策（変装術）:
  • 列挙型を、**「数字を隠し持つ特別なオブジェクト」**として作り変えました。
  • C++ で「赤＝0」としていたのを、Java では「赤というオブジェクトの中に 0 が隠れている」という形にし、数字に変換するメソッドを用意しました。これにより、Java の厳格なルールを守りつつ、元の C++ の挙動を再現しました。

壁③：「資源の片付け」（デストラクタ）

• C++ の状況: 関数が終わると、自動的に「メモリやデータベース接続」などの資源を片付ける（デストラクタ）仕組みがありました。
• Java の壁: Java には「自動片付け」の仕組みがなく、ゴミ収集（ガベージコレクション）がいつ来るか分かりません。
• 解決策（契約書）:
  • Java には**「Try-with-resources」**という、資源を使うときは「使い終わったら必ず閉じる」と約束する仕組みがあります。
  • ツールは、C++ の「資源を使うクラス」を特定し、自動的にこの「契約書（Try ブロック）」の中に囲むようにコードを書き換えました。

4. 結果：成功への道のり

• エラーの減少: 変換当初はエラーが山積みでしたが、ツールを改良するにつれて急激に減っていきました。特に「型（数字と文字の区別）」を正しく扱う仕組みを導入した時期に、エラーが劇的に減りました。
• 最終成果: 80 万行のうち、約 99% 以上は自動変換されました。残った数少ないエラー（約 60 個）は人間が手直しし、無事に Java のサーバー（WildFly）上で動作しました。
• 継続性: C++ 側で開発を続けながら、変換ツールを回し続けることで、常に最新の Java コードを維持できました。

まとめ

この論文は、**「巨大なレゴ城を、壊さずに別のブロックに作り変える」という不可能に見える挑戦が、「賢い翻訳ロボット」と「人間の知恵（ルール作り）」**の組み合わせによって成功したことを示しています。

単なる言語変換ではなく、「建築様式（アーキテクチャ）」そのものを変えるという、非常に高度な工事だったのです。

技術概要

論文「Experience on Automatically Converting a C++ Monolith to Java EE」の技術的サマリー

本論文は、物流ソフトウェア企業において、80 万行規模の C++ モノリシックアプリケーションを、Java EE（WildFly 上での実行）および Java 8 へ自動変換する試行と、その過程で直面した技術的課題、解決策、および成果について報告したものです。開発中の C++ コードベースを維持しつつ、自動変換ツール（トランスパイラ）を用いて Java へ移行するアプローチが採用されました。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

1. 問題定義 (Problem)

• 大規模コードベースの変換: 80 万行の C++ コード（約 2,500 ファイル、3,000 クラス）を人手で Java に書き直すのは非現実的であり、エラーのリスクが高い。
• アーキテクチャの転換: 単一のモノリシックな C++ アプリケーションを、Java アプリケーションサーバー（WildFly）上で動作するモダンなアーキテクチャへ変更する必要がある。
• 並行開発の制約: 変換プロセス中は C++ 側での新機能追加やバグ修正が継続していたため、手動変換ではなく、C++ への変更を反映して Java コードを継続的に再生成できる自動化ツールが必要だった。
• 言語間の構造的差異: C++ と Java には以下のような根本的な違いがあり、単純な置換では対応できない。
  • 多重継承（Multiple Inheritance）の存在。
  • enum と int の暗黙的な相互変換。
  • スコープ付きオブジェクト（RAII パターン）によるリソース管理（デストラクタ）。
  • ストリーム入出力（std::ostream など）の存在。
  • 例外処理の有無と扱い方の違い。

2. 手法とアーキテクチャ (Methodology)

著者らは、LLVM/Clang フレームワークの clang-tool を基盤とした自動変換ツール（トランスパイラ）を開発しました。

• ツールの構造:

  • AST 解析: Clang のフロントエンドを用いて C++ コードを抽象構文木（AST）に変換。
  • Visitor パターンの活用: ConstDeclVisitor, ConstStmtVisitor, TypeVisitor などを継承した「トランスパイル・ビジター」を実装し、AST を走査して Java 相当のコードを生成。
  • テンプレートエンジン: 生成される Java コードは、C++ の構文ごとのテンプレート（例：キャスト、ストリーム演算子）に基づいて生成される。
  • 自由関数とメンバ関数のマッピング: C++ の自由関数（atoi など）や STL 関数（std::string のメソッドなど）を、Java の静的メソッドやクラスメソッドへ変換するテーブル（マッパー）を定義。
  • 型推論とインポート管理: C++ の型を Java の型にマッピングし、必要なパッケージのインポートを自動的に追跡・生成する。

• 開発プロセス:

  • 変換された Java コードはビルドシステムに組み込まれ、C++ コードのチェックインごとに自動再生成される。
  • 完全な自動化は困難なため、「チェックド・リプレイス（Checked Replace）」方式を採用。変換結果が既知のテンプレートと一致しない場合、手動修正済みの Java ファイルで上書きする仕組みを導入し、C++ 側の変更による影響を監視した。

3. 主要な技術的貢献と解決策 (Key Contributions & Solutions)

C++ から Java への変換において直面した主要な課題に対する具体的な解決策が提案されています。

A. 多重継承 (Multiple Inheritance)

Java は多重継承をサポートしないため、以下の戦略で対応しました。

• DAO（Data Access Object）の場合: 「is-a」関係を「has-a」関係へ変換。DAO クラスをメンバ変数として保持するようにリファクタリングし、アクセスを this.getDAO() から m_oDAO.getDAO() へ変更。
• Chain of Command パターンの場合: 連鎖的な制御フローを、チェーンマネージャとリンク間の「制御の受け渡し」パターンへ変更。Java のスタックを利用して逆方向のトラバースを処理。
• その他の場合: 抽象クラスを Java のインターフェースに変換し、implements として記述。変換が不可能な少数のクラス（5 未満）は手動で修正し、ビルドプロセスで監視するガードを設けた。

B. ストリーム入出力 (Stream I/O)

• std::cout などのストリーム演算子を、StringBuilder による文字列連結へ変換。
• std::endl の有無に応じて、System.out.println または System.out.print を使い分ける。
• 連結が不要な場合は StringBuilder の生成を省略し、直接出力する最適化も実施。

C. Enum と Int の変換 (Enum vs. Int)

C++ では enum と int の自由な変換が可能だが、Java では厳格であるため、以下の構造へ変換した。

• Enum のクラス化: C++ の enum を、内部に int 値を持つ Java クラスとして表現。
• コンストラクタとメソッド: 数値から Enum オブジェクトへの変換には forNum() メソッドを使用し、無効な値の場合は例外を投げるようにする。逆に、Enum から数値へは asNum() メソッドを使用。
• これにより、C++ のような不正な数値代入を Java 側で検知・防止し、データベースインターフェースとの整合性を保った。

D. コンストラクタとデストラクタ (Constructors & Destructors)

• RAII パターンの変換: C++ のデストラクタによるリソース解放（特にデータベースカーソル）を、Java 7 以降の「Try-with-resources」構文へ変換。
• 実装: デストラクタにリソース解放ロジックがあるクラスを特定し、Closeable インターフェースを実装するように変換。ただし、空のデストラクタが多いため、手動のコメント注釈（アノテーション）でリソース使用クラスを特定し、try-with-resources ブロックを生成するアプローチを採用した。

E. 例外処理 (Exceptions)

• C++ 側ではエラーコードで処理されていたが、Java 側では例外が一般的。
• 本プロジェクトでは、サードパーティライブラリの例外をラップするか、チェーンマネージャや各リンクの呼び出し周りに try-catch を追加する案が検討されたが、最終的な決定はプロジェクト終了時点で行われていない（コスト対効果の検討中）。

4. 結果 (Results)

• エラー数の削減: 変換プロセスを通じて、Java のコンパイルエラー数は時間とともに劇的に減少した（図 12 参照）。特に、Java 型システムを導入して型キャストと Enum/Int 変換の誤りを検知・修正した段階で、エラー数が急減した。
• 最終的な状態: プロジェクト終了時点で約 60 個のエラーが残存したが、これらは手動修正され、変換された Java コードは正常に実行され、基本的な操作が可能であった。
• 自動化の成功: 80 万行のコードのうち、約 10 クラスを除いて自動変換が可能であり、残りの手動介入も限定的であった。

5. 意義と結論 (Significance & Conclusion)

• 実用的な大規模変換の成功: 80 万行規模のレガシー C++ コードを、アーキテクチャ変更（モノリシックから Java EE）を伴いながら、自動ツールを用いて実用的なレベルまで変換できたことは、大規模システム移行の重要な事例である。
• 継続的変換の重要性: C++ 側での開発を継続させつつ、ツール駆動で Java 側を同期させるアプローチは、移行期間中のビジネス継続性を確保する上で有効であった。
• 技術的知見: 多重継承、リソース管理、型システムの違いなど、C++ から Java への移行特有の難問に対して、パターンベースの変換（DAO の「has-a」化、Chain of Command の再設計、Enum のクラス化など）が有効であることを示した。
• 今後の課題: 例外処理の戦略や、完全な自動化に向けたさらなるルールの整備が必要であるが、今回のアプローチは「完全自動化」への道筋を示すものとして成功と評価されている。

本論文は、単なるコード変換ツールの実装だけでなく、ドメイン知識（物流、DAO、チェーンオブコマンド）を反映した高度な変換ロジックと、実運用環境での継続的メンテナンス性を考慮したプロセス設計の重要性を浮き彫りにしています。