Java 9の機能

Oracle は、Java 9 の最初の拡張計画 (JEP として知られる) が 2016 年初めにリリースされることが確認されたと発表しました。

3 つの新しい API が発表されました:

Process API は、アップデート後にオペレーティング システム内の非 Java 関連プロセスと対話できるようになります。現在使用されている API には多くの制限があるため、開発者はネイティブ コードに頼ることが多くなります。この API の主なリスクは、オペレーティング システム、特に Windows の異種混合の性質です。 API の設計は、異なるオペレーティング システム上での小型デバイスの展開に適応する必要があり、複数の Java 仮想マシンが同じオペレーティング システム プロセスで実行される環境も考慮する必要があります。これらの考慮事項により、API がより抽象化され、設計の作業負荷が増加します。

新しい HTTP クライアント、HTTP/2 のサポートが導入されました。

既存の API の問題と実装:

URLConnection に基づく API は、複数のプロトコルを念頭に置いて設計されており、その多くは放棄されました (ftp、gopher など)

初期の HTTP 1.1 は抽象的すぎました

使用方法が困難 (多くの動作は文書化されていません)

ブロッキング モードでのみ動作します (リクエスト/レスポンスごとに 1 つのスレッド)

維持するのが非常に困難です

HTTPS 2.0 のサポートは TLS ALPN (Application Layer Negotiation Extension) に依存しており、現在 JDK ではサポートされていません。 HTTP 2.0 仕様自体はまだインターネット ドラフトの段階ですが、2014 年に正式なドラフトになる予定です。

新しい軽量 JSON API: JSON ドキュメントとデータ ストリームを処理および生成するための軽量 API を提供します。後者は標準化された JSON サポートに基づいており、JSR 353 の一部です。

3 つの JVM およびパフォーマンス関連の機能も発表されました:

スレッドがオブジェクトにアクセスするために競合する場合のパフォーマンスを向上させるように設計された、競合ロックの改善。コンテンション ロックの改善は、現実世界のアプリケーション、特に Volano や DaCapo などの産業用ベンチマークに対して大きな利益をもたらします。

このプロジェクトでは、競合する Java モニターに関連する次の領域でパフォーマンスの向上を検討します:

フィールドの並べ替えとキャッシュ ラインの配置

PlatformEvent::unpark() の高速化

高速 Java モニターのエントリ操作

高速 Java モニターexit 操作

高速 Java モニター Notice/notifyAll 操作

SPARC でのアダプティブ スピンの改善と SpinPause

JIT コンパイラーのコード キャッシュの分割 (大規模なアプリケーションでの JIT パフォーマンス向上のため)。コード キャッシュを独立したセグメントに分割し、それぞれに特定の形式のコンパイル済みコードが含まれるようにすることは、パフォーマンスを向上させ、将来の拡張をサポートすることを目的としています。

コンパイルされたコードの編成とメンテナンスはパフォーマンスに大きな影響を及ぼし、コードキャッシュが間違った方向に進むと、パフォーマンスが低下する例がいくつか知られています。多レベルコンパイルの導入後は、コンパイルされるコードの量が多レベルコンパイルを使用しない場合に比べて 2 ～ 4 倍に増加するため、コードキャッシュの状況が非常に重要になります。マルチレベル コンパイルでは、新しいタイプのコンパイル コード、つまりインストルメント化されたコンパイル コード (分離コード) も導入されます。エイリアン コードには、非プロファイル コードとは異なる特性があります。重要な違いの 1 つは、プロファイル コードには、常にコード キャッシュに残る非プロファイル コードとは対照的に、事前に定義された制限されたライフ サイクルがあることです。

既存のコード キャッシュは単一コード用に最適化されています。つまり、コンパイルされたコードの形式は 1 つだけです。コード キャッシュは、連続したメモリ ブロックの先頭に位置する個別のヒープ データ構造として編成されます。その結果、事前に定義された制限された有効期間を持つプロファイルされたコードがプロファイルされていないコードと混合され、コード キャッシュに永続的に残ることになり、パフォーマンスと設計にさまざまな問題が発生します。たとえば、スイーパー メソッドは、一部のエンティティが更新されない場合や、メソッド以外のコードが存在する場合でも、スキャン時にコード キャッシュ全体を強制的にスキャンするようになります。

sjavac と呼ばれる「スマート」 Java コンパイラーの綿密な開発。これは、他の機能の中でも特に、並列コンパイルと共有コンパイルをサポートします。

さまざまな安定性と移植性の問題のため、デフォルトでは sjavac は JDK ビルド スクリプトで使用されません。この JEP の最初の目標は、これらの問題を解決することであり、これには、ツールがすべてのハードウェアおよびソフトウェア構成で常に信頼できる結果を生成できるようにすることが含まれます。 。

全体的な目標は、sjavac の品質を向上させ、さまざまな大規模な Java プロジェクトをコンパイルできるユニバーサル javac パッケージにすることです。

フォローアップ プロジェクトでは、可能であれば JDK ツール チェーン内で sjavac を分離する方法を引き続き検討します。 sjavac は、スタンドアロンでサポートされるツール、javac と統合された非スタンドアロン ツール、またはその他のものになる可能性があります。

最後に、JEP 201 には魅力的な機能、つまりモジュール型ソース コードが約束されています。これは実際、かつてモジュール型ソリューション「Project Jigsaw」として知られていたものです (当初は Java 8 の一部としてターゲットにされていました)。

Jigsaw プロジェクトは、Java SE プラットフォーム用に標準化されたモジュール システムを設計および実装し、それを独自のプラットフォームに適用して、JDK に投資することを目的としています。その初期の目標は、プラットフォームの実装を小型デバイスに簡単に拡張できるようにし、セキュリティと保守性を向上させ、アプリケーションのパフォーマンスを向上させ、大規模なアプリケーションに直面した場合に開発者に優れたツールを提供することです。

この JEP は Jigsaw プロジェクトの第 1 フェーズの一部です。次に、JEP は JRE と JDK イメージをモジュール化し、モジュール システムを導入します。

初期段階でソースコードを再編成する動機は次のとおりです:

JDK 開発者にシステムのモジュール構造に慣れる機会を与えるため。

モジュール システムが導入される前であっても、ビルドでモジュール境界を強制することで構造を進化させ続けます。

既存の非モジュラーコードを常に「ゆっくり」とモジュラーコードに変換するのではなく、ジグソープロジェクトを徹底的に開発します。