Java 技術、IBM スタイル: Java 技術の新たな時代

Oracle 仕様のハイライト、そして IBM がパフォーマンス、信頼性、保守容易性に与える付加価値

Java™ SE 7 の待望の最終リリースでは、Java 言語および仮想マシンの主要な側面のすべてで機能が強化されると期待されています。Oracle と IBM ではすでに、それぞれの Java SE 7 実装について検討およびフィードバックができるように Early Access 版ダウンロードをリリースしています。この記事では IBM Java Technology Center で Java サービス・ストラテジーのアーキテクトを務める Chris Bailey が、Oracle 仕様による変更、そして IBM が提供する付加価値による変更の両面から、新規リリースの内容を紹介します。

Chris Bailey, Java Support Architect, IBM

Chris BaileyChris Bailey は、英国の Hursley Park Development Lab を拠点とする IBM JTC (Java Technology Center) チームの一員です。IBM Java サービスおよびサポート組織でテクニカル・アーキテクトを務める彼は、IBM SDK のユーザーをアプリケーション・デプロイメントの成功に導くことを任務としています。また、新しい要件の収集と評価、新しいデバッグ機能とツールの実現、資料の改善、そしてIBM SDK for Java の全体的な品質改善にも携わっています。



2010年 4月 20日

この秋に最終リリースが見込まれている Java プラットフォームの最新アップデートは、その大幅な変更内容に大きな期待が寄せられています。Java 7 プラットフォームの JSR (Java Specification Request) は JCP (Java Community Process) で正式に作成されるまでには至っておらず、最終的な機能セットはまだ公表されていませんが、Oracle が提供している Early Access 版ダウンロード (「参考文献」を参照) と Oracle チームの公式見解から、Java SE 7 に期待される新しい機能の内容は十分に理解することができます。

期待されている機能は、大まかに以下の 4 つのカテゴリーに分類することができます。

  • Java 以外の言語のサポート
  • 開発しやすくするための更新
  • モジュール方式のサポート
  • 拡張性に関する更新

Java 以外の言語のサポートと JSR 292

Java 7 での改善により、動的型付け言語のコンパイラー実装者は、Java ランタイム対応の実装を容易に作成できるようになるとともに、これらの実装を今までより遥かに優れたパフォーマンスで実行できるようになります。この変更の推進力となっているのは、JSR 292 です。JSR 292 では、新しいバイト・コードと多数の新規 Java クラスを導入しています。

ほとんどの場合、Java 言語では強い型付けがされることから、指定のメソッドとの間で、パラメーターの型を受け渡しする必要があります。けれどもバイト・コード・レベルでは、Java はもっと弱い型付けがされます。オペランド・スタックでの変数が型付けされるのは、それらの変数がどのプリミティブ・タイプであるかという観点、もしくはそれらの変数は一般的にオブジェクト参照であるという観点からのみです。バイト・コードでの弱い型付けは、ほぼすべての場合に当てはまりますが、メソッド呼び出しは例外です。メソッド呼び出しの場合には強い型付けが強要されます。つまり、呼び出す対象とするメソッドには、パラメーターの型と戻り値の型が含まれる完全なシグニチャーによって強い型付けがされるということです。この場合、呼び出しは既知の Java の型を使用する Java メソッドに対して行わなければなりません。これは、動的に型付けされる Ruby、Python、Groovy などの動的言語では問題になります (型は、実行時にならないと既知になりません)。

この問題を回避して、動的言語を JVM で実行できるようにするメカニズム (通常はリフレクションをベースにしたメカニズム、あるいは呼び出し元を生成して使用するメカニズム) もありますが、これらのメカニズムにはかなりのパフォーマンス・ヒットが伴います。そこで JSR 292 を導入し、動的メソッドを呼び出すための新しい Java バイト・コード invokedynamic を追加するとともに、実行時にメソッドと接続しなおすことができるメソッド・ハンドル構成体を使用した Java 言語リンケージ・メカニズムを組み合わせることで、こうした問題を解決しようとしました。


開発しやすくするための機能

Java プラットフォームのこれまでのリリースと同じく、よく使用される構成体に必要な構文を単純化するために、数々の新しい言語機能が追加されています。

Project Coin

Project Coin が扱っている数々の細かな変更 (「コイン」) は、単純なタスクをプログラミングする際の複雑さを軽減し、完成したコードを読み易くすることを目的としています。

  • switch 文での String
    Java 7 より前のリリースでは、switch 文で StringObject を使用することはできません。つまり、Stringswitch スタイルの操作を実行するには、一連の if-then-else 文を使うか、String をプリミティブ型または enum 型に変換するしか方法はなかったということです。switch 文で String を使用できるようになるということは、以下のような単純な構成体が認められることを意味します。

    switch (myString) {
                   case "one": <do something>; break;
                   case "red": <do something else>; break;
                   Default: <do something generic>;
    }
  • Generics インスタンス生成のための型推論の改善
    Java 5 で導入された Generics では、Generics のコレクション・クラスをインスタンス化する際にパラメーター化した型を適用し、コンパイル時に安全性チェックを行えるようになりました。けれども Generics を実装すると、型パラメーターが不必要に重複する結果となってしまいます。以下はその一例です。

    Map<String, List<String>> anagrams = new HashMap<String,
    List<String>>();

    型付けを改善したことで、2 番目の <> 構成体を以下のように推定することができます。
    Map<String, List<String>> anagrams = new HashMap<();
  • varargs メソッド呼び出しの単純化
    現在、可変長の引数を受け入れるメソッドを呼び出すと、呼び出し側コードはコンパイル時に安全でない操作を行っているという警告を受け取ります。単純化された varargs メソッド呼び出しでは、この警告が可変長の引数を受け入れるメソッドの宣言に移されるため、呼び出し側コードに含めなければならない警告の数が減ります。
  • コレクションの言語サポート
    配列を初期化する構文では、以下の構文を使用して配列に含める値を指定することができます。

    int[] array = new int[] {0,1,2,3,4,5}

    この構文は、コレクションに適用されるようになりました。以下はその一例です。

    List<String> numbers = ["one", "two", "three", "four",
    "five"];
  • 自動リソース管理
    この機能強化は、手動で閉じなければならない InputStreamOutputStream などのリソースを 1 つ以上宣言する新しい形の try 文を提供します。この新たな try 構文では、try 文の実行が完了すると、宣言されたリソースが自動的に閉じられるようになっています。

    static String readFromFile (String file) throws IOException {
                try (BufferedReader reader = new BufferedReader(new FileReader(file)) {
                               return reader.readLine();
                } // resources are automatically closed here
    }

クロージャーに関する議論

クロージャーはこれまで、Java コミュニティーで大いに物議を醸してきました。クロージャーを含めるかどうか、そしてどのように含めるのが最適であるかなどの論争です。2007年に Brian Goetz が示した当時のクロージャー論争についての見解は、この数年間、賛否が定まっていません。Neal Gafter は Java 言語にクロージャーを追加することを積極的に支持してきました。彼は自身の「Closures for Java」ページで、Java におけるクロージャーについて豊富な情報を提供しています。

クロージャー (大きな変更)

Scheme、Ruby、SmallTalk をはじめとする多数のプログラミング言語では、クロージャーやラムダ関数を使用することができます。最終的な Java 7 仕様にはクロージャーの実装が組み込まれることになると予想されていますが、競合するさまざまな提案があるため、その実装の詳細はまだ明らかになっていません。


モジュール方式のサポート

Java プラットフォームの新しいバージョンがリリースされるごとに、SDK のサイズは大きくなってきました。これは、多種多様な環境で使用できる機能が増えたことに伴う残念な副次作用です。確かにこの大量の機能は資産ではあるものの、極度にサイズが大きくなり、複雑さが増してくると、ダウンロード・サイズや起動時間、そしてメモリー・フットプリントという重要なパフォーマンス・メトリックに影響を与えることになります。

Project Jigsaw

Java の技術、文化、業界の現状について話し合っている developerWorks の記事で、Project Jigsaw の詳細および、Java モジュール・ソリューションでの役割について学んでください。

こうした問題に対処するために Java 7 で予定されているのが、モジュール式 JDK ランタイムの提供です。Project Jigsaw と呼ばれるこのランタイムでは、ユーザーがアプリケーションを実行するのに必要なコンポーネントだけをダウンロードして、ロードすることができます。さらに、ライブラリーとアプリケーションにもモジュール方式を適用できるようになるはずですが、その詳細な実装はまだ決まっていません。

拡張性に関する更新

マルチコア・システムが普及し、マルチコア・システム内で使用されるコアの数が増え続けているなか、Java 言語もそれに伴って拡張性を向上させることが重要な課題となっています。その延長線上で考えると、開発者は拡張可能なコレクション、データ構造体、そしてアルゴリズムを使用しなければならないということです。バージョン 7 でも引き続き、Java 言語の拡張性に関する改善を New I/O 2、並行性およびコレクションの更新という 2 つの主要な機能によって進めています。

New I/O 2

JSR 51 によって 1.4 リリースに導入された一連の Java プラットフォーム用 New I/O (NIO) API では、ネイティブ・コードを開発することなく、極めて拡張性の高い I/O を開発できるようにすることを目指しています。JSR 51 は主にバッファーとチャネルに重点を置き、非ブロック多重化 I/O を実現しました。1.4 リリースで開始されたこの取り組みを拡大するのが、JSR 203 によってバージョン 7 に登場した (新しい) New I/O API (NIO.2) です。

NIO.2 API で改善された主なものとして挙げられるのは、非同期 I/O 処理、更新された SocketChannel 機能、そして大幅に改善されたファイルシステム・インターフェースの 3 つです。これらの更新のそれぞれが、極めて拡張性の高い I/O インフラストラクチャーの実現を可能にするというテーマを引き継いでいます。

  • 非同期 I/O 処理
    Java プラットフォームのバージョン 7 は、ソケットとファイルの両方に非同期 I/O 処理を導入するために、新たな AsynchronousChannel のセットを提供します。これによってスレッドは、I/O 処理の続行中に処理を続け、I/O 処理が完了すると通知を受けることができます。バージョン 7 には、2 つの通知メカニズムが用意されています。一方の通知メカニズムでは、非同期 I/O 処理を呼び出すと、結果オブジェクトを表す java.util.concurrent.Future オブジェクトが返されます。このオブジェクトが提供する API によって、I/O 処理が完了するまで待機することも、現行の状態をポーリングすることもできます。もう一方の通知メカニズムは java.nio.channels.CompletionHandler を指定し、I/O 処理が完了するとコールバックで指定のハンドラーを呼び出します。
  • 更新された SocketChannel API
    NIO.2 で SocketChannel API が更新されるまでは、ネットワーク・チャネルの実装はネットワーク・ソケットを完全に抽象化しないため、ネットワーク・チャネルを作成するにはソケット API とチャネル API の両方を使わなければなりませんでした。SocketChannel API の更新ではこの問題を解決するために、ネットワーク指向のチャネルのそれぞれに、bind()getLocalAddress()getOption()、および setOption() メソッドを定義する新しい NetworkChannel インターフェースを実装させます。さらに、新規 MulticastChannel インターフェースにより、マルチキャストのサポートも追加されます。
  • 改善されたファイルシステム API
    改善されたファイルシステム API は、標準 Java ファイル I/O API に伴ういくつかの根本的な問題 (例えば、ファイルの削除や名前変更などの操作中に I/O 例外が発生しないなど) を解決します。さらに、よく実行されるのにもかかわらず、これまでは提供された API をベースにカスタムでコードを作成しなければ実行できなかったタスクに新たなサポートを追加しています。この新しいサポートには、ファイル、シンボリック・リンク、およびファイル・アクセス許可のコピーと移動のサポート、そしてファイルの変更通知と監視 API の提供に対するサポートも含まれます。

並行性およびコレクションの更新

java.util.concurrent パッケージは、JSR 166 により Java 5 で導入され、Java 6 では JSR 166x によって拡張されました。Java 7 での並行性は JSR 166y によってさらに更新され、JSR のリーダーである Doug Lea が「マルチコアに適した軽量の並列フレームワーク」と称する新しいフォーク/ジョイン・スタイルのフレームワークが追加されています。その他の並行性の拡張には、TransferQueuePhaser もあります。

フォークを活用する

Java 7 の登場までに、かなりの時間がかかっていることは、Brian Goetz が 2 年も前に書いた、フォーク/ジョイン・スタイルのフレームワークに関する人気の 2 回連載の記事が証拠となります。この連載の第 1 回では、さまざまなアルゴリズムを分解し、ハードウェアによる並列処理を効果的に活用するための機構について紹介し、第 2 回では、メモリー内のデータ構造に対する並列ソートや並列検索の操作を単純化する ParallelArray クラスについて説明しています。

  • フォーク/ジョイン・フレームワーク
    フォーク/ジョイン・フレームワークの目的は、複数の並列タスクに分割することのできるタスクを高速に実行できるようにサポートし、複数のプロセッサーおよびコアを効率的に活用できるようにすることです。

    多数の並列タスクに分割可能な演算の代表例は、マージ/ソート・アルゴリズムです。このアルゴリズムでは、ソートするデータが複数のフラグメントに分割され、個々のフラグメントがサブタスクとして個別にソートされます。これらのサブタスクが、さらに細分化されたサブタスクに再帰的に分割されることもあります。そしてサブタスクが完了した時点で、結果が結合 (マージ) されます。このプロセスは、指定されたタスクを複数のサブタスクにフォーク (分割) し、サブタスクの完了を待ってジョイン (結合) するという方法で行われます。Java 7 に追加されたフォーク/ジョインのフレームワークは、他のサブタスクが完了するまで待機することによる影響を減らすためのプールとワーク・スティーリングを含め、フォーク/ジョイン処理を実行するためのインフラストラクチャーを提供します。
  • TransferQueue
    TransferQueue クラスは一種の BlockingQueue ですが、記録された配信サービスを提供するという点で異なります。オブジェクトを BlockingQueue に入れるスレッドは、オブジェクトがキューに正常に追加された時点で制御を戻しますが、オブジェクトを TransferQueue に入れるスレッドは、そのオブジェクトが別のスレッドによってキューから削除されてからでないと制御を戻しません。
  • Phaser
    Phaser クラスは、新しい柔軟性の高い同期化バリア機能となります。このクラスは Java 5 で導入された既存の CyclicBarrier と同様ですが、いくつかの機能が追加されています。具体的には、登録されるスレッドの数を動的に変更する機能などです。

IBM が提供する付加価値

JVM 仕様と Java クラス・ライブラリー API の更新に伴って Java プラットフォームの新規リリースで必要となった機能更新に加え、各 Java ベンダーはそれぞれの Java 成果物に独自の改善を加えて付加価値を提供できるようになっています。IBM の Java 成果物の場合、そのような付加価値のある機能強化は、パフォーマンス、信頼性、そして保守容易性という 3 つの領域で行われています。

ランタイムのパフォーマンス

アプリケーションのデプロイメントに対する投資の収益率は、Java ランタイムのパフォーマンスによって直接左右されます。このことから、大まかな投資収益率を把握できるように、特定のデプロイメント・シナリオや作業負荷を模倣するさまざまな標準ベンチマークが作成されてきました。これらのベンチマークの大部分はランタイムのパフォーマンス (アプリケーションの実行可能速度) に焦点を絞っていますが、IBM ではアプリケーションに必要な初期起動時間についても考慮しています。

IBM による Java SE 7 の実装について詳しく学ぶには

IBM の Java SE 7 のアーキテクト・リーダーを務める Trent Gray-Donald が、このポッドキャストで Oracle Java 7 仕様、IBM が提供する付加価値、そして Java 技術の現状について、彼の考えを語っています。

起動パフォーマンス
IBM チームが Java アプリケーションの起動パフォーマンスを重要視した理由の 1 つは、起動に時間がかかるとクライアント・サイドのアプリケーションのユーザビリティーに影響を与えるため、そしてもう 1 つは、起動時間によってサーバー・サイドでのアプリケーションのリサイクルおよびフェール・オーバーのシナリオに影響する可能性があるためです。

IBM SDK for Java 5 で、IBM は Java アプリケーションの起動時間および再起動時間を短縮するための主要な機能を、クラスの共有という形で提供しました。この手法によって可能になったのは、共有メモリー内にある永続的な動的クラス・キャッシュに、システム・クラスとアプリケーション・クラスのすべてを (極めて重要な点として) クラス・データの検証が行われた状態で保管することです。したがって、Java アプリケーションがクラスをロードするときには、起動時にロードされる大部分のクラスを共有メモリーからロードできるため、バイト・コードの検証によるオーバーヘッドがなくなります。

IBM SDK for Java 6 でも起動パフォーマンスに対する取り組みは続けられ、ある程度最適化された JIT (Just-In-Time) コンパイル・コードが共有クラス・キャッシュにインクルードされるようになりました。これは、起動時に発生するもう 1 つの大きなオーバーヘッドが取り除かれることを意味します。それは、頻繁に使用されるメソッドをアプリケーションの起動時にコンパイルすることによって発生するオーバーヘッドです。

IBM SDK for Java 7 は、共有キャッシュのデータ保管量を増やしたり、通常の単一スレッドによる起動アクティビティーを複数のスレッドで実行したりすることに重点を置き、起動パフォーマンスをさらに改善します。

ランタイムのパフォーマンス
Java アプリケーションのパフォーマンスは、すべての Java ベンダーとは言わないまでも、ほとんどの Java ベンダーが常に重点を置いています。Java 技術対応の IBM ランタイムもその例に洩れず、パフォーマンスを高い優先度で扱っています。IBM ランタイムの各リリースは、いずれも前のリリースを上回るパフォーマンス改善を目標としてきました。

表 1 に、AIX で IBM の 32 ビット版 Java ランタイムを使用した場合の SDK for Java 5 と SDK for Java 6 のパフォーマンスを比較し、バージョン間での改善率を示します。

表 1. IBM SDK for Java のパフォーマンス
IBM SDK for Java結果 (bops/JVM) 4 コア結果 (bops/JVM) 8 コア結果 (bops/JVM) 16 コア
V5877378668686497
V610295910073199844
改善率17.3%16.2%15.4%

: このデータは、spec.org で公開されている SPEC JBB2005 ベンチマーク・データから引用しています。使用されているのは、4.7 GHz の IBM System p 570 で稼働する IBM Java ランタイムです。

IBM SDK for Java 7 でも、ランタイムのパフォーマンスが重要なことに変わりはありません。新機能については、それぞれ使用可能になった時点で Open beta program ページに詳細を記載します。

信頼性

Java ランタイムの信頼性は何にも増して重要です。それは、ビジネスに不可欠なアプリケーションを毎日 24 時間休むことなく実行しなければならない場合には尚更のことです。極めて信頼性の高いランタイムを実現するため、IBM チームは開発段階に多数の品質プロセスを導入し、コード・ベースを作成してはテストするというストラテジーを用いて、テスト・カバレッジとテスト・シナリオを最大にしています。

すべてのプラットフォームに共通のコード
IBM SDK for Java 5 のリリース以来、IBM の Java ランタイム実装の基礎となるすべてのコンポーネントは、共通のコード・ベースにほんのわずかなプラットフォームまたはアーキテクチャー固有のコードを加えて作成されています。IBM が IBM SDK for Java 6 で提供したリリースは 14 を数えます。これらのリリースは、Windows からメインフレーム上の z/OS に至るまで、多岐にわたるプラットフォームでの 31 ビット、32 ビット、64 ビット版を網羅しています。この広範なハードウェアおよびオペレーティング・システム構成を使用してテストすることで、さまざまなシナリオでの信頼性を確実にすることができます。さらに、ある 1 つの構成でバグを見つけて修正すれば、すべての構成でコードが改善されることにもなります。このテスト・シナリオの幅の広さが、検出しにくいタイミングや同期関連のバグを特定できる可能性を大きくしています。

IBM SDK for Java 7 を形作るための支援

オープン・ベータ版プログラムでは、最新の IBM SDK for Java 7 ベータ版にアクセスすることができます。新しく追加される可能性のある技術や機能を前もって検討し、オープン・ベータ版プログラムのフォーラムにフィードバックすることができます。

製品ポートフォリオ
IBM Software Group 製品ポートフォリオのほとんどで使用されているのは、Java コードです。これは、IBM では高品質で信頼性に優れた Java ランタイムを実現することを常に重視しているというだけではなく、IBM ソフトウェア製品ラインでは大量のテストが実行されることも意味します。通常の Java ランタイム (オープンソース製品のテストも含め) に適用されるテスト・シナリオは、IBM ソフトウェア製品での典型的な各種デプロイメント・シナリオおよび負荷のシナリオのテストと組み合わせられます。この幅広く、奥の深いテストは、Java 技術に対応した IBM ランタイムの品質、信頼性を確実にするのに役立ちます。また、この IBM Software Group 製品ポートフォリオに加え、多くの ISV パートナーも IBM ランタイムに対してそれぞれの各種ソフトウェア・シナリオをテストするため、使用ケースの対象範囲がさらに広がります。

保守容易性

あらゆるベンダーと同じく、IBM もアプリケーション・デプロイメントのバグをなくそうと努力していますが、それでも予期せぬ結果をもたらす欠陥が生じることは、ソフトウェア開発の認められた事実です。IBM では問題の原因を究明し、解決するために、デプロイ済みの Java アプリケーションや Java ランタイム自体での問題のトラブルシューティングを支援する監視診断機能およびツールを提供しています。

デバッグ機能

  • ダンプ・エンジンの機能強化
    ダンプ・エンジンは、非破壊システム・ダンプからスレッド・ダンプに至るまでの多種多様なデータを生成する機能、あるいは特定のコマンドラインを実行する機能を提供します。新しいリリースでは、これらのダンプ生成対象イベントの範囲が一層広くなります。

    IBM SDK for Java 7 では、新しいタイプのダンプを生成することができます。その一例は、イベントの原因となっているスレッドに対して単一のスタック・トレースを生成する「スタック」タイプです。さらに、オブジェクトが割り当てられると発生する「割り当て」イベントをはじめ、ダンプ対象のイベントの数も多くなっています。
  • トレース・エンジンの機能強化
    トレース・エンジンは、Java ランタイムの内部や、Java ランタイムで実行中の Java コード (コア・クラス・ライブラリー、ミドルウェア・コード、あるいは独自のアプリケーション・コードなど) の内部で何が起こっているのかを、インスツルメンテーションなしでトレースできるようにします。トレース・エンジンはコードの実行をトレースするだけではありません。コードの実行をトリガーすることも可能です。最も基本的なレベルでは、トリガーを使用してトレースのオン/オフを切り替えることにより、生成されるトレース・データの量を減らすことができます。さらに、ダンプを生成するためにトリガーを使うこともできます。トリガーを使用して生成できるダンプには、jstracktrace という新しいダンプも含まれます。このダンプは、呼び出し側コードのスタック・トレースと、任意の遅延を実行中コードに挿入できる「スリープ」オプションを提供します。
  • Java ダンプの機能強化
    javadump ファイルには、アプリケーション内の全スレッドのスタック・トレースを含め、実行中のランタイムの状況が要約されて記録されます。このファイルに関しても更新が行われました。その変更は、オペレーティング・システムの ulimit および環境変数、そしてスレッドごとのネイティブ (C) スタック・トレースという形になっています。これらの変更により、Java ランタイムが Java コードの代わりに何を行っているのか、あるいは任意の JNI (Nava Native Interface) コードで何が起こっているのかをより詳しく理解できるようになります。
  • 診断コレクター
    一般保護エラーや OutOfMemoryError などの問題イベントが発生すると、IBM Java ランタイムは問題の原因に関する有用な情報が含まれる多数の診断ファイルを生成します。これらの診断ファイルが生成されると、その直後に診断コレクターというツールが稼働します。このツールは、システム・ダンプ、Java ダンプ、ヒープ・ダンプ、Java トレース・ダンプ、そして問題イベントのタイムスタンプと一致する詳細な GC ログを検索した後、ディスクの占有スペースを節約するために問題イベントのすべての診断ファイルを単一の .zip ファイルに圧縮します。そのため、その有無が定かではないファイルを手動で検索する必要がなくなります。

IBM Monitoring and Diagnostic Tools

  • GCMV (Garbage Collection and Memory Visualizer)
    GCMV はアプリケーションの verbose:gc 出力またはオペレーティング・システム・メモリーの監視データを分析し、分析結果をグラフ形式と表形式の両方で表示します。また、簡潔な要約を提供し、情報を解釈して一連の調整案を提示するとともに、Java メモリー・リークを検出します。この解釈により、アプリケーションのメモリー使用状況のプロファイルを理解し、ガーベッジ・コレクターのパフォーマンスが改善されるように調整することができます。
  • Dump Analyzer
    Dump Analyzer は、Java アプリケーションの失敗の原因をオペレーティング・システム・レベルのダンプを使って判断できるようにするツールです。このツールは個別のアナライザーを使用して、特定の問題に対する回答となる具体的なデータを生成します。これらの個々のアナライザーを 1 つに組み合わせ、あらゆる問題の原因とアプリケーションのステータスに関するレポートを生成します。
  • Health Center
    Health Center は、実行中の Java アプリケーションの現在のステータスを評価できるようにする、オーバーヘッドの小さいリアルタイムの監視ソリューションです。Health Center はパフォーマンス、メモリーの使用状況と管理、最適化およびプロファイルに関する簡潔でわかりやすい情報を提供します。Health Center が具体的に提供する情報には、メソッドが呼び出されている頻度と呼び出し側スタック・トレースを示すメソッド・プロファイル情報、アプリケーションで同期化されたコードのパフォーマンス情報、そして Java ヒープおよびプロセス全体でのメモリー使用量に関するデータがあります。
  • Memory Analyzer
    Memory Analyzer は、DTFJ (Diagnostic Tool Framework for Java) を使用して Eclipse MAT (Memory Analyzer Tool) を拡張することにより、Eclipse MAT の診断機能を IBM Java ランタイムにもたらします。この拡張は、オペレーティング・システム・レベルのダンプと IBM PHD (Portable Heap Dumps) を使用して Java ヒープを分析することを可能にするため、メモリー・リークの原因の診断やアプリケーションのフットプリントの分析を行ったり、Java コレクションのサイズと効率性を検討したりできる他、任意の時点でのアプケーションの状態を把握したりすることができます。

まとめ

Java 7 SDK への取り組みは、Oracle でも、IBM でも順調に進行していることは明らかです。このリリースの仕様と内容は絶えず変更されていますが、この記事の内容から、現状についての十分な洞察を得られたはずです。現在の開発状況は、Early Access プログラム (「参考文献」を参照) でも追跡することができます。このプログラムを利用して、皆さんも開発プロセスに関与し、自分にとって重要なフィーチャーや機能に関するフィードバックを送ってください。

参考文献

学ぶために

  • IBM Java SE 7 設計リーダーのインタビュー: Trent Gray-Donald はこのポッドキャストで、Java SE 7 仕様、プラットフォーム拡張に向けた IBM の構想、そして Java 技術の現状についての彼自身の考えを語っています。
  • Pure Danger Tech: Java 7: Alex Miller が Java 7 に提案されている機能とその情報を包括的に取り上げています。
  • IBM SDK for Java 7 オープン・ベータ版プログラム: 最新のIBM SDK for Java 7 ベータ版のアクセス権を入手できます。新しい技術と機能について学び、オープン・データ版プログラム・フォーラムにフィードバックを送ってください。
  • OpenJDK 7: Java SE ライセンスの下、Java SE プラットフォームの次回の主要なリビジョンのオープンソース実装を使用できます。
  • Apache Harmony: 同じく、Java SE ライセンスで使用できる Java SE プラットフォームの次回の主要なリビジョンのオープンソース実装です。
  • Java roundtable, Spring 2010」: Java プラットフォームが将来どのような形になるかについて、内部情報を入手してください。Java コミュニティーを代表する 9 人のリーダーが今の Java 業界が直面する大きな (場合によっては困難な) 課題について意見を述べています。
  • Java の診断を IBM スタイルで」(developerWorks、2007年 – 2009年): Java アプリケーションの問題解決を支援し、アプリケーションのパフォーマンスを改善する新たな IBM のツールについて調べてください。この連載のそれぞれの記事から、すぐに実行に移せる新しい知識を得られるはずです。
  • Technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。
  • developerWorks Java technology ゾーン: Java プログラミングのあらゆる側面を網羅した記事が豊富に用意されています。

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology
ArticleID=490589
ArticleTitle=Java 技術、IBM スタイル: Java 技術の新たな時代
publish-date=04202010