--サーバ側ではJavaが使われ、フロントエンドにはスクリプト言語が用いられるケースが増加しているとしましょう・・・Javaにとって、それは問題ではありませんか。
わたしは今まで、ウェブのフロントエンド開発は、コンピュータが扱う作業の中でも簡潔かつ単純なものの1つだと見なしてきたと思います。Java関連で利用されているスクリプト言語はたくさんあります・・・JavaScript自体もそうですし、ほかに「Groovy」「J/Python」「J/Ruby」といったものもあります。
多くの人々は、Javaが実際には2つのレベルから成る言語であるということの良さを正しく評価していません。Javaは仮想マシンであり、またASCII文字によって表現された構文体系でもあるのです・・・その他の本当に興味深い仕掛けはすべて、人々が実際に目にすることのないこの仮想マシンのなかに存在しています。この仮想マシン上で実装されているスクリプト言語は、非常にたくさんあります。
--スクリプト言語とJava仮想マシン(JVM)を連係させて利用することを評価しているのはなぜですか。
スクリプト言語をそうした形で利用するメリットの1つは、膨大なツールライブラリを即座に利用でき、優れたパフォーマンスや互換性を実現できるという点です・・・Groovyを利用すれば、POS端末やスマートカードの情報、あるいはフーリエ変換を行うための数学ライブラリといった、興味を引かれるものをどれでも利用できます。
--Javaは、分散コンピューティング用として設計された言語であり、複雑な計算処理によく用いられます。Javaはもっと単純な処理にも用いられるべきでしょうか
Javaは昔から、単純な処理もうまくこなしてきています。ただし、トレードオフのような関係は存在します。とても単純な処理をごく簡単に行えるものを作ったとしても、複雑で大規模な目的に利用しようとすれば、うまくいかなくなる傾向があるのです。
これはJavaの設計におけるここ数年の一般的な傾向ともなっていることですが、われわれは極度にハイエンドな開発に力を入れてきました。おかげで、一晩に1000億ドル分のトランザクションを処理するサーバを運用したい大手銀行があったとしても(そのような銀行は実際に存在します)、Javaの世界におけるインフラだけでこうしたニーズに対応することができるのです。このようなシステムでは、シンプルさは要求されなくなります。なぜなら、これぐらい大規模になると、対処しなければならない曖昧な物事がたくさん出てくるからです。こういったハイエンドの世界で実際に要求されるのは堅牢性であり、それに対応しなければなりません。
--Javaの使い勝手の問題は以前から採用を妨げる障害となっています。この点については、どのように対応していきますか。
実際のところ、われわれが行おうとしてきたのは、言語に変更を加えることではありません。言語をシンプルにしようとすれば、しばしばハイエンドな要求に対応する能力が損なわれてしまうからです。そこでわれわれは、ツールの単純化に対する取り組みを強化して、使い勝手の向上を目指してきました。例えば「Java Studio Creator」では、AJAXのコンポーネントやデータベースアクセスなどをドラッグアンドドロップして、ウェブページをごく短時間で制作できるようになっています。
ツールを使用する利点の1つとして、ツールが生成するものは必要な洗練性をすべて兼ね備えているという点を挙げることができます。使い勝手という面では、込み入った操作を行わなくても、フェールオーバ機能やリモートマネジメント機能を備える、大規模かつ冗長なサーバクラスタに、ツールが生成したものを実装することが可能になっています。しかも、こういったツールは無償で提供されています。
--しかしそうしたツールは、時間が経つにつれて、より大きく複雑になっていきます。
より大きく、より複雑になっていき、最後には捨て去らなければいけない「限界点」という転機がやってきます。
われわれが目指してきたのは、優れた使い勝手が実現されたシンプルな開発をスタートさせ、規模が大きくなるに従って、ツールによって複雑性を明らかにしていくということでした。
--数年前までは、開発スタック(開発における技術上の選択肢)と言えば「J2EE」とMicrosoftの「.NET」の2つが主流だとされていましたが、最近では「LAMP」(Linuxをはじめとするオープンソース・ソフトウェアの組み合わせ)が脚光を浴びるようになっています。LAMPは、Javaが提供するものに取って代わるだけの選択肢となっていますか。
確かにLAMPは実用に耐えるものになりましたし、Linux、Apache、MySQL、PHPからなるLAMPの世界でもJavaはうまく動作します。実際に、JavaはLAMPとうまく組み合わせることが可能であり、そういった組み合わせで使用されることもかなり一般的です。
私自身は、信条として市場の多様性を概ね歓迎しています・・・実際のところ、市場にそれほど多様性があるようには思っていません。
--「Ruby on Rails」といったものが出現したり、PHPあるいはLAMPの利用が増加していることについて、あなたはそれほど心配していないとの印象を受けます。これらはJavaと同じというわけではありませんが、ご自身の観点からは現状に問題はないと考えているように聞こえますが。
どれも面白いツールだと思っていますよ。これらのツールは、すべて現実に連係して動作します。特に、Rubyの一実装であるJ/Rubyが良い例です。これはRubyをJVM上で実装したものです。なかなか気の利いた処理が可能な、すぐれたツールです。ただ1つ、スクリプト言語の作成者には、もっと変わったものを作ってほしいという願いを抱いています。
CNET Japanの記事を毎朝メールでまとめ読み(無料)
地味ながら負荷の高い議事録作成作業に衝撃
使って納得「自動議事録作成マシン」の実力
ものづくりの革新と社会課題の解決
ニコンが描く「人と機械が共創する社会」
ZDNET×マイクロソフトが贈る特別企画
今、必要な戦略的セキュリティとガバナンス