なぜJavaを選ぶのか？〜JavaOneTokyoに期待すること

Javaが10周年を迎えた今年、JavaOneが久しぶりにその名前で東京でも開催されることになりました。明日から開催です。

10年前、Javaが世に出てきた当初、ここまで広まるとは誰も予想していなかったと思います。Webアプリケーションをイントラネットで使うという流れが出てから、エンタープライズ用途での利用を確固たるものにしてきました。この10年間は、Javaという技術にとって、とても貴重な期間だったと思います。

JavaがWebアプリケーションで使われ出した頃においては、色々な制約条件などが重なって、Javaという選択肢が企業向けのシステム開発で使うには最適の答えだと考えられていました。今でこそ、社内向けのエンタープライズアプリケーションにJava（JavaEE）を使うことに異論を唱える者はいないと思いますが、当時は、既存のCGIとの比較などをした提案をしていたと思います。当時を思い出してみると、以下のような比較をしたのではありませんか？

  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は確かに、比較をすると高速であると言えるかもしれませんが、パフォーマンスを理由にした選択というのは、ムーアの法則によっていずれ覆されます。インフラの性能が上がることで、その速度差は誤差になってくるでしょう。

最近で言えば、Ruby on Railsなどのフレームワークの台頭によって、PerlやRubyなどのスクリプト言語が見直されています。開発だけで考えるのでなく、システムの運用を見越して考えた場合、スクリプト言語でWebアプリケーションを作るほうがメリットが出てくる場合があります。アプリケーションのバージョンアップなどについては、スレッドで動いているJavaよりもプロセス単位の方が置き換えが楽だったり、など。言語の進化の方向性としては、コンパイル言語からスクリプト言語であり、Javaはハードウェア制約などの中での過渡期としてのプラットフォームだったようにも思えます。

そうなってくると、Javaであることの理由が見つからなくなってきます。7のとっつきやすさは確かに重要ですし、今現在であれば、Java技術者の調達の方が楽にできるということも重要な要素ではありますが、それはマネジメントの課題であって、Javaそのものの話でもないように思えます。そこで今こそ、Webアプリケーションを開発する際には、なぜJavaを選ぶのかを考えた方が良いかもしれません。

ただし、Javaが今のままであるとは思っていません。Javaそのものは、言語としての意味だけでなく、技術基盤としての意味など大きく世界は広がっています。それを考えたとき、Javaの可能性はまだまだあるのかも知れません。今までに無い、新しいJavaの方向性を発見できるかもしれない、JavaOneにはそんな期待をしています。Javaの今後の10年を見つけるために。私も参加します。

最後に苦言を１つだけ。
登録ページのスケジュールビルダーがとても使いにくかったのは残念。Webだけで利用する利用者の観点に立ったデザインになっていなかったし、使いやすくするためのAjax風味もなかった。あのサイトがJavaでできているとしたら、デモンストレーションとしては失敗だと。。。