BT

Ready for InfoQ 3.0? Try the new design and let us know what you think!

Java 7と8についてAdam Messinger氏が語る

| 作者: Charles Humble フォローする 1009 人のフォロワー , 翻訳者 徳武 聡 フォローする 1 人のフォロワー 投稿日 2011年8月8日. 推定読書時間: 9 分 |

原文(投稿日:2011/08/01)へのリンク

先週のJava 7のリリースを受けて、InfoQはOracleでFusion Middlewareグループで開発部門のバイスプレジデントを務めるAdam Messinger氏に今回のリリースとJava 8についての同社の計画について詳しい話を聞いた。

InfoQ: OracleのJavaに対する"全体的"な計画がどのようなものか教えてくれますか。

OracleはIBMのような大企業から個人開発者までの他のグループも巻き込んでJavaの開発を続けていきます。JCPのようなAPIや使用が開発される団体やOracleがスポンサーになっているGlassFishやOpenJDK、参画しているEclipseのようなプロジェクトにも関わっていきます。私たちの最優先事項はすべての開発者のために時代とともにJavaの生産性、信頼性、技術を進化させ続けることです。

Oracleが生み出したJavaの製品の幅の広さを見るだけでコミットメントのレベルが分かると思います。私たちはJava SE 7をリリースし、Java SE 8を準備しています。GlassFishも既にリリース(3.1)しましたし、今年の暮れには新しいバージョンを出す計画をしています。JavaFX 2.0もほとんど完成しています。Java EE 7も強化していますし、NetBeans 7はそろそろリリースします。これらは既に私たちが達成したことです。もちろん、Oracle Fusion MiddlewareやOracle Exalogic Elastic CloudはすべてJavaベースです。

InfoQ:Java 7で最も重要な機構、面白い機能はなんですか。

ほとんどの開発者はProject Coinによる言語の変化が最も役に立つと考えるでしょう。文字列型によるswitchステートメント、ダイヤモンド演算子、multi-catch例外、try-with-resources構文のような新しい特徴はすべての開発者の役に立つはずです。というのは、これらの新しい機能に共通するのは、既存のコードの可読性を向上させるからです。これらの新しい機能のプロジェクトのリーダーであるJoe Darcy氏は開発者が既存の古いコードや間違えやすいコードの候補を見つけ、より簡潔な新しいtry-with-resources構文に置き換えることが出来るようにアノテーションプロセッサの開発も手がけています。

またFilesystem APIにも触れておきたいです。このAPIはファイル変更通知やシンボリックリンクのような現代的なファイルシステムの主要な機能を提供し、デレクトリ構造の検索のような一括処理をサポートする。私はこれらの機能が最も重要だと思います。

最も面白い機能は新しいFork/Join APIだと思います。これを使えば開発者は並列実行可能なアプリケーションを作ることができます。今まではデータ処理が中心のアプリケーションや複雑なアルゴリズムを必要とするアプリケーションをハイエンドサーバで動かすときだけ、開発者はそのアプリケーションが並列実行され、マルチコアプロセッサアーキテクチャの能力を完全に利用できているかどうか気にする必要がありました。しかし、今や、ディスクトップマシンにクアッドコアが搭載され、ノートパッドやスマートフォンにデュアルコアが搭載されるのが一般的になりつつあります。これからはもっと多くの開発者が並列処理プログラミングを念頭に置かなければならなくなるでしょう。

InfoQ: NIO 2はJavaに本当の非同期APIを導入しました。なぜこれが重要なのですか。どんな場面で利用すればいいのでしょうか。

非同期I/Oは拡張性の高く、多くのI/O処理を必要とするアプリケーションにとって鍵となる機能です。この機能は二重化されたノンブロキングI/Oのようなもので、Java SE 1.4でのNIOの改善で導入された機能の一部です。ノンブロッキングI/O多くのネットワーク接続を扱うのに大変優れていますが、ディスクドライブのようなランダムにアクセスされるI/Oデバイスには不向きです。非同期I/Oシーケンシャルなアクセスでもランダムなアクセスでも上手く動作します。ある種のアプリケーションアーキテクチャには適用しやすいでしょう。ノンブロッキングI/Oもそうですが、多くの開発者は非同期I/O APIを直接使わないでしょう。しかし、使ってみればこのAPIの提供する価値に気付くと思います。

InfoQ: IO 2の新しいファイルシステムAPIはJavaの書けば、どこでも実行できるという原則に違反しているように思えます。単一のファイルシステム上のファイルへアクセスするためのAPIだからです。この方針は正しいのでしょうか。Javaから一般的なシステムコールを可能にするような他の領域へこのAPIを拡張すればいいのではないでしょうか。

WORAの原則に違反しているかどうか私にははっきりしません。もし違反していたとしても、これが初めてではありません。Javaは開発者をプラットフォームの下部の詳細から分離することに成功してきました。しかし、あるプラットフォームが他のプラットフォームに比べて異なる機能を持つということは隠蔽できません。例えば、すべてのコンピュータにディスプレイがあるわけではありません。なのでそのようなコンピュータではSwingのコードは動きません。つまり、ファイルシステムAPIはシンボリックリンクにアクセスできるものの、この機能がすべてのプラットフォームで正常に動作しないことが問題であるなら、そもそも、Javaが動くすべてのコンピュータがファイルシステムを持っているわけではないということを問題にしなければならないはずです!

WORAの原則は堅牢です。この原則はJavaが成功した大きな理由のひとつですので、これからも堅持していきます。しかし、Javaはプラットフォームやデバイス、実装に固有の特徴を取り込むことでより便利にすることで成功を納めていかなければならないと思っています。このようなことに取り組む方法は実証されています。例えば、このような実装依存の部分の拡張を定義するプロバイダと抽象APIを組み合わせる方法です。ファイルシステムAPIやその他の多くのJava APIは標準的なものであれ、そうでないものであれこの方法を利用しています。

あなたの質問に答えるとすれば、ええ、確かにJavaからある種のシステムコールをもっと簡単に行えるようにするのは有意義だと思います。JavaのコミュニティやOpenJDK、JCPなどでこのような議論が起こるといいですね。

InfoQ: Javaにラムダを導入することについて、ラムダはFork/Joinに必要だから導入されるのだ、という言い方がされてきました。なぜ最初にFork/Joinを導入しようとしているのでしょう。ラムダが出来上がったらFork/Joinは中途半端なAPIになってしまいませんか。

そんなことはありません。私たちは並列処理が必要なアプリケーションを実装する開発者のために複数のリリース計画を勧めています。始まりはJDK 1.5のときです。Doug Lea氏とJSR 166の専門家グループはアプリケーションを並列実行できるタスクに落とし込む機能をAPIレベルでサポートしました。JDK 7のFork/Joinフレームワークもゴールへ向かうための一歩です。しかし、このフレームワークを使う場合は開発者は手動でツールの設定をしなければなりませんし、実際に利用するにはある程度の知識が必要です。

私たちの目的は並列実行可能なアプリケーションの設計や実装を今よりももっと自動化することです。Project Lambdaにラムダ式が含まれるのは、関数とフィルタリングやマッピングのような並列アルゴリズムの実装のカプセル化を簡潔に行うためです。この実装はひょっとしたらFork/Joinのような既存の並列実行APIの上に実装されるかもしれませんが、これは本当に実装の細かい部分の話です。ラムダを導入することで並列プログラミングはより一般的になると思います。私はFork/Joinをそのまま扱おうとする'強烈な'開発者は常にいると思っていますが。

InfoQ: ということは、ひょっとしたらJava 8ではフィルタやマップ、リデュースのようなデータを一括で扱う処理を自動的に並列化できるようになるのでしょうか。

このようなデータ一括処理が重要なのは、内部反復処理を通じて自動的に並列実行できるからです。つまり、コレクションのフィルタは外部反復処理である従来のforループを使うよりも、ラムダ式を定義して、それをコレクションのフィルタメソッドに渡すことで実現できます。これは内部で反復処理を行っているのです。フィルタメソッドはどのように反復処理が実装されているか制御するので、マルチプロセッサコアにタスクを割り当てることもできます。しかもこれを開発者はまったく意識する必要がないのです。

InfoQ: Java 7はJVMの初めての新しいバイトコード命令invokeDynamicを導入します。しかし、Project Coinで行われたinvokeDynamicに対応するJavaの構文のための先進的な提案は却下されました。この背景について教えてください。Java 8では盛り込まれると考えていいのでしょうか。

全体的にしっかりと分析した結果、他の言語を実装する圧倒的少数の人々しか使わない機能のためにJavaというプログラミング言語を拡張するのは得策ではないと判断しました。Java 8で見直されるかどうかはわかりません。

InfoQ: JVM上の他の言語のサポートという観点から考えると、将来のVMレベルでの変更から恩恵を受けると思う言語はありますか。

特定の言語が恩恵を受けることはありせん。各言語の開発者がJavaを使いながら興味を持ったことに注意を払うのが私たちの方法です。名前は出せません。JRuby、JavaScript、Scala、Clojureの性能を改善するためにVMを強化しているのは価値あることですが、これはもっともはっきりとして例です。

InfoQ: 言語のサポートの次の優先事項は何ですか。継続ですか。それとも、末尾呼び出しですか。インターフェイス注入でしょうか。Java 8ではこれらの機能が搭載されますか。

この点について話すのは時期尚早だと思います。John Rose氏が多くの言語設計者や実装者と協力して作業をしています。彼らはこれらの機能のプロトタイプを実装して、どれが最も影響があるのかを調べています。先週開催されたJVM Language Summitでは興味深い議論が行われています。ここでその成果を確認できます。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT