5月末、著者はパリの中心'Le Grand Rex'で開催された、第一回What's Nextカンファレンスに参加した。キーノートのスピーカーの一人、Neal Gafter氏は、Java SE 4と5の言語拡張の設計と実装を行った人物であり、現在はMicrosoftで.NETプラットフォームの言語に関する仕事をしている。幸運にも、筆者はNeal氏にインタビューを行うことができた。以下は、我々の対談の内容である。 Neal氏はプレゼンテーションの中で、"誰かが統括している時にこそイノベーションが最もよく機能する"ゆえ、OracleによるSun Microsoftの買収は、結局Javaにとって良いことであった、という見解を述べていた。そこで著者はまず最初に、OracleによるJavaコミュニティへの対応についての見解を、Neal氏に尋ねてみた。
Neal Gafter氏: そうですね、Javaコミュニティは、Oracleによる買収でのプラス面が最も少ないものの１つだと思っています。
コミュニティの人々は、今でも色々なことに取り組んでいます。つまり、それらは今まさに取り組んでおり、まだ完了していないということです。彼らはオープンな仕様を作り出そうとしています。今後全てのJSRはオープンに取り扱う、全てのエキスパートグループのメーリングリストを誰でも読めるようにする、と彼らは言っていました。
その後、彼らはProject CoinとProject Lambdaを立ち上げました。それらは現在も活動が続いています。パブリックレビューが行われましたが、エキスパートグループの議論は読むことができません。
私は彼らに、参考として私がエキスパートグループとの議論を行えば、すぐに詳細にフィードバックするつもりである、と言いました。なぜなら多くの決定に対する論理的根拠が明らかになり、フィードバックは議論の文脈の中で理解できるでしょう。
それに対する回答は、"我々は今それに取り組んでいます。いずれそれをあなたにお伝えします"というものでした。エキスパートグループが"これを公開したくない"と言った訳ではありません。エキスパートグループは公開で議論することを望んでいますし、Oracleも公開したいと思っているがまだできていないだけだ、と言っています。
そして、パブリックレビューの期間が終わりましたが、それらにはまだアクセスできません。Java言語仕様の改訂のため、JSRが検討されており、私はそのレビューに行きました。しかし、取り組んでいるのはエキスパートグループでさえなく、Alex Buckley氏とOracleの言語チームが、仕様を訂正して仕様バグを直していました。
彼ら(Oracle)はこう言いました。"これはこのバージョンの仕様で修正されたと考えているバグのリストで、これが訂正後の仕様です"と。私はリストを見て、バグを確認するためWebサイトを訪れましたが、それらは公開されていません。だから、私は彼らが修正したと考えているバグが何なのか知ることさえできません。どうやってそれを知れと言うのでしょう？
私には十分な情報がありません。彼らは"すみません、それはミスです。それらは公開されるべきものであり、いずれそうします。"と言っていました。パブリックレビュー期間が終わった１、２週間後、彼らから"バグが見られるようになりました"という連絡がありました。しかし、それでは遅すぎて、パブリックレビュー期間にフィードバックを得ることができません。
もちろん、彼らは内部、外部に関わらず、パブリックレビュー期間中にフィードバックを得ることを望んでいます。パブリックレビュー期間は形式上の期間であり、彼らは可能な限りいつでもフィードバックを得たいと望んでいるでしょう。だから、それは言語仕様の場合は、大したことではありません。しかし、それでも彼らはSun Microsystemsが行っていたほどは、外部に目を向けていません。彼らはより内向きなのです。彼らは自身の開発者を抱えています。彼らは、Sun Microsystemsと違い、Oracle以外のところでフォークされることを期待していないのです。
実際問題として、作業のほとんどは社内で行われています。これまでずっとそうでしたし、おそらく今後もそうだと思います。Sunはコミュニティと積極的に関わろうとしていましたが、Oracleの場合はそうではありません。Oracleはコミュニティの扱いについて、不器用なのだと私は思います。そう、彼らは本当に不器用なのです。今まさにコミュニティとの関わり方を学んでいるところなのでしょう。
InfoQ: 彼らはそれを改善しようとしていると思いますか？
Neal Gafter氏: ええ、そう思っています。悪意がある訳ではないと思います。私が思うに、Javaコミュニティは彼らが今まで扱ってきたコミュニティとは、ずいぶんと異なっているのでしょう。
彼らは、コミュニティにどのように関与すればよいかを学んでいるところです。前途多難な船出ですが、彼らは本当にコミュニティのよい協力者になりたいと願っており、その方法を模索しているところだと私は思います。技術的な問題ではなく、Oracle内部の管理上の問題です。
もし彼らが何かをアナウンスしようと思ったり、公開メーリングリストを立ち上げようとすれば、彼らはそれを行うための管理機構を持っていません。会社は、それを行う人を持てないほど大きいのです。彼らは承認や制定のプロセスを持つ必要があります。そしてそのプロセスは、彼らが現在行おうとしているようなことには使えないのです。
私は彼らがそれを解決し、そのうちよい方向に向かっていくだろうと思います。
確かに現時点では居心地がよくないですが、彼らはコミュニティのよい協力者になるだろうと思います。彼らはコミュニティを育てたいと考えているでしょう。なぜなら、彼らこそがコミュニティからの恩恵を受けるのですから。
それが彼らにとって一番よいことです。だから私は、議論やレビューの公開について、度々彼らを困らせるようなことをしていますし、彼らが改善しても、これからも困らせていくつもりです。改善の余地は常にあるからです。
しかし、私は彼らが正しい方向に向かっていると思っています。
InfoQ: これまで何度も質問されたことだとは思いますが、私はあなたが今Microsoftで働いているということについて関心があります。MicrosoftとSunの関係が最悪だったのは間違いありません。様々な理由で関係は改善されましたが、C#に取り組みつつ、Javaの改善にも積極的に関わっていることについて、政治的な面に興味があります。どのように活動しているのですか？
Neal Gafter氏: 実際のところ、それは私の仕事の一部ではないのです。つまり、私がMicrosoftで行っている事とJavaとは全く関係がない、ということです。関心や興味があり、同じようにJavaに関わっている多くの友人を持っているから、私もやっているのです。Javaは長い間私の生活で大きな部分を占めて来ましたから、今後どうなっていくのか気になりますし、Microsoftが行っていることで、Javaの役に立つと思えることはたくさんあります。
Javaを成長させるための産みの苦しみの多くは、C#が既に経験したものです。今日Javaがしようとしていることの多くは、C#がやりたいと思い、そしてやってみて上手くいっていることなのです。しかし、C#の中の全てが完璧という訳ではありません。つまり、そこからJavaにとって価値ある教訓を学ぶことができたのです。
例えば、C#が非同期機能をどのように扱うか調べたことがありますか？ C#でLambda式が動作する方法はどうですか？
並列処理モードのオペレーションはCとLINQで動作します。私は、これらはJavaにとってとても有用だと思っています。
InfoQ: C#にいくつかの重要な機能を追加した時、C#にはJavaに比べていくつか利点があったと思います。C#のユーザーはJavaに比べて少なかったため、後方互換性などをなくすのが簡単だったでしょう。それとも、それはむしろ哲学的な違いなのでしょうか？
Neal Gafter氏: そうですね、哲学的な違いは多少あると思います。あなたが聞きたいのは、何よりもまずはジェネリックのことでしょう？
InfoQ: まさしく、その通りです。
Neal Gafter氏: Javaにジェネリックを追加する時、型消去(Type Erasure)が使われました。
つまり、それは仮想マシンの大幅な変更を必要としませんでした。全てはコンパイル時に処理され、実行時にはジェネリックに関する情報はオブジェクトから消去されるのです。実行時に、空の文字列リストと空の整数リストを見分けるようなことはできません。それらは全く同じクラスのオブジェクトとして表現されるのです。
そのようにした理由の一つは、既存のライブラリを汎用的にしたかったからです。ライブラリの作成者に、非ジェネリック版とジェネリック版の両方を用意させるようなことはしたくありませんでした。
もしあなたがライブラリを作っていたら、それぞれのバージョンのライブラリを作らないといけなくなりますよね？ 理論的には、それはとても複雑です。しかし実際のところは、懸念していたほどライブラリ作成者にとって複雑ではなかっただろうと、私は思っています。
C#にジェネリックを追加した時は、非ジェネリックコレクションクラスを廃止しませんでした。これらの非ジェネリックコレクションクラスは未だにライブラリの一部であり、事実、非ジェネリックコレクションとジェネリックコレクションには継承関係があります。ジェネリックコレクションは、非ジェネリックコレクションを拡張したものです。
InfoQ: なるほど。
Neal Gafter氏: だから、実際のところ、ジェネリックコレクションは非ジェネリックコレクションと同じように実装できます。これは、一定レベルの相互運用性を提供してくれます。つまり、ジェネリックコレクションオブジェクトは、非ジェネリックコレクションオブジェクトを受け取ることを想定しているAPIで使うことができるのです。
その逆、つまり非ジェネリックコレクションオブジェクトを、ジェネリックコレクションオブジェクトを受け取るAPIに渡すことはできません。しかし、この状況に適応させるのは難しいことではありません。新たにジェネリックコレクションオブジェクトを作成し、非ジェネリックコレクションオブジェクトの中身を移し替えればよいだけです。
JSR-14をより簡単に実現することが明確なゴールだったわけではないと思います。"最小限の努力でジェネリックを追加したい"ということが、明確なゴールの１つだったわけではありません。しかし、Javaにジェネリックを追加するために費やされた労力は、Microsoftプラットフォームに費やされた労力に比べればとても少ないものでした。なぜなら、Microsoftプラットフォームでは、コンパイラの大幅な変更だけでなく、仮想マシンと実行時ライブラリにも大幅な変更が行われたからです。つまり、システム全体の、抜本的で広範囲に渡る変更ということです。
技術的には既存のライブラリを壊すことはありませんが、もしジェネリックを使うためにライブラリをマイグレートしたいのであれば、実際にはライブラリをマイグレートするための努力が必要です。しかし、もしSunがC#と同じアプローチを取っていれば、それはユーザにとって大きな負担にはならなかっただろうと思います。Sunにとっては、大きな努力を必要としたでしょうが。
Sunには他にもやることをたくさん抱えており、実際にはそれを行うだけのリソースがなかったのでしょう。
InfoQ: なるほど。
Neal Gafter氏: 少なくともその時期には。つまり、もう2、3年あるか、もしくは多くの人を投入できれば、Microsoftがやったのと同じことをできたと思います。MicrosoftはSun Microsystemsに比べて、自身のプラットフォームのためのリソースをより多く抱えています。しかし、フィーチャーポイントの観点から見ると、一人当たりの作業はSun Microsystemsの方がMicrosoftよりもおそらく多いでしょう。
Microsoftのシステムはじっくりと設計、テストされ、入念にレビューされていて、そのシステムのそれぞれのピースは、Sunのものに比べてうまく連携しあっています。例えば、1.1でSun Microsystemsはインナークラスとシリアライズ機能を同時に追加しました。私は実際にはこれらに関わっていませんでしたが、開発チームはこれらの機能を独立した、もしくは直交した機能として扱ったと認識しています。
実際は直交した機能ではないにも関わらずです。それゆえ、それらの連携は快適なものではありません。つまり、実際のところこれらの機能の間の連携には、弱点があるということです。ですが、より多くのテストやレビューを行えば、それだけ時間がかかったり、開発にコストがかかったりするわけですから、よりベターな落とし所で決着させることになります。私の経験から言うと、C#はJavaに比べてより堅実な設計になっています。ジェネリックがその一例です。
これで質問の答えになっていますか？
InfoQ: はい、ありがとうございました。これまでJavaでは、新たに機能を追加し続けていくべきかどうかについて、議論が続けられてきました。それは.NETについても同じだと私は思っています。新機能の追加によって言語が複雑になった場合、それを止めるべきでしょうか？その好例としてCがあります。Cは実際のところ長い間発展していないですが、まだ広く使われています。対照的なのがC#で、ものすごい勢いで進化しています。これについて、ご意見をうかがわせていただけますか？
Neal Gafter氏: 変化は必要だが慎重に管理されなければならない、というのが私の考えです。いくつかの理由から、JavaはC#に比べて、それがより困難です。
1つ目の理由は、リソースの制約です。
2つ目の理由は、C#のような長期計画がJavaにないことです。
C#は非常に明確です。それは、Anders Hejlsberg氏の存在故です。Anders氏は言語とプラットフォームのアーキテクトで、設計センスに非常に優れています。実際のところ、Anders氏は、同僚たちとの強調の手腕も抜群ですが、言語がどこへどうやって向かうべきかという長期的な視点も持ち合わせています。あらゆる変更の前に、それは言語が向かうべき方向なのかどうか、という点がまず検討されます。
何かを追加すると、ある人にとってはプラスだけれど、その他の多くの人々はそこから何のメリットも得られない、というのはよくあることです。それどころか実際にはマイナスになってしまうこともあります。例えそれを使わず、見ず、気にしないとしても、それはシステムをより複雑にしてしまいます。
Microsoft内部のやり方の一つに、言語に対するあらゆる提案を、-1,000ポイントから始める、というものがあります。まずは-1,000ポイントと格闘し、本当に言語に追加する価値があるのか検討することになります。これは言語に何かを追加するのをより難しくしますが、言語への追加というのはそうあるべきです。
C言語も変わりました。標準委員会があり、標準の新バージョンが発行されます。ゆっくりと時間をかけて、本当に実体のある変更がもたらされます。例えば、Cの標準委員会はC++の標準委員会に比べると変化に対してずっと保守的です。
C++標準委員会は、言語に何か追加するのを検討したり、却下したりすることに関して、かなり寛容です。保守主義には何らかの理由があると思いますが、私は、今日使っているどんな言語でも、ある程度の変更を喜んで受け入れない限り、活気を保つことは難しいと思っています。
それから、Javaに関しては、変更がより困難な理由の1つは、一般的によいアイディアだと言われていた変更が加えられてきたものの、それらが言語の未来の進化を十分に検討せずに追加されてしまったことです。さきほど述べた、長期的な視点がなかったということです。
ジェネリックがその好例でしょう。ある種の移行を簡単にするために、型消去が採用されました。問題は、型消去が言語にその他の機能を追加するのを困難にしたということです。例えば、言語に関数型を追加するのはとても困難です。
InfoQ: 私の記憶が正しければ、あなたはブログの中で、まだ修正できる、と論じていましたね？ 型消去に頼らないジェネリックを実現できると。
Neal Gafter氏: その通りです。私は実際には両方混在できると提案しました。そうすると、型は非ジェネリックとジェネリック型パラメータが消えたもの、具象ジェネリック(Reified Generics)になるでしょう。型消去をなくしてしまう必要はありません。いくつかの型パラメータは消去され、他は消去されずに残ることになります。
問題は、型消去が言語の未来の進化を妨げるということです。これまでも言語の進化を妨げてきましたし、今でもそうです。特にジェネリックを使いたいと思っていた人や、何か特定の目的のために具象ジェネリックが欲しい人にとっては役に立つでしょう。しかし、型消去は未だに多くのものにとってマイナスになっています。一方、最小限の変更(Breaking Changes)で今日のジェネリックを具象ジェネリックにしようとしている人たちもいます。多くを破壊することなくそれが可能でしょうか？
それはとても困難な問題ですが、そうしていけるだろうと確認している人たちもいます。もし彼らが成功すれば、間違いなく破壊(これまで動いていたものが動かなくなる)をもたらすジェネリックコードがリリースされるでしょう。しかし一方で、将来具象ジェネリックが使えるようになるということであり、もしそうなれば、私は素晴らしいことだと思います。私は多少懐疑的に見ていますが。
InfoQ: そうですね、なかなか難しいことですが、興味があります。Stephen Colebourne氏は、Oracleは後方互換性のないJavaを作るべきだ、と主張していたことがあります。そうなると、我々は2つのバージョンをメンテナンスしていくことになってしまいます。すると...
Neal Gafter氏: Microsoftはすでにそれを行いました。ご存知の通り、C#です。そう、つまり私はこう質問したいのです。なぜそれがOracleであるべきなのかと。
なぜそれがJavaと呼ばれるべきなのでしょう？Javaと共通なのは何なのでしょうか？それはJavaではありません。もし後方互換性がないなら、それはJavaではないのです。もしそれをJava VMで動かしたくて、かつ具象ジェネリックが欲しいのであれば、問題を抱えることになります。具象ジェネリックがJava VMのサポートを必要とするからです。
このように、もしそれが新しいVMとプログラミング言語なのであれば、Oracleはそれに一体どんな関係があるのでしょう？
それが私の疑問です。当然、私はJava以外の言語にも余地があると考えています。そうでなければ、現在Microsoftでは働いていないでしょう。しかし、Java VM上で動くものでいえば、例えばScalaのような、Javaに代わる優れた言語もあります。
もし私がJava VMに関わっていて、使いたい言語を選ぶとすれば、Scalaは有力候補となるでしょう。
InfoQ: 新興の言語で、注目に値するものを教えていただけますか？先ほど、オブジェクト指向と関数型のハイブリッド言語であるScalaが話に出ましたが、.NETには同様の言語としてF#がありますね。関数型の次には何が来ると考えてらっしゃいますか？
Neal Gafter氏: 関数型の次ですか？
私は実際のところ、特にJavaやC#など命令型のスタイルの言語にとって、関数プログラミングコミュニティが言っているような概念まではまだまだ距離があり、それがゼロになるまでは数年かかると思っています。
ですが、JavaやC#は、望んでいる所までは行くことができないと思います。それらは関数型プログラミング言語のようにはならないでしょう。つまり、JavaやC#は命令型のスタイルのままだと思います。同時に関数型のイディオム、特にイミュータブルデータ（変更不可能なデータ）を使ったプログラミングからは、多くのものを得られるでしょう。実際にはスケールしない古き良きロックやシグナルを使って、並列実行を活用することができると思います。
ロックやシグナルを使って、並列実行を活用した巨大なシステムを構築することはできません。皆さんはできるかもしれませんが、少なくとも私には。そして、大量データ処理や並列処理プログラミングにとって、問題はミュータブルな（変更可能な）状態の共有です。
その解決策は、共有しないか不変にすることです。
関数型スタイルでは「不変にする」です。状態をミュータブルにしてはいけません。イミュータブルなデータを使うのです。Javaでは、ライブラリの内部でこのようなことを行っているものや、もしくはそのようなスタイルをサポートする多くのライブラリがあります。しかし、そのようなスタイルが広く使われるのはまだ先でしょう。
InfoQ: では、マルチコアなどの性能を十分に引き出すためには、我々のプログラミングのやり方を変える必要があると考えていらっしゃいますか？
Neal Gafter氏: そうです。そして、革命としてそれが起こるとは、私は思っていません。
我々はパフォーマンスや信頼性の問題を抱えており、よりスケーラブルなスタイルを採用したサブシステムで既存のサブシステムを置き換えていく中で、それは起こっていくでしょう。
InfoQ: ActorモデルやErlangなどで使われているメッセージパッシングのような手法のうち、どれがJavaやC#にフィットすると思われますか？
Neal Gafter氏: それをするには、今のところ誰も計画していないような方向へ言語を持っていく必要がある、と私は思っています。Actorスタイルに価値を与えているものの１つはパターンマッチングです（ScalaではCaseクラスを使います）。
現在、Javaのためにそのようなことをしようとは誰も考えていません。考えることに価値があるとは思いますが、私は長期間を見据えた“全体像”が必要だと思っています。そうすれば、全体像の１つとして、ご質問のようなことも簡単にわかるようになるでしょう。
しかし、長期の計画なしにはそれは実現できません。"Actorをバージョン◯◯で追加します"とは誰も言えないでしょう。長期計画が必要なのです。現時点で、Javaではイミュータブルデータを表すクラスを構築しにくい状況です。もっと簡単にしなければなりません。簡単にパターンマッチングできるようになるべきです。私は現在のシリアル化はイミュータブルデータを渡す望ましい方法ではないと思っていますが、どうでしょう？ 今のところまだ存在しないイミュータブルデータタイプが採り入れられれば、おそらくそれがイミュータブルデータを渡す適切なメカニズムになるでしょう。しかし、Javaにはまだそれが存在しないので、今のJavaにはうまくフィットしないように思います。
私は、今後のためにこのようなことを考えるのは確実に価値のあることだと思っていますが、Oracleの中の誰かがこのようなことについて話しているのを聞いたことがありません。だから、Java 7やJava 8では実現しないでしょう。もっとずっと先のことになると思います。
ですから、もしプログラムでこのようなスタイルを望んでいるなら、今の所はそれを自然に扱うことのできる言語を選んだ方がよいと思います。JavaやC#で、このようなスタイルのコードを簡潔に表現できるようになるまでには、とても多くの変更が必要です。ですから、ScalaやF#を使いましょう。
InfoQ: .NETプラットフォームとJavaプラットフォームで共通のもう１つの大きなトレンドに、C#やJava以外の言語のサポートがあると思っています。Microsoftは最初の頃からそれをより際立たせてきましたね。
Neal Gafter氏: java.lang.Objectという名前のことですよね？
InfoQ: まさしく、その通りです。
Neal Gafter氏: これは全ての言語にとってのObjectになるはずのものですが、かつてはそうではありませんでした -- ごく初期の段階では、誰もその点について考慮していなかったのです。
InfoQ: ええ。ところで、John Rose氏がJavaのためのプロジェクトをリードしています。末尾再帰のような、Da Vinci Machineプロジェクトの一部と考えられるものの中で、次にやりたいと思っているのはどんなことですか？
Neal Gafter氏: 動的言語のサポートを成し遂げるには、実に様々なことがあります。それらの１つは、VMの中の色々なものを、より簡単に動的言語を実装できるようにすることです。そのほとんどはDa Vinciプロジェクトで重点的に取り組まれています。ところで、個々のプログラミング言語のために、何を付け加えることができるでしょうか？ もう１つは、プラットフォーム上の言語間でより簡単に相互連携できるようにすることでしょう。MicrosoftはDLRや、C#で言語間連携をサポートするためのdynamicの追加に注力してきました。
Microsoftのアイディアは、効率的な動的ディスパッチをサポートしてこれらの言語を効率的に実行できるようにするだけでなく、ある動的言語のオブジェクトが別のプログラミング言語から使われた時に、無理のないセマンティックを持つことができ、そのようなセマンティックで言語間の相互連携を実現できるようにするメタオブジェクトプロトコルにあります。
だから、VM自体、もしくは可能であればVMの上にメタオブジェクトプロトコルを追加することは、動的言語間の相互連携にとって価値あるものだ、と私は考えています。
InfoQ: 後者はあなたが.NETで行ったことですよね？ それはCLR上のライブラリだと記憶しています。
Neal Gafter氏: ええ、そうです。実際のところ、CLRの中にもいくつかサポート機能がありますが、ほとんどはCLR上のライブラリです。
２つ目はJava言語のサポートでしょう。もしC#のスタイルでそれをするなら、基本的には"実行時のセマンティックとして解釈せよ。コンパイル時にやりたいことはさせて欲しいが、実行時のセマンティックとして解釈せよ"を意味する、"dynamic"と呼ばれる型を導入することになります。それは、動的プログラミング言語によって生成されたオブジェクトとの相互連携を可能にします。
動的メタオブジェクトプロトコルを持つのは、とても有用だと私は思います。
動的言語をサポートするために期待していることはたくさんあります。末尾再帰もその一つです。それは大きな変化ではありませんが、いつくかのプログラミング言語にとっては大きな違いを生み出すでしょう。
セグメンテッドスタックもそうです。現在、これはJavaとC#両方の問題です。これらのプラットフォームは、CやC++といったネイティブプラットフォーム上の多くの信頼性に関する問題を取り除いています。インデックスの境界外アクセスエラーが起こることはありません。なぜなら、それはチェックされ、例外がスローされるからです。メモリ管理を自分自身で行わないため、解放済みのメモリ領域や未確保のメモリ領域に書き込んでしまうこともありません。メモリ管理はガベージコレクタの仕事です。しかし、これらのプラットフォームが今のところ行わないことの一つが、スタックオーバーフローの処理です。スタックオーバーフローはエラーがあるからといって常に発生するわけではありません。想定していなかった無限再帰がプログラムに含まれていたからといって、常に起こるわけではないのです。
自然と再帰になるような箇所があるため、スタックオーバーフローは時々発生します。int i = 1+1+1+1と数千回繰り返すと、Javaコンパイラは簡単にクラッシュします。セマンティックアナライザがそれを解析しようとしている時、もしくはパーサがそれをパースしようとしている時に、それはスタックを破壊するでしょう。そしてプロセスがクラッシュします。
ご存知の通り、そこからリカバリできません。"もっとスタックを確保してもう一度やり直そう"と言いながら、対処することになります。問題は、確保すべきスタックの量を事前に知ることができないということです。
GoogleのGoのようなセグメンテッドスタックの利点は、事前に決める必要がないということです。スタックの量はプログラムのニーズを基に、動的に調整されます。それはある種のソフトウェアをとても簡単に書けるようにします。
Javaでスレッドを使うのは高くつきます。なぜならそれらが全くプールされないからです。もしそれらが高くつくものでなかったなら、それらをプールしないでしょう。スレッドが高くつく理由は、スタックが事前に確保されるからです。大きなスタックは、大量のリソースを消費します。スタックを使い果たしたくなければ、巨大なスタックを確保しなければなりません。もしセグメンテッドスタックが利用できれば、スレッド自身をより気軽に使えるようになります。
スレッドを気軽に使うことができれば、多くのことがより簡単になります。 例えば非同期プログラミングやステートマシンの記述、コルーチンです。もしスレッドを利用するコストが十分低ければ、そういうことをする必要はないでしょう。スレッドを作成してそれを待たせればいいのです。スレッドが待っている間は、リソースを消費しないのですから。
スレッドは仮想アドレス空間に確保されたスタックさえ持ちません。だから、私はこのようなものをJavaに実装することを検討するのは、価値があることだと思います。
それはわずかなことですが、プラットフォームに非常に有益な影響を与えると信じています。そしてそれは、Javaプラットフォームを進化させ続けるのに必要だと考えられているものにも、そうでないものにも影響を与えるでしょう。私はVMレベルのコルーチンのようなものの代わりに、セグメンテッドスタックに一票を投じます。
InfoQ: ありがとうございました。
インタビュー対象者について
Neal Gafter氏は、Java SE 4、5の言語拡張の主要な設計者兼実装者の一人であった。Neal氏のJava Closures実装は、OpenJDK Innovator's Challenge賞を獲得した。Neal氏は現在進行中のJava SE 7や8の言語の変更について、アドバイスを続けている。以前、Googleのオンラインカレンダーに取り組んでいたことがある。C++標準委員会のメンバーだったこともあり、Sun MicrosystemsやMicrotec Research、Texas InstrumentsでCやC++のコンパイラ開発をリードした。現在は、Microsoftで.NETプラットフォームの言語に関する仕事をしている。また、"Java Puzzlers 罠、落とし穴、コーナーケース"(Addison Wesley, 2005)の共著者でもある。Neal氏はRochester大学のコンピュータサイエンスの博士号を所有している。