話題のJavaライブラリ、Lombokを試してみた感想と良い点まとめ
少し前にLombokというJavaのライブラリが話題になったので、試してみました！
簡単に説明すると、**Javaでよくあるgetter/setterとか、コンストラクタをコード上に記述しないでよくなる（コンパイル時に自動生成）**というライブラリです。
使い方はひと手間必要で、eclipseで使うなら単純にjarをビルドパスに含める(pomに記述する)だけじゃなくって、lombok.jarを実行して、eclipse.exeにパッチか何かをあてないといけない・・・。この時点で「え？」と思いつつも、色々な記事を読む限りは便利そうなので続行しました。
以下、他の日本語サイトで書かれていなかったこととか、利点欠点を挙げてみます。
利点
@Dataすごい！
import lombok.Data;
@Data public class Person {
private String name;
private int age;
}
というように記述するだけで、setter/getterができるだけでなく、ToStringやEqualsなんかも生成されるようになります。そしてEclipse上でnameやageが使われていませんよ、というような警告が出ることもなし！他のコードでgetter/setterを利用しようとするとき、ちゃんとコンテンツアシストで補完が出てくる！
これは凄いです。eclipse.exeにパッチをあてたのは構文解析か何かの処理を変更するためだね、きっと。
@Builderすごい！
前述の@Dataは確かに凄いけど、「俺はJavaBeanパターンは好きじゃない。Builderパターンが使いたい」という人もきっと居るでしょう。俺はBuilderパターンのが好きです。
Builderパターンは一回何かを作るときに使ったことがある人なら分かってもらえると思うんだけど、とにかく記述するのが面倒です・・・。真面目に計算してないけど、普通のgetter/setterと比較したら3倍くらいコード多くなってしまうんじゃなかろうか。勿論EclipseにはBuilderパターンのコードを自動生成してくれるプラグインもあるけど・・・Lombokを使いましょう。
コードは面倒なので省略するけど、ほとんど@Builder付けるだけです。後は以下のような感じで使えるのでかなり楽で良いです。
Person p = Person.builder().name("tsukaby").age(17).build();
Effective javaなんかに載ってるBuilderパターンだと、Person.Builderをnewする方式だけど、Lombokではクラスメソッドであるbuilder()からnew Builder()を受け取るような感じです。これは初め気づかずにパッケージprivateなBuilderをnewしようとして混乱しました。
@ToStringのパラメータすごい！
前述の@Dataが万能すぎてこれだけでOK、かというと実際はそうでもないシーンがあります。例えば以下のようなコードがある場合、toString()を実行するとpassの中身まで見れてしまいます。
import lombok.Data;
@Data
public class Account {
private String id;
private String pass;
}
passの中身がなぜ見れてはいけないのか。例えばtoStringの結果をログ出力するシステムを作ったとすると、当然ログにはpassの値が出力されます。セキュリティぼろぼろ。
ではどうするかというと、@Dataと一緒に**@ToString(exclude = “pass”)**とやるだけ。これで安心です。
他にもちょくちょく便利だなーと思う機能があるので、一度はLombokの公式サイトでアノテーション一覧を見た方が良いかもしれないです。英語できついけど。
欠点
これは実際に試したわけじゃないから何とも言えないけど、多分そうなるだろうな、という想像です。
静的解析できなくなる？
Lombokを導入すればコンパイルはこけない。Eclipseも問題ない。けど、それはEclipseにパッチを当てたからであって・・・、パッチを当てないと当然こけます。学生だと中々機会は無かったけど、企業に入ると当然のようにソースに対して解析ツールを利用します。理由は様々でバグ減らしたり、その結果をもって品質が保たれていると判断するからです。多分、動的解析ツールであれば実行時の、つまり中間コードやメモリ上の値に対して処理を実施するからLombokを使っても大丈夫なんだけど、静的解析ツールは怪しいです。実際どのように作られているかは分からないけど、中間コードでなく、生のJavaコードに対して解析するタイプなら、多分色んなコードでgetter/setterがないよ！って言われてまともに動かないんではなかろうか・・・。
実際のところ試してないので、不明ですが。
コード生成されないから不安(実際はそこまで不安じゃない)
他のLombok紹介サイトでは、getter/setterの中身が生成されないので、デバッグとかで困るのでは、とあります。確かにそれは同感で、ちょっと怖いです。
でもLombokで隠れてる部分は別に大したコードではないし、そこにバグがある可能性は低いんじゃなかろうか。実際怪しかったとしても、中間コードを逆コンパイルして、それ使えば中身は普通に見られるし、不安と言えば不安だけど、それほどでもないかなーと。
知名度
Lombokの最大の欠点はEclipseに対するパッチだと思っていて、これがなければ最強かなと思っています。多分、十分にJavaやコードに強い会社・チームだったりすれば問題ないんだろうけど、大体の会社・チームは経験の浅いメンバーがコード書いたり、プログラムの管理が雑だったりします。
そんな訳で、実際分散開発とか保守とかそういう場面で、**「このコードgetter/setterがないんだけど、どうなってるの・・・」とか「(lombokとか知らないので、)普通にgetter/setter書きました」とか「保守フェーズだけど、lombokが分からなくて2日無駄にしました」**とかが起こるかもしれない・・・。自分の会社だと導入厳しいかもしれないな、と思いました。
まとめ
- Lombokを試してみた感想を記述
- @Data, @Builder, @ToString excludeなんかが良い
- 静的解析できなくなるかもしれないので、そこが怖い