なぜ Java なのか。
■なぜJavaを選ぶのか？〜JavaOneTokyoに期待すること
という記事を見付けました。
以前から私が思い感じていたことと、とても重なっていて共感を覚えます。
hatena に来る以前に、「こんな私は Java がどうも余り好きでないです」なんてエントリで簡単に書いたこともありました。
ここでは、「なぜ Java を選ぶのか」に書かれていることの、ほんの一部にしか触れてませんが、やはり私も自分が携わる現場で、上司やクライアントとのやり取りとして似たようなことがありました。
私は、(特に他のスクリプト言語と比較した場合の) Java のメリットは殆ど無いと言えると思っていまして、
1. CGIは毎回プロセスが起動する⇒ Javaならスレッドなので高速に応答できる
2. 同様に、DBコネクションを使いまわせるので高速に処理できる
3. Javaは、"Write Once Run Anywhere"なのでプラットフォームに縛られない
4. J2EEには、最初からセッションの仕組みが組み込まれている
5. Javaの方が、ＭＶＣ・レイヤ分割など設計の直感的な見通しが良い
6. インタプリタ言語を使う場合に比べ、バイトコードなので高速に動作する
7. 言語としてとっつきやすい
と列挙した以降に記述された考察である、
こんなところでしょうか。これらの比較は、当時の状況においては、（それを求める人達にとっては）どれも正しい意見だったのかもしれません。しかし、時代は変わり、今同じことが言えるでしょうか。
1,2に関しては、mod_xxxやFastCGIを駆使すれば、それほど遜色なく実現できそうです。
3に関しても、スクリプト言語を使えば、最近の状況であれば、WORAはJavaだけの特権では無いと思えます。
4,5は、言語や仕組みの話ではなく、Webアプリケーションフレームワークがあるか無いか、というだけでしょう。そして、今やJava以外のメジャーなフレームワークは沢山あります。
6は確かに、比較をすると高速であると言えるかもしれませんが、パフォーマンスを理由にした選択というのは、ムーアの法則によっていずれ覆されます。インフラの性能が上がることで、その速度差は誤差になってくるでしょう。
の殆どの内容は、指摘されている通りだと思います。
特に、インタプリタ言語として存在している P言語 (Ruby が仲間にならないのがイヤな言い回しではありますが) の VM 化が進む (Parrot とか) と、もはや差は無いと言っても良いのではないでしょうか。
Perl6 はエンタープライズ的にも満足の行くソリューションを提供して来るでしょうし。
しかも、7. については、Java と比較して他の light weight な言語の方が数段とっつきやすいと感じています。まあ、これは個人の資質や好みに左右されるものですが。
ただ、Java を選択する理由としては、上に加えて、
といったところも、エンタープライズ用途では大きく意識されたところだったと思っています。この辺りは今も変わらないですが、有力ベンダの他の言語に対する働きかけが表面化すれば、どんどん変わって行くものと思います。
Google や Amazon なんかが、どう動いて行くかですかね。
また、上に書いた VM 関係ですが、何だかんだ言っても、これまでの P言語 (Ruby も入れてあげて……) のインタプリタ環境と、Java の VM 環境では、その枠組みには大きな違いがある様には思います。
詳しくは知らないので的外れかもしれませんが、Java VM が持つスレッド環境やデバッガインタフェースなど、仮想マシンとしての枠組みの充実度は高いものだと思います。
後追いで開発されている Parrot などの VM 環境が、どれほどプラットフォームから独立し、充実した機構を構築するものなのかが鍵かもしれないなどと考えてます。
また、Java の強みは、言語そのものではなくコミュニティであるとも考えています。
上で加えた IBM などのベンダのフォロー、代表的なアプリケーションのサポートといった部分は、そこで活躍している開発者達やコミュニティそのものが、Java を押し上げるイノベーションを起こしていますよね。
その最たるものが Eclipse でしょうか。
それについて、■Ruby the gateway drugという記事では、Java で活躍していたイノベーター達が、Ruby に移ってしまうために、Java でのイノベーションはもう望めなくなるという話が出ています。(すみません、原文は読んでません……)
この話がどこまで真実を突いているのか、今後の動きに注目して行きたいと思います。
