「Javaの鉱脈」連載開始

WEB+DB PRESSのVol.81からJVMを中心とした連載を始めましたので是非買って下さい。

2014/6/24発売です。書店には既に並んでいるかと思います。

これはアマゾンのアフィリエイトリンクですので、踏んだ直後に冷蔵庫等の大型家電を購入して頂けると僕が喜びます。

電子書籍版もありますので物理的な媒体に興味がない方はPDFを買って下さい。

初回の内容はラムダ式 + RxJava

今回の内容としてはJava8のラムダ式に関する簡単な説明から、ラムダ式を利用してRxJavaを使うとこんなに便利という話を書きました。

記事内でStream API に関して説明しなかった最大の理由はラムダ式とStream APIに関する適切で妥当な説明については桜庭さんの記事を読めば良いと考えているからです。

正直に申し上げて、僕も桜庭さんの記事待ちをしています。

次点の理由としては、僕が現在のStream APIを難解な割に既存のAPIとの親和性が低すぎて使えないと考えているからです。

まず、難解な部分としてはcollectメソッドを第一に挙げておきます。

僕の能力が足りない可能性については否定しませんけども、API ドキュメントを読んでもどう使えば良いかサッパリ分かりません。

Javaにおける既存のAPIはチェック例外をどんどん送出しますけども、Stream APIはチェック例外のある処理を非常に書き辛いのです。java.util.function.BiFunction#apply等を見れば分かりますが、Stream APIには例外オブジェクトを使ったエラー処理という概念が、そもそも存在しないのです。

それに対してRxJavaを使うとキチンとしたエラー処理が記述できますので、既存資産との親和性がキープされます。

AkkaReactorRxJavaが集まってReactive Streamsという新しいJSRを作る試みが始まっています。

このAPIがそれなりに妥当な形で定義されれば、現状の残念なStream APIが大きく改善されますので、それを先取りする意味でもRxJavaを学んでおく価値があると僕は考えています。

記事を書きながら悩んだこと

非常に細かい点なのですけども、今回の記事を書いていてFRP(Functional Reactive Programming)をスタイルと書くかパラダイムと書くか非常に悩みました。

  • 少なくとも既に解決できている問題の大部分を代替できるわけではない

    • 「FRPが向いている領域」とFRPが向いてない領域」がある
  • 既存のやり方に比べて大幅に生産性や品質が向上するわけではない

    • Javaでオブジェクトが状態を維持しないモデルのコードを書くのは明らかに難しい

ことから、僕はFRPをある種のプログラミングスタイルであってプログラミングパラダイムと呼べるほど大げさな違いでは無いと結論付けましたので、記事内ではFRPをスタイルであると説明しました。

異論や反論はあってしかるべきだと考えていますので、twitterなりブログなりで意見を聞かせていただけると嬉しいです。

最後に

記事内で説明していないコードがサンプルコードには含まれていますので、是非お試し下さい。