Scala使いがまともなJava開発環境を模索する(続き)

「Scala使いがまともなJava開発環境を模索する」という、簡単に言えば「ぼくの考えた最強のフレームワークセット」みたいな記事を書いたのですが、実際に仕事でそれらをそれなりに使ってみたのであんまり為にはならない感想を書きます。

Spring Boot(Webフレームワーク)

前回も書きましたが、JavaではやっぱりSpringBootが一番じゃないかなぁという気がします。Strutsを触ったことがほとんど無いのですが、SpringはStrutsに比べるとかなりXML地獄感が無くなったということを伝聞で耳にしていました。それが本当かどうかは知らないし確かめようとも思わないのですが、私はSpringもまだまだXML地獄であって使いにくいように思います。

Spring BootはそのXML地獄をAnnotation地獄というちょっとマシな記述方法に変化させてくれたという点が功績なのだと私は勝手に思っているのですが、その点だけでもSpring Bootを使う価値はあると思います。

ただ、Annotationも「マシ」であって地獄には変わらない気がします。記述量はそこまで多くないのですが、annotationベースの処理では処理の対象と実際の処理が分離してしまって何かあったときにコードを追っていくのがとてもしんどいです。また、あるannnotationを付けたときにどういう動きになるかというのはドキュメントをしっかり読まないと分からないことが多く、この点もしんどいです。

ドキュメントをしっかり読むのは当然だろうと言われそうですが、しかし、自分が今まで触ってきたフレームワーク(ExpressとかPlayとか)は大体ノリで学習を進めることが出来て、何か壁にぶち当たった都度ドキュメントをあたって正確な情報を仕入れるというやり方で覚えてこれたのですが、Spring Bootはそういうやり方をすると泥沼にはまってしまいます。それが良いのか悪いのか、私だけがそうなのかとかまでは判断付かないのですが、とりあえず私はそういう感想を持ちました。

ScalikeJDBC4J

結局これは私のプロジェクトでの採用は見送りました。それは根強いScala反対論があったからです。ScalikeJDBC4Jは各種メソッドのJava 8以降向けラッパークラスを同封したようなものになっているのですが、肝心のSQL構築部分はScalaで書く必要があります。Scalaを使わないとScalikeJDBCのQueryDSLとかStringInterpolationとかが使えないからです。それらが使えないのであれば正直ScalikeJDBCを使うメリットもあんまりありません。だから、部分的にScalaでコードを書くようになっているのだと理解しています。

で、私は「データアクセス部分だけだから!ここだけScalaを使わせて!」と主張しました。徐々にScalaを浸透させていきたいという魂胆ですね。また、Scalaを使うとこんなに便利ですよ的な啓蒙活動も社内ではずっとやってきました。でもまあ何だかんだあって結局それは失敗に終わってしまったので、他のDBアクセスライブラリ(O/Rマッパ)を探すこととしました。

ちなみに、Scala反対派の意見を集約すると「Scalaはシンタックスが分かりにくすぎる。理解の困難さはC言語→Javaの比ではない」「Scalaはスタンダードにはならない。Javaの代替にはなりえない。数年後消えているエコシステムかもしれない」というあたりでした。この点に関しても色々思うところはあるのですが、省略。

あと、もう一つ多かった意見が「S2JDBCを使いたい」というものでした。うちの課では私がやってくる前にはSeasar2をメインに使っていたそうですが、ご存じのとおりSeaser2は開発が終わりました1

私は2Way SQLという書き方があんまり好きじゃないのですが、私の好みで開発メンバのスキルを捨てるというのも変な話なので2Way SQLを書けるというメンバのスキルを活用しようという方向に切り替えました。

色々検討した結果、MirageをSQLパーサとして使い、データベースアクセスは標準のSpring JDBC(JdbcTemplate)を使うのが無難ではという話に落ち着きました。パーサとして使う点については、下記記事が詳しかったです。

2Way SQLパーサとしてのMirage, Doma, Clione-SQLの比較

Typesafe Config

これも先の記事で書きましたが、Typesafe Configを導入したからと言ってapplication.propertiesを代替できるわけではないので、部分的に使うといった感じです。あまりあっちこっちに記述を増やしても分かりにくくなるだけなので、「この機能に関してはapplication.propertiesじゃなくてTypesafe Configを使って書くよ(そっちの方が便利だから)」というコンセンサスを作ってから導入しました。

Thymeleaf

ThymeleafはValidなXMLを要求するので何かと使い勝手が悪く、しかしだからと言ってThymeleafよりも明確に良いと思えるようなテンプレートエンジンも無く渋々使っていたという感じなのですが1か月くらい前にSpring Bootが1.4になり、Thymeleaf 3を使えるようになりました。Thymeleaf 3はそのValidなXMLを要求していたというあたりがかなり柔軟になって、JSONデータなんかも出力できるようになりました。詳しくはmigration guideをどうぞ。

ちなみに、Spring BootでThymeleaf 3を使うには

<properties>
    <thymeleaf.version>3.0.0.RELEASE</thymeleaf.version>
</properties>

を追加する必要があります。

ちなみにReactとかAngularを使うからテンプレートエンジンはあんまり使わないなぁ…という現場も多くなってきているのかもしれませんが、私の周囲ではjQueryでゴリ押し派が主流です。

Lombok

Getter/Setter/コンストラクタの生成に使っています。前回も書きましたが、IDEがあれば自動生成できるから良いじゃんという意見も確かにありますが、自動生成するのを忘れたり、一つ追加するだけだからと手動で追加して何かミスったり、コードが無駄に長くなったりということが完全に解決されたので気に入っています。

ただ、型推論のvalはなんだか思ったように動いてくれません。IntelliJのプラグインの問題なのかもしれませんが、IDE上ではエラーになるのにコンパイルは成功する、またはその逆というパターンがいくつかありました。あと、ラムダ式の内部では使えないっぽい?とか、型パラメータが入ってくるとうまく推論してくれない?とかなんだか動作が怪しいところが多々あり、こちらはほとんど使っていません。

Maven

これも前回書きましたが、やっぱりpom.xmlがまだまだXML地獄感があります。しんどいです。Gradleにした方が良かったかなあ…。


  1. 主要な開発メンバが開発を止めただけ?