Java を Scala の中で使うこと

ScalikeJDBC は手軽なはず

ScalaでORマッパーというとSlickやScalikeJDBC等色々あるが、ほんとにちょっとしたツールを作りたいだけならばもっと手軽にやりたいと思うはず。

ScalaでDBを使った小物ツールをサクッと作れるJDBI - 気まぐれラボラトリィ

手軽ですよということを示すためにちょっとしたサンプルを書きました。ScalikeJDBC や Skinny ORM のミニマムな導入方法としても参考になるかなと思います。

https://github.com/seratch/jdbi-scalikejdbc-skinny-orm-example/blob/master/src/main/scala/app.scala

JDBI については私も結構好きなんですが Java であることの限界が見えてしまっている感はあります。SQL をアノテーションに書くわけですが、改行もできないですし、アノテーションに渡す文字列はベタ書きするしかないので、こういう簡単なケースではなく、それなりの SQL を書くとなるとかなり苦しいと言わざるをえません。

また Java ライブラリ一般に言えることとして @BeanProperty とか Java っぽいアノテーション駆動な処理が入るコードでは Scala の恩恵を受けづらいことが多いと思います。コンパイルの重さを考慮するとそういうケースでは Groovy の方がよかったりするかもしれません。

今更という気もしますが、ちょうどよい機会なので Scala の中で Java を使うことについて意見を書いておこうかなと思います。

いざとなれば Java の既存コードをそのまま使えるのは Scala のよいところなのですが、あくまで「いざとなれば」というオプションであり、かなりニッチな分野であればまだしも、RDB アクセスのようなありふれたユースケースではファーストチョイスが Java の利用とは考えない方が幸せになれると思います。

自分自身を振り返っても Scala を始めた頃は「手慣れた Java のライブラリを使ってやった方が楽なのでは？」と思ったりしたものですが、結局 Java と Scala の架け橋となるところをケアしながら書かないといけないので簡潔にはなりにくく、落とし穴もあったりします。

例えば null は Scala の世界では「なかったこと」になっていて Option にしてあげないといけないですが、そういうことをやってくれる Java のライブラリはまずないので Java の API からの戻り値を自分で Option で包んであげないといけなかったりします。また Scala のコレクション型のオブジェクトは Java の世界からはうまく扱えないので Java の世界に渡す前に必ず scala.collection.JavaConverters なりで変換してあげる必要がありますし、逆に java.util.List などが Java から返ってくれば毎回 #asScala を呼んで変換する必要があります。

どういうときに Java を混ぜるか

ということで Scala であえて Java API を使う場合というのは、既に Java で SDK が提供されている場合だったり、よほど Scala で実装されたライブラリで選択肢がないケース（枯れてない、難解すぎる、機能が足りない、メンテされてないなど）に限るのがよいかと思います。

「どうしてもこの Java ライブラリを流用したい」というケースはあるかと思いますが、それほどのものなのであれば自分で Scala ラッパーを書いてみることも検討してもよいでしょう。OSS として公開すれば一定の需要もあるかもしれません。

以上、あるべき論で Scala らしいコードを書くべきということではなく「（ニッチなケースでなければ）普通は Scala ネイティブなやり方をした方が結果的に楽ですよ」という話でした。