レポート

スクリプト言語からSunの財務状況まで~James Gosling氏プレスインタビュー

この記事を読むのに必要な時間:およそ 4 分

12月2日,サン・マイクロシステムズの開発者向けイベント「Sun Tech Days」参加のため,「Javaの生みの親」として知られるSun Microsystems, Vice President and Sun FellowのJames Gosling氏が来日し,同イベントの基調講演後にプレス関係者を招いてのラウンドテーブルが行われました。このインタビューの模様をお届けします。

いつも訥々とした独特の口調でインタビューに答えるGosling氏ですが,今回はいつも以上にざっくばらんに,Javaの最新事情からスクリプト言語への考え方,そしてSunの置かれている現在の状況まで,幅広い質問に本音で答えてもらえました。

画像

「クラウド」はバズワード,Javaは昔からやっている

――Pythonや.NETは,それぞれGoogleとMicrosoftがクラウド対応を進めていますが,Javaでのクラウドコンピューティングについて,何か注目する動きがあれば教えてください。

ああクラウドね(ため息)。クラウドコンピューティングなんてのはおかしなバズワードだよ。Webホスティングをクラスタ的に使うための技術で,これまでも呼び名が違うだけで,さまざまな人がJavaにおいても何年も努力してきた技術だ。こうしたインフラの中で最も大規模なものとしてAmazon EC2があるけれど,これはJavaアプリケーションに対応したシステムだ。

基調講演で言ったように,Javaの核となるJVM(Java Virtual Machine)にはいろいろな活用形態があるけど,クラウドコンピューティングもその1つだ。JVMを使ってスクリプト言語を組み合わせることによって,違う言語を連携して動作させることもできる。一方,Javaのコードで書かれた機能をマシン間で簡単に移す機能がある。これをJava Spacesと呼んでいるが,これを利用してコンピュータクラウドを形成できる。Java Spacesによって,オペレーションとハードウェアを分離し,ハードウェアによるアーキテクチャの違いをや言語の違いを吸収したクラウド作ることができるんだ。

――JavaSpacesとはなつかしいですね。Sun内部でまだ使っているんですか?

ええと,JavaSpacesの技術自体はもうかなり前にコミュニティに引き継がれていて,我々は別の「標準化」の作業にとりかかっている。標準化された技術というのは,同じ機能をもつ過去の技術に比べてパワーが落ちることもある。たとえばGlassFish v2に「クラスタリングファシリティ」というのがあるが,これはクラウド的な振る舞いを実現するもの。ただし,これは動作が遅い。なぜなら,世界的な標準に則って実装を進めたからだ。これに対して,JavaSpacesはJava世界のフィーチャに依存した実装なので,他の言語との相性は悪いが,動作は速い。

今ではJVM上にいろいろなスクリプト言語が乗るようになっている。以前は非常に難しかったことが実現しているんだ。このようなWebサービスの標準化委員会がやってきた方向というのは,元々我々がJiniやJavaSpacesで達成したものよりも弱い。ただし,複数の言語をサポートできるという強みを持っている。それが標準となっているので,我々もそれに準拠するということだ。

Javaはスケールアップにも対応できる

――では逆に,今後のコンピュータパワーの増大に伴って,新しく実現していく機能やテクノロジとして考えられるものは何かありますか?

画像

うーん。これは幅広い分野をカバーしていて答えるのが難しいな。すでにすごいパワーで動くものがあるということは皆も見ている思うんだけど,それがとくに現れているのはコンピュータゲームかもしれない。リアルで生きているような表現もできるようになってきた。基調講演のときに見せたデモも,Java Game Engineを使ってもっとすごいものにできる。映画,ストーリーテリングがこうした強力なゲームエンジン,そしてネットワークの組み合わせでどんどん変わってきている。この間の大統領選挙でもインターネットを使った新しいクリエイティブな取り組みがあったし,もっとバンド幅が広がると,ダイナミックメディアの使われ方も変わってくると思うし,一般の人がもっとジャーナリスティックに活動できるようになると思う。

――マルチコアのシステムに限ると,たとえば数千コアのシステムが実現した場合,JVMはいまのモデルでスケールアップできるのか見通しはありますか?

今でも256コアまでは対応できているし,Javaアプリケーションの中には何千ものスレッドをハンドリングしているものがある。これはまさに「バーチャルコア」と呼べるものだ。今後扱うコア数が増えたら,想像のつかない問題も出てくるだろうけれど,その問題の大部分はJVMそのものではなく,その上で動くプログラムモデルに関わるものになると思う。プログラムで行う処理をマルチコアにどのようにマッピングしていくかということだ。さいわい,エンタープライズのトランザクションについては,現在でもマルチコアにうまく載せ替えることができている。GlassFishについてもそう。

今後,数値演算アルゴリズムなどについては,かなり難しいことになるだろうと思うけど,それよりも一般的なスクトップモデルで問題になってくるのは,グラフィックスになるだろう。どのようにビデオメモリを使い,イメージをレンダリングしていくかというところだ。いまの段階ではこれはうまくいっている。レイトレーシングソフトなどは,うまくマルチコアを使っている例だ。ただ,今行っているやり方は,マルチコアでの問題を全部解決するものではない。マルチコアに処理を分解するには,それぞれのソフトウェアでの対応法しか見い出せていないんだ。

――今のコンピュータパワーや状況の下で,もしあなたが20代,30代だったらどういう技術にチャレンジしたいですか?

グラフィックスだね。3Dのモデリングツールなんかに関わっているだろう。もちろんJavaを使ってね(笑)。

JDKのバージョンアップを巡る問題

――JDK 7について教えてください。とくにクロージャ導入について。

JDK 7にクロージャが入るかどうかは,まだ決まっていない。僕は含まれるべきだと思っている。いまインタークラスというのがあって,これはクロージャへの第一歩と言うべきものだが,僕ははじめからクロージャを実装すればいいと思う。これは今一番ホットなトピックで,コミュニティの意見が真っ二つになっている。僕が入っている派はクロージャを使えばアプリケーション開発がシンプルになるし,開発者の作業も簡単になるという意見。反対派の意見は,これ以上言語をいろいろいじるといずれ問題が出てくるかもしれない。最小限の変更にとどめるべきだというものだ。

後者の意見にも関係あるが,コミュニティの問題は,多くの参加者が,JDKの新しいリリースが出てきても追いつけないという点だ。JDK6というのが現在の最新だが,エンタープライズの人たちはいまだにJDK4を使っている人が多い。彼らをアップデートさせるのはとんでもなく大変なんだ。こうした人たちからは「もっとゆっくりと進んでくれないとついて行けない」という意見が出てきた。だから,JDK6よりも7のほうが時間がかかっている。我々はJDKのアップグレードよりも,JavaFXなどの周辺技術に注力しているんだ。

――いまだにJDK1.4などの古いJDKを使っている人がいるのはなぜでしょうか?

まったく悲惨なことなのだけど,一番大きな理由は技術的なことではない。つまりコストの問題なんだ。たとえばJDK1.4.xで認定されているIBM WebSphereに10万ドルものお金を払っていると,もしそれがJDK6で動いたとしても,IBMからサポートを受けるためにはJDK 6で認定されたWebSphereをさらに10万ドルかけてアップデートしなければならない。WebLogicやOracleなどのJava製品もすべてそうだ。どの企業もそういうライセンス体系を取っているので,今現在ちゃんと機能していれば,わざわざ大金をかけて最新のJDKにバージョンアップすることはない。そのまま使い続けることになる。

コメント

コメントの記入