【ITニュース解説】Why We Finally Fired Lombok (and How MapStruct + Records Saved Us)

Javaを用いたシステム開発において、開発者が書くコードの中には、プログラムの本質的な処理とは別に、決まりきった形式で何度も記述する必要がある「ボイラープレートコード」と呼ばれるものが存在する。例えば、ユーザー情報や商品情報といったデータを格納するためだけのクラスを作成する場合、それぞれのデータ項目（フィールド）に対して、値を取得するためのメソッド（getter）や、値を設定するためのメソッド（setter）、オブジェクト同士が等しいか比較するためのメソッド（equals）、そして効率的なデータ構造で利用するためのメソッド（hashCode）などを、一つひとつ手で記述する必要があった。これは非常に退屈な作業であり、コードの量を不必要に増やし、可読性を低下させる原因にもなっていた。

この問題を解決するために、長年にわたり多くのJava開発者に愛用されてきたのが「Lombok」というライブラリである。Lombokは、クラスに「@Data」や「@Getter」といった「アノテーション」と呼ばれる特殊な目印を付けるだけで、コンパイルの際に裏側で前述のgetterやsetterなどの定型的なメソッドを自動的に生成してくれる。これにより、開発者はデータ構造を定義するだけで済み、冗長なコードを記述する手間から解放された。コードは劇的に短くなり、開発者はビジネスロジックなど、より重要な部分の開発に集中できるようになった。この魔法のような手軽さから、Lombokは多くのプロジェクトで標準的に採用されてきた。

しかし、この「魔法」にはいくつかの代償が伴うことが徐々に認識されるようになってきた。Lombokの最大の問題点は、その「透明性の欠如」にある。アノテーションを付けるだけでコードが自動生成されるため、ソースコード上には存在しないメソッドが、あたかも存在するかのように振る舞う。これは一見便利だが、プログラムの内部で何が起きているのかを正確に把握することを難しくする。例えば、デバッグ作業中にエラーが発生した際、その原因がLombokによって生成されたコードにあるのか、それとも開発者自身が書いたコードにあるのかを特定するのが困難になることがある。また、Lombokを正しく動作させるためには、統合開発環境（IDE）に専用のプラグインを導入する必要があり、チームメンバー全員が環境を揃えなければならないという手間や、IDEのバージョンアップによってプラグインが動作しなくなるリスクも抱えていた。

このようなLombokが抱える課題に対し、Java言語自体の進化と、別のライブラリの活用という二つの解決策が登場した。一つ目が、Java 16から正式に導入された「Records（レコード）」という言語機能である。レコードは、不変なデータを扱うためのクラスを非常に簡潔に定義するための仕組みだ。「record User(String name, int age)」のように一行記述するだけで、コンパイラが自動的にコンストラクタ、各フィールドの値を取得するメソッド、そしてequalsやhashCode、toStringといった基本的なメソッドを生成してくれる。これはLombokの「@Value」アノテーションが提供していた機能の多くを、Javaの標準機能として実現するものである。標準機能であるため、特別なライブラリやIDEプラグインに依存することなく、誰でも同じように利用でき、コードの意図も明確になる。

そしてもう一つの解決策が、「MapStruct」というライブラリの活用である。システム開発では、データベースとやりとりするためのデータ構造（Entity）と、画面表示やAPI通信で利用するためのデータ構造（DTO）など、目的の異なる複数のデータ構造を扱うことが頻繁にある。このとき、EntityからDTOへ、あるいはその逆方向へ、データを一つひとつ手作業でコピーするコードを書く必要がある。これもまた、間違いやすく退屈なボイラープレートコードの一種だ。MapStructは、このオブジェクト間のデータ変換（マッピング）処理を自動化するためのライブラリである。開発者は、どのような変換を行いたいかをインターフェースとアノテーションで定義するだけでよい。するとMapStructは、コンパイル時にその定義に基づいた具体的なJavaのクラスファイルを自動生成する。重要なのは、Lombokのように裏側で動作するのではなく、開発者が直接確認できる実装コードとして生成される点だ。これにより、どのような処理が行われているかが明確になり、透明性が高く、デバッグも容易になる。

記事の筆者たちは、Lombokの持つ「魔法」の裏側にある不透明性やツールへの依存といった問題点に直面し、Lombokの利用を中止するという決断を下した。そして、その代替として、データクラスの定義にはJava標準のレコードを、オブジェクト間のデータ変換には透明性の高いMapStructを採用した。この移行により、コードの冗長性を排除するというLombokのメリットを維持しつつ、コードの可読性、保守性、そしてデバッグの容易さを大幅に向上させることに成功した。この事例は、便利なライブラリがもたらす恩恵と、それに伴うリスクを天秤にかけ、言語の進化や代替技術を取り入れながら、より堅牢で理解しやすいシステムを構築していくことの重要性を示している。