それがC#を使った時に初めて感じた違和感だった。SEになってラムダ式をサポートした。メニーコアなCPUを使い切るには並列度を高める必要があるし、並列度を高めるためには並列処理の粒度を小さくして、かつ、書きやすくしなければならない。そのためにラムダ式は必須と言ってもいい。Javaはサーバでもよく動いているのだから、Javaでそういう流れが起きたのは当然と言っていい。これは遅きに失していると思う。Javaは保守的すぎる。私はそう思うようになった。それはC#の新しい言語機能が思った以上に有用だとわかったからである。C#のラムダ式とLINQに触れたとき、私が長年必要としていたものはこれだったんだと分かった。Pythonでリスト内包表記を覚えたとき、これはC#だけでなくて近代的なプログラミング言語の潮流なんだな、と理解した。演算子オーバーロードすら実装してくれないJavaに嫌気が差した。SEリリースでラムダ式がサポートされてStreamでmap/filterできますよ、なんて言われても何を今さら、と思った。私は今後、Javaを進んで使うことはないだろうと思う。我々は優れたオブジェクト指向設計をしたいのではなく、優れたシステムを簡潔に実装するためのツールとしてオブジェクト指向設計をするのである。オブジェクト指向に代わるより良い方法があるならば、それを柔軟に利用すべきである。Struts/JSP/Seaser2に触ったときここからが今回の記事の本題。いう、C#やPythonが好きな私がいきなりWeb開発をしなければならなくなり、仕事で初めてSeaser2に触って、あまりの古臭さにゲロ吐きそうになった。2014年に入ってから触ったので当たり前なのかもしれないけど。JavaBeansという仕組みに吐き気を催した。巷に流布するJavaBeansの仕様は以下のようなものですね。・引き数なしのコンストラクタを持つ・プロパティを持つ(setter/getter)メソッドやイベントを持てたり、シリアライズ可能にできるとかもあるんだけど、重要なのは上記2点だと考えています。JavaBeansって一体何が嬉しいの?C#にはこういうことをするためにプロパティという仕組みがある。実行時型情報を持っていて、リフレクションでプロパティを自由に操作できる。いちいちgetter/setterを定義するのは面倒くさい。C#を使ったときはプロパティなどという、たかがgetter/setterを置き換えるだけの目的で言語機能を拡張してしまうC#の思想のほうが嫌だったが、しかし使ってみるととても表記が簡潔になる。setter/getterだけで何行も書く必要はなくなる。言語機能としてサポートするだけの価値はある。次に嫌気がさしたのが、Seaser2のS2Daoだった。RDBMSにクエリを投げるために、引数をEntityと呼ばれるPOJOオブジェクトで指定してやる。それは直観かつ簡潔で良い仕組みだと思う。クエリを生成するところは結局SQLを書かねばならず、表記方法も特殊だ。/*empno*/このようにコメントでプロパティ名を指定してあげることで渡したEntityの内容を自動設定する仕組みになっている。empnoが空ならばWHERE節ごと削除されて実行される、などという機能もある。Frameworkがあった。EFを使えばラムダ式でクエリを書いてPOCOでデータを取得できる。書いたラムダ式はうまいこと式木に変換され、SQLに変換され、必要になった時に遅延実行される。EFは実行速度が出ないという弱点はあったけれども、方向性は間違っていないと思う。実装は改良していけるが、一度決めた設計思想はなかなか変更できない。大幅に設計思想を変更したら、それは別のフレームワークだ。それを考慮すると、私はS2Daoの設計思想がまず間違っていると思う。SQLに簡単にパラメータを流し込めるのではなく、簡単にクエリを書けるという方向に落とし込むべきであった。それはSeasarが悪いのではなく、ラムダ式の無いJavaで実装しなければならないという背景と、制作時期を考えれば仕方ないことであると思う。余談だが、Querydslは素晴らしいインタフェースを持つ。いわゆる「流れるようなインタフェース」で直観的にクエリを記述でき、POJOで結果を受け取れる。ラムダ式の無いJavaでよくもまあここまで頑張ったものだと思う。JSFに触ったとき「次世代のエンタープライズ向けWebフレームワークはJSFにGrassfishだ」と某社のそれなりに偉い人が言っていた。