ORACLE.COM/JAVAMAGAZINE ////////// JULY/AUGUST 2012

07

blog

COMMUNITY

JAVA TEC

HABOUT US

JAVA IN

ACTION

JCP Executiveシリーズ

Gil Teneに 聞く

この 記 事 は 、J a v a Community Process（ J C P ）から選 ばれた

Executive Committeeのメンバーにインタビューするシリーズの第1回です。今回は、Azu l Sys temsのCTOおよび共同設立者であり、代表も務めるGil Tene氏に、JavaとJCPの現況に対する見解をうかがいました。Azul Systemsは、拡張性に優れたJava仮想マシン（JVM）を開発しており、2003年にJCPのメンバー、2011年11月にExecutive Committeeのメンバーになっています。

Azul Systems CTOのGil Tene氏が、JavaとJCPの状況について語る Janice J. Heiss

Java Magazine: 普段の業務について簡単に教えてください。Tene氏： Azul SystemsのCTOを務めています。Azulは、拡張性の高いJVMの開発に注力しています。ですから、AzulにとってはJavaが世界であり、Javaがすべてです。そのため、JCPやJavaコミュニティがあらゆる活動の中心となっています。Azulでは長年にわたって、拡張性の極めて高いJVMを提供してきました。CPUコアは数個から1000個近くまで、メモリは数ギガバイトから数百、数千ギガバイトまで、どのようなプラットフォームでも動作します。おそらく、Azulの技術でもっともよく知られているのは、並行処理によるガベージ・コレクションでしょう。応答時間の短縮が命題であるエンタープライズ向けJavaアプリケーションでは、ガベージ・コレクションによる動作停止が問題となりますが、これを効果的に解消できます。私は、Azul内でメンバーとともに現場で作業を行っ

たり、カンファレンスへの参加や論文執筆、顧客とのやり取りといった多くの社外活動も担当しています。この業務をAzulで約10年間続けていますが、過去の経験から、これほど楽しい仕事はないと感じています。エンジニアにとって、Azulはおもちゃ屋のような場所です。私は具体的には、並行ガベージ・コレクタからロックとトランザクショナル・メモリまで、拡張性の高いJVMを構成するさまざまな要素に取り組んできました。実行時の拡張性に「効果があることは何でも」行うというのが、設立以来変わらないAzulのやり方です。

写真： MARGOT HARTFORD

カリフォルニア州サニーベールのAzul Systems本社にてウェブキャストの準備を行うCTOのGil Tene氏

ORACLE.COM/JAVAMAGAZINE ////////// JULY/AUGUST 2012

08

blog

COMMUNITY

JAVA TEC

HABOUT US

JAVA IN

ACTION

私自身はカーネルのコードや高度な仮想メモリ管理のためのコードを開発し、新しいプロセッサの機能や命令を設計し、仮想化についてさまざまなことを試してきました。Azulはここ数年、ソフトウェア中

心の製品に力を注いでいるため、Javaプラットフォームの行く末は以前にも増して重要な問題となっています。単にJCPを支持するのではなく、JCPのリーダーシップに貢献したいと考えています。Azulは、Javaの最先端に近づきつつあります。Azulのソフトウェアを利用してくださる方もますます増え、それにつれて、開発者はJavaにより深くかかわることを求めるようになっています。Azulでは、Java EEの活動も多くを支援していますが、技術的に重点を置いているのは、専門知識を有するJava SEです。Java Magazine: JCPについておもに気にかけていることは何ですか。Tene氏： AzulがJCPのメンバーになってから、およそ9年になります。2011年には、JCPにより積極的にかかわることを目的に、Executive Committeeに加わりました。コミュニティのだれもがそうだったように、私たちも、オラクルがSunを買収したことでJavaプラットフォームが変化するのではないかと懸念していました。そこで、第三者として傍観するのではなく、積極的に関与することにしました。Azulの関心は、JCPが1つの企業に支配されるような事態を防ぐことにあります。つまり、JCPが単にオラクルの意向を承認するだけの形式的な機関にならないようにするということです。オラクルもJCPをそのように形骸化させるこ

とは望んでいないと信じています。そのためには、プロセス、ルール、

ガバナンスを形成する会社役員のメンバーから、標準化に取り組む専門家グループ、さらにはコードの開発などさまざまな方法で貢献する人々まで、JCPのメンバーがあらゆるレベルで参画する必要があります。Javaが一企業のプラットフォームとなることは望ましくありません。だからこそ、コミュニティがリーダーシップを担う必要があります。Java Magazine: イノベーションの奨励と安定した標準の策定と

のバランスを保つために、JCPはどうあるべきでしょうか。Tene氏： Tイノベーションと安定した標準の間には矛盾が発生する場合と、発生しない場合があり

ます。個人的には、JCPが、標準として、またコミュニティの主体として、信頼性と生産性を維持できる範囲に留まることが重要だと思います。最近、ソーシャル・メディアAPIに関するJJSR 357が議論になったことをご存じでしょうか。Java向けの標準ソーシャル・メディアAPIが必要だというものでしたが、Executive Committeeは8対5で否決しました。Azulは反対票を投じました。私の考えでは、JCPの管理下にありJCPの目的の範囲内にある領域であれば、しかも関係するテーマについて業界を先導している信頼できる専門家グループをJCPが組織できるのであれば、JCPは革新的であるべきです。しかし、このような領域の外では、JCPは革新的であろうとしてはならないと思います。Javaプラットフォームの範疇から大きく外れ、しかもまだ変化の過程にある安定性に欠ける技術をJCPで標準化しようとすることは、私の意見では、根本的に誤っています。だれにも

イノベーションに ついてJCPは革新を実現する場です。 しかし、そのイノベーションについては、JCPの管理が及び、JCPの目的の範囲内にあるものに集中するべきです。

現在のプロジェクトについて話し合うTene氏とAzulのエンジニアリング・チームのメンバー。Azulでは、4年勤めたチーム・メンバーの全員に研究者用の白衣が渡される。

ORACLE.COM/JAVAMAGAZINE ////////// JULY/AUGUST 2012

09

blog

COMMUNITY

JAVA TEC

HABOUT US

JAVA IN

ACTION

利用されない標準ができるだけでしょう。 JCPはJavaプラットフォームを前進させるた

めに存在しています。しかし、動作の安定化、モデル化、標準化の取り組みが業界ですでに始まっている分野においては、JCPの役割は、その取り組みを統率することではなく、その取り組みに従うことです。たとえば、XMLがまだ変化の過程にあり、W3CがXML標準の概要すら決定していない段階で、JCPがXMLを標準化しようとすることを想像してください。JCPは、そのような未確定な技術を標準化する場としては適切ではありません。しかし、外部の標準をJavaのAPIとして取り込む場としては、間違いなく適しています。Java Magazine: JCPに対するコミュニティの参加を促進するにはどうすればいいでしょうか。 Tene氏： 多くのアイデアが飛び交っていますが、私は、JCPの間には矛盾が発生する場合と、発生しない場合があります。を実現する場だと思っています。JCP以外で、Javaプラットフォームをイノベーションする者はいません。しかし、そのイノベーションについては、JCPの管理が及び、JCPの目的の範囲内にあるものに集中するべきです。たとえば、Java SEの将来のバージョンで、新しい構文や機能、APIを伴う特定の機能を追加しようとする場合、あるいはJava EEにおけるコンテナの新しい動作方法を定義しようとする場合、それらを標準化する唯一の場がJCPです。機能のプロトタイプ作成にはJava.netやオープンソース・コミュニティで取り組み、さまざまな実装を試行できますが、Javaプラットフォームやその機能を定義する役割については、JCPが担います。したがって、コミュニティ上での開発と革新的な

取り組みを結びつけること、そしてその取り組み

がJCPのプロセスに自然に取り込まれるように支援することが、JCPが本来の役割を果たしながらコミュニティの参加を維持し促進するための最適な方法だと私は考えます。Java Magazine: JCPが解決する必要のあるおもな問題について教えてください。 Tene氏： ライセンス、知的財産へのアクセス可否、透明性に関して明確化が求められており、多くの人が関心を向けています。JCPでは、

Executive Committeeで対応を進めており、特にJSR 348によって透明性などのプロセス・ルールに対処するJCP.nextという取り組みが始まっています。この取り組みにより、ワーキング・グループ内の透明性が向上します。これは適切な第1歩ですが、今後、JCP.nextのプロセスにはさらなる2歩目、3歩目が必要です。構造的な取り組みや手続き的な取り組みもありますが、より基本的な取り組みとしては、TCK [Technology Compatibility Kit]の実際の実装に対するアクセス可否の明確化という問題があります。どんなルールにするか、アクセスを提供するために仕様のリーダーは何をするかといったことです。この問題は多くの強硬な意見が介在する、いわば危

険地帯となっています。一方で、すべてを強制的にオープンソースとす

ることを求める人がいます。私個人は、全オープンソース化が実現可能な道であるとは思いません。むしろ、標準を正しく機能させるためには、ソリューションの形を問わない環境が必要だと考えています。商用で厳しい管理下にある独自仕様の実装であろうが、無償でオープンソースの実装であろうが、採用できるようにするべきであり、同じ標準に従うべきです。 そのため、JCPが特定のライセンス条項を押し

コミュニティについてコミュニティ上での開発と革新的な取り組みを結びつけること、そしてその取り組みが JCPのプロセスに自然に取り込まれるように支援することが、 JCP が本来の役割を果たしながらコミュニティの参加を維持し 促進するための最適な方法だと私は考え ます。

磁石式の模型組立てキットを使ってAzul のエンジニアとブレーンストーミングをするTene氏。

ORACLE.COM/JAVAMAGAZINE ////////// JULY/AUGUST 2012

10

blog

COMMUNITY

JAVA TEC

HABOUT US

JAVA IN

ACTION

付けたり、特定のライセンスの許可または禁止を言明したりすることは、すべきではないでしょう。ただし、一定のガイドラインや制限は必要であると思います。たとえば、TCKに対して、既知の予測可能な条件に基づき、信頼できる方法で永続的にアクセスできることは、実装に投資し、JCPが定める標準に従う企業、プロジェクト、および個人にとって不可欠です。そのようなアクセスを提供するためにJSRが満たす必要のある最低限の要件は、明確かつ厳密に定義する必要があります。この点については、ここ数年は停滞しています。Java Magazine: JCPの透明性やオープン性を高めるという約束をオラクルは果たしてきたでしょうか。Tene氏： オラクルはその過程にある、といえるでしょう。約束を果たしたとは言えません。オラクルは多くの約束を掲げ、前向きな姿勢を示していま

すが、実際の成果が出たと言うにはまだ早すぎます。そのため、コミュニティの一員として、継続的に見守る必要があると考えています。Executive CommitteeにおけるAzulの役割の1つは、オラクル社外の監視の目となって、誤った方向に進んでいるときにはそれを指摘することです。具体的な例を挙げましょう。JCPはJSR 348

をリリースし、コミュニティの要望に合ったコミュニティの取り組みを実現するため、ルールを改善して透明性を向上しました。しかし、このプロセスはまだ半分しか終わっていません。今後のJSRで対応する予定のJSPA [Java Specification Participation Agreement]文書などに関連した多くの仕事が残っています。私たちが特に懸念しているのは、新しく制定し

たルールが、それまでの作業のやり方と矛盾するという安定性に欠ける状況です。つまり、1年前に当時のプロセスでうまく行っていたやり方が、新しいルールと矛盾してしまうという状況です。このような問題には、まだ解決されていないものがあります。できることとできないことを規定するような新しいルールは、以前にはできたことを行う際の妨げになることがあります。たとえば、JSRの専門家グループが議論し作業する資料に機密情報を含めることは、JCP 2.8とJSR 348に定められた透明性に関するルールや要件と矛盾すると私は考えています。しかしJSPAでは、場合によってJSRに関する作業についてさまざまな水準の機密性を確保することを許可しており、専門家グループのメンバーに対して機密性の確保を要求する場合すらあります。このような矛盾は、ルールの変更やJCP.nextの取り組みによって解決されなければ、JSRの作業が頓挫する原因となる可能性があります。

Java Magazine: Javaが古くなっているという見方や、Javaがまもなく他の言語やプラットフォームに置き換わるだろうという見方がITコミュニティ内にあると思いますか。Tene氏： Javaが古くなっているという見方はあると思います。イノベーションが減速しているという議論をよく聞きます。興味深いことに、このようなことを耳にする文脈は、たいていの場合、実際に古いプラットフォームを追い越して置き換わろうとしている新技術に関するものです。しかし、Javaプラットフォームがそのような新技術に追い越されることはないと私は考えています。Javaプラットフォームには約17年の歴史があり、これまでに極めて大きな成功を遂げています。Javaは、登場してから2年ないし3年で、他の開発および配備プラットフォームに置き換わろうとしていることが明らかになっていました。私が見るところ、現在の新興プラットフォームで、当時Javaが他のプラットフォームを脅かしていたようにJavaを脅かしているものはありません。動的言語や関数言語、迅速な開発のための技法などの技術革新には、新しく興味深い発展が数多くあり、中にはJava言語でない技術もあります。しかしその大部分は、むしろJavaプラットフォームを対象とし、Javaプラットフォーム上で実行するものであって、Javaを脅かすものではないのです。 </article>

Janice J. Heiss ： オラクルのJava編集者であり、Java Magazineのテクノロジー編集者

LEARN MORE• Java Community Process

Azul のエンジニアリング・チームの メンバーと話すTene氏。

準拠についてJCPは Javaプラットフォームを前進させるために存在しています。しかし、動作の安定化、モデル化、標準化の取り組みが業界ですでに始まっている分野においては、JCPの役割は、その取り組みを統率することではなく、その取り組みに従うことです。