で紹介したツールのコード生成のベースとなっているプロジェクトについて紹介したいと思います。
概要
本プロジェクトを使用することでのメリット
- AnnotationProcessorを統一的に操作できます
- 定義用XMLで外部からパラメータを指定できます
- 各Elementの操作のヘルパーが準備されています
- テストが統一的に行えます
拡張のやり方の詳細については、Sampleとして、READMEに既出の「プロパティファイルからEnumを生成する」の実装内部の説明をしていますので、そちらをご確認いただければと思います。
maven/org/vermeerlab/annotation-processor-javapoet at mvn-repo · vermeerlab/maven · GitHub
Code
コード生成するプロジェクト自体を拡張したい場合は、こちらのコードを参照してください。
コンパイル時にコード生成すると何が嬉しい？
自動生成というと、いわゆる「超高速開発ツール」などと言われる、エクセルなどから作成したコードを使用するパターンがあると思います。
あくまで私の過去の経験ですが、ツールによる自動生成で課題に思ったのは「ドキュメント（もしくは それに準ずる資産）と 生成されるコードの版数が一致しないこと」です。
開発者がドキュメントから必ずコードを生成してくれれば良いのですが、手に届くところにコードがあるということで、どうしても直接コードを修正してしまうことがあります。
そうなってしまう理由は色々とありますが、いずれにしても、こうなると結構しんどくて、結局 コードが正しいとならざるをえず「ドキュメントは後回しになっている自動生成してはいけない機能」みたいな謎ノウハウが生まれます*1。
AnnotationProcessorによるコード生成は、参照資産と常に一致した状態を保てるところが 大きなメリットです。
AnnotationProcessorにより自動生成したコードは、実質「クラスファイル」と同レベルです。
targetフォルダに、生成したコードとして確認することはできますが、コンパイル都度 再作成されるためです。
アイディアとして
今回、私はプロパティファイルからEnumクラスを作成しましたが、エクセルを入力資産に指定することも可能だと思います。
よく揶揄されるように思う*2 SIer＋自動生成 ですが、AnnotationProcessorという仕組みと組み合わせると、Java標準の技術の範疇でビルドプロセスの中に組み込めるので色々と面白いことができるような気がします。
自動生成ツールと別アプローチとして結構有効だと思いますので、SIerの共通部品とかフレームワークとか開発支援とか言われるチームの方は、一度 検討されてみては？と思います。
懸念
資産からコードを生成した上でコンパイルをするため、資産が増えてくると コンパイルする時間が長くなって無視できなくなることが懸念されます。
思いつく対処としては、以下など考えられます。
プロジェクトを分けて分割コンパイル
単純ですが、それなりに効果はあると思います。
例えば 更新頻度が高い資産と、低い資産を分けるというような やり方はどうでしょうか？
更新管理ファイルを保持する
ファイルのタイムスタンプ比較するための更新管理ファイルを設けて、AnnotationProcessorの#initで読み込むようにすれば クローン後の初めの一回は重いかもしれませんが２回目以降は早くなることが期待できます。
さいごに
AnnotationProcessor + maven + classloader（リフレクション）で踏める地雷は大体踏んだと思っています。
本ブログを読まれて「こんなことできるのかな？」ということがありましたら、出来る範囲でお答えしたいと思いますので、気軽にご連絡いただければと思います。
