Java による Web アプリケーションのプロトタイプのために最近使っている構成

2014 年 5 月 3 日に開催された「Kyoto.なんか」という勉強会で、最近 Java で web アプリケーションのプロトタイピングするとき使っている構成について喋りました。最近個人的に愛用している構成です。

Java による Web アプリケーションのプロトタイプのために最近使っている構成 from Yu Nobuoka

補足

TypeScript コンパイラを Nashorn 上で動かしたときになんで遅いのかまでは調べてない。
- Nashorn 上で動かすために IO 周りのコードを書いただけなので、自分がなんかミスったとかではないと思うけれど。
- そのうちもうちょっと調べたいとは思ってるけど、そもそも Nashorn 上で動かすのは難しい気がしてる。
テンプレートエンジンはとりあえず Velocity を使ってるけど、これがいいとは思ってない。
- 型安全性の高いテンプレートエンジンを自分で書いたりもしたのだけれど、型安全性を求めすぎてそれはそれで使いにくかった。
- 最近は Java 8 のラムダ式とかそこら辺の機能を使って、いい感じに型安全性を持たせつつ扱いやすいテンプレートエンジンを書けるのではないかと思ったりしてる。
- あるいは Groovy コンパイラとか Nashorn を使って扱いやすいテンプレートエンジンを作るとか。

懇親会で話したことなど

Grizzly、非同期 IO って言ってるけど、リクエスト処理の内部で同期的な IO を使ってたらだめですよね?
- 確かに。
- 単に Jersey が対応している非サーブレットコンテナな HTTP サーバーという理由で選んでたのでそこまで考えてなかった。
- そのうち調べたい。
- Play Framework は Netty を使ってるけど、そこら辺ちゃんと API が提供されてる気がする、とのこと。
Velocity はちょっと古い気がする。時代は FreeMarker か Thymeleaf じゃないの?
- まあうちも Velocity 使ってるんだけどね、とのこと。
- そのうちそれらも真面目に使ってみようかと思う。
- ちなみになんで Velocity を選んだかというと、次の記事あたりを見て、汎用性と枯れてて安心できそうという面で Velocity が良いのかなーと思ったという感じ。
  - Template Engineの比較(Java) - No Bugs, No Life
  - Shootout! Template engines for the JVM
JAX-RS で、ルーティングが分散するの面倒じゃないか? ルーティングのルールは 1 箇所にまとめたい感。
- それは思う。
- が、Java 7 的世界観ならアノテーションであんな感じに書くのが全体的には幸せになれそうな気がする。
- 命名規則でカバーという感じ。
GC について。
- 某サービスでも Full GC が走ってサービス再起動を余儀なくされたことが何度かある、とのこと。
- 例えば、ユーザーの入力次第で多くのメモリ容量を使用するようなコードになっている箇所があって、それの影響で Full GC 走ってしまった、とか。
- そういうときはサービスを再起動して、ヒープダンプから原因箇所を特定してコードを変更して対応する、らしい。