GlassFishが重すぎる件

私はJavaが嫌いである。

ラムダ式やStreamが使えるようになったのはJava 8だ。数多の言語で当然のごとく利用できる機能がこれまで使えなかったというのが私がJavaを嫌う主たる理由である。そしてそれを加速させているのが仕事でJava EEを使うことが多いという事と、Java 8がエンタープライズ系システムで利用できるようになるのがいつになるのか全然分からないということだ。

今回私はJSF、GlassFish 3、NetBeans、Oracleと言った感じの開発環境で仕事をする羽目になり、初めてGrassFishやJSFに触ったのだが、これがまたしんどい。すっごくしんどい。

まず、何よりもGrassFishとNetBeansがメモリ食いすぎなのである。私の環境だとGlassFishが300~400MB、NetBeansが800MBくらいのメモリを食う。これに加えてChromeを起動してネットで調べながら開発を進めようとするとスワップし始める。これは良くない。

私の仕事用PCは4GBのメモリを積んでいる。確かに、昨今のPCに比べれば潤沢なメモリ量とは言い難いし、Chrome自体もメモリ食いなアプリであるとは言える。しかしそれでも食いすぎじゃないだろうか。たとえばMS系の開発環境でこんなにメモリ食ったことは無い。ネットで調べると「GlassFishは軽い」とか書いているところがいくつかヒットするが、信じられない。

そいでコードを編集して保存すると自動的にビルドして差分デプロイされすぐにチェックできるのは良いんだけど、これが頻繁にOutOfMemoryとかで失敗する。Java VMのメモリ確保量を変えればなんとかなるのかもしれないが、そもそもこういうところに手を入れてあげないとまともに動かないというあたりがイライラをさらに助長させる。さらに、これがきっかけかどうか不明だが、頻繁にGlassFishが暴走する。具体的にはIDE上からの一切の操作を受け付けなくなり、CPUをシングルスレッド分食いつくす。こうなると強制終了するしか無い。サーバとしてこれで大丈夫なのかと不安になる。

Node.jsやPlay Frameworkなどの最近の素敵な軽量フレームワークに触った後こういうことをすると本当がっくりくる。ため息が出る。まあ、フレームワークのターゲットが全然ちがうので比較すること自体がおかしいのかもしれないけれども、しかしそれでもこの重さに見合った素晴らしさがあるようにはとても思えない。

JSFも覚えることが多くて嫌になってくる。commandButtonなどはまだどういうHTMLが吐かれるか想像がつくが、PanelGridなどは名前からではどんなHTMLを吐くか、どういう結果が期待できるのかすら想像できない。すると調べるしかない。調べて覚えるしかない。調べて覚えた暁に、どんな嬉しいことがあるのか想像できない。大したメリットは無いのだろうと思ってしまう。

言語自体の古さにも嫌気がさす。早くJava 8が使えるようになってくれればいいのだが、今はまだラムダ式も型推論も高階関数も使えない。大量のgetter/setterを書いて長ったらしいクラス名を書いた後に変数を宣言してエディタの横幅に収まりきらない羅列を見ているともう…。ため息しか出ないのである。

なんで基幹系のシステムはJavaをベースにされることが多いの?何が嬉しいの?この問いを私は求め続けているが、いまだに納得できる回答にはたどり着けていない。その昔、大規模Web開発に対応できたのがJavaだけだったのでその名残であるとしか思えない。

「じゃあ使うなや」、そういう声が聞こえてきそうです。うんうん、その通りです。人間には良くない製品を使わないという選択肢があります。しかしビジネスシーンではそれが適用されないことが多いですけどね。「じゃあそんな会社辞めろや」うんうん、その通りです。以下略。

でも私がいくらギャーギャー騒いだところで潮流は変わらないでしょうから諦めて暗い顔をして私は毎日Javaと付き合っています。この状況が変わるのはJava 8が本格的に利用できるようになってからでしょう。

(追記)
twitterでツッコミが入ったので念のため書いておきますと、重いというのはメモリ食いだという意味です。レスポンスタイムやサーバのスケーラビリティの話ではないです。開発用PCでサーバとIDEを2つ動かすとメモリ食いまくってスワップする、ひでえ、って話です。