JDK 15:Java15の新機能

OracleのJavaSE(Standard Edition)の次のバージョンの実装であるJava Development Kit 15は、本日2020年9月15日に製品リリースとして利用可能になります。JDK15のハイライトには、テキストブロック、非表示クラス、外部メモリアクセスAPI、 Z Garbage Collector、および封印されたクラス、パターンマッチング、およびレコードのプレビュー。

JDK 15は短期リリースであり、JDK16が来年3月に到着するまでの6か月間だけOraclePremierSupportでサポートされます。オラクルが8年間サポートする次の長期サポートリリースであるJDK17は、Java SEバージョンに対するオラクルの6か月のリリースリズムに従って、今から1年後に到着する予定です。

OracleのJavaPlatformGroupの社長であるGeorgesSaab氏は、開発者はJDK15を今すぐ見てJDK17に何が含まれるかを知ることができます。現在のLTSリリースは2018年9月に到着したJDK11です。LTSリリースは3年ごとに到着します。JDK 15は、2020年3月17日にリリースされたJDK14に続くものです。 

OpenJDK15の新機能と変更点:

  • 外部メモリアクセスAPIの2番目のインキュベーター。これにより、JavaプログラムはJavaヒープの外部の外部メモリに安全かつ効率的にアクセスできます。 APIは、ネイティブヒープ、永続ヒープ、マネージヒープなど、さまざまな種類の外部メモリで動作できる必要があります。多くのJavaプログラムは、IgniteやMapDBなどの外部メモリにアクセスします。 APIは、ガベージコレクションに関連するコストと予測不可能性を回避し、プロセス間でメモリを共有し、ファイルをメモリにマッピングすることでメモリコンテンツをシリアル化および逆シリアル化するのに役立ちます。 Java APIは現在、外部メモリにアクセスするための十分なソリューションを提供していません。しかし、新しい提案では、APIがJVMの安全性を損なう可能性はありません。この機能は、JDK 14の初期のインキュベーター段階を経ており、JDK15で改良が加えられています。 
  • 封印されたクラスのプレビュー。シールされたクラスは、インターフェイスとともに、他のどのクラスまたはインターフェイスがそれらを拡張または実装できるかを制限します。この機能の目標には、クラスまたはインターフェイスの作成者がそれを実装するコードを制御できるようにすること、アクセス修飾子よりも宣言的な方法を提供してスーパークラスの使用を制限すること、徹底的なサポートによってパターンマッチングの将来の方向性をサポートすることが含まれます。パターンの分析。
  • ソースコードの削除とSolaris / SPARC、Solaris / x64、およびLinux / SPARCポートのビルドサポート。これらは、将来のリリースで削除することを目的として、JDK14での削除が非推奨になりました。 Valhalla、Loom、Panamaなどの開発中の多くのプロジェクトや機能では、CPUアーキテクチャとオペレーティングシステム固有のコードに大幅な変更を加える必要があります。 SolarisおよびSPARCポートのサポートを終了すると、OpenJDKコミュニティへの貢献者は、プラットフォームを前進させる新機能の開発を加速できます。 SolarisとSPARCはどちらも、近年LinuxOSとIntelプロセッサに取って代わられています。
  • 不変データの透過的なキャリアとして機能するクラスであるレコードは、JDK 14で初期プレビューとしてデビューした後、JDK15の2番目のプレビューバージョンに含まれます。計画の目標には、値の単純な集計。プログラマーが拡張可能な動作ではなく不変データのモデリングに集中できるようにし、equalsやassessersなどのデータ駆動型メソッドを自動的に実装し、名目上の型指定や移行の互換性などの長年のJava原則を維持します。レコードは、名目上のタプルと考えることができます。 
  • エドワーズ曲線デジタル署名アルゴリズム(EdDSA)に基づく暗号署名。 EdDSAは、JDKの既存の署名スキームよりも優れた最新の楕円曲線スキームです。 EdDSAはSunECプロバイダーでのみ実装されます。 EdDSAは、他の署名スキームと比較してセキュリティとパフォーマンスが向上しているため、需要があります。 OpenSSLやBoringSSLなどの暗号ライブラリですでにサポートされています。
  • java.net.datagram.Socketおよびjava.net.MulticastSocketAPIの基盤となる実装を、1。デバッグと保守が容易で、2。ProjectLoomで現在調査されている仮想スレッドで動作する、よりシンプルで最新の実装に置き換えることにより、レガシーDatagramSocketAPIを再 実装します。新しい計画は、従来のSocketAPIを再実装したJDKEnhancement Proposal353のフォローアップです。現在の実装java.net.datagram.Socketおよびjava.net.MulticastSocketJDK 1.0に遡るとIPv6はまだ開発中だった時間。したがって、現在の実装で MulticastSocket は、維持が困難な方法でIPv4とIPv6を調整しようとしています。
  • デフォルトでバイアスロックを無効にし、関連するすべてのコマンドラインオプションを非推奨にします。目標は、競合しないロックのオーバーヘッドを削減するためにHotSpot仮想マシンで使用されるバイアスロックの維持にコストのかかるレガシー同期最適化の継続的なサポートの必要性を判断することです。一部のJavaアプリケーションでは、バイアスロックを無効にするとパフォーマンスが低下する場合がありますが、バイアスロックによるパフォーマンスの向上は、通常、以前ほど明確ではありません。
  • instanceofJDK 14での以前のプレビューに続く、のパターンマッチングの2番目のプレビュー。パターンマッチングにより、プログラム内の共通ロジック、主にオブジェクトからのコンポーネントの条件付き抽出を、より簡単かつ簡潔に表現できます。HaskellやC#などの言語は、その簡潔さと安全性のためにパターンマッチングを採用しています。
  • 非表示のクラス、つまり他のクラスのバイトコードで直接使用できないクラスは、実行時にクラスを生成し、リフレクションを通じて間接的に使用するフレームワークで使用することを目的としています。非表示のクラスは、アクセス制御ネストのメンバーとして定義でき、他のクラスとは独立してアンロードできます。この提案は、標準APIが検出できず、ライフサイクルが制限されている非表示クラスを定義できるようにすることで、JVM上のすべての言語の効率を向上させます。 JDKの内外のフレームワークは、代わりに非表示のクラスを定義できるクラスを動的に生成できます。 JVM上に構築された多くの言語は、柔軟性と効率性のために動的クラス生成に依存しています。この提案の目標は次のとおりです。フレームワークがクラ​​スをフレームワークの検出不可能な実装の詳細として定義できるようにする、したがって、他のクラスによってリンクされたり、リフレクションによって発見されたりすることはできません。検出不可能なクラスでアクセス制御ネストを拡張するためのサポート。検出不可能なクラスの積極的なアンロードをサポートするため、フレームワークには必要な数を定義する柔軟性があります。もう1つの目標は、非標準のAPIを廃止することです。 misc.Unsafe::defineAnonymousClass、将来のリリースでの削除を非推奨にすることを目的としています。また、この提案の結果としてJava言語が変更されることはありません。
  • Zガベージコレクター(ZGC)は、実験的な機能からこの提案に基づく製品に移行します。 2018年9月にリリースされたJDK11に統合されたZGCは、スケーラブルで低レイテンシのガベージコレクタです。 ZGCは実験的な機能として導入されました。これは、Javaの開発者が、このサイズと複雑さの機能を慎重かつ段階的に導入する必要があると判断したためです。それ以来、クラスの同時アンロード、未使用メモリのコミット解除、クラスデータ共有のサポートから、NUMA認識の向上、マルチスレッドヒープの事前タッチまで、多くの改善が追加されました。また、最大ヒープサイズが4テラバイトから16テラバイトに増加しました。 ZGCは、機械学習など、大量のデータを含むアプリケーションのパフォーマンスの問題に対処します。ガベージコレクションが原因でデータの処理が予測不能になったり、長い一時停止が発生したりしないようにする必要がある場合。サポートされているプラ​​ットフォームには、Linux、Windows、MacOSが含まれます。
  • JDK14とJDK13の両方でプレビューされるテキストブロックは、一般的なケースでエスケープシーケンスを回避しながら、ソースコードの数行にまたがる文字列を簡単に表現できるようにすることで、Javaプログラムの作成タスクを簡素化することを目的としています。テキストブロックは、ほとんどのエスケープシーケンスの必要性を回避し、予測可能な方法で文字列を自動的にフォーマットし、必要に応じて開発者がフォーマットを制御できるようにする複数行の文字列リテラルです。テキストブロック提案の目標は、Java以外の言語で記述されたコードを示すJavaプログラムの文字列の可読性を高めることです。もう1つの目標は、新しい構造が文字列リテラルと同じ文字列セットを表現し、同じエスケープシーケンスを解釈し、文字列リテラルと同じ方法で操作できることを規定することにより、文字列リテラルからの移行をサポートすることです。OpenJDKの開発者は、エスケープシーケンスを追加して、明示的な空白と改行の制御を管理したいと考えています。
  • シェナンドアの低休止時間のガベージコレクターは、生産機能になり、実験段階から抜け出します。1年前にJDK12に統合されていました。
  • 2014年3月にJDK8でデビューしたが、その後GraalVMなどのテクノロジーによって廃止されたNashornの削除。OpenJDK 15の提案では、NashornAPIとNashornの呼び出しに使用されるjjsコマンドラインツールを削除する必要があります。
  • 将来の削除のためのRMIアクティベーションメカニズムの非推奨。RMIアクティベーションメカニズムは、Java 8以降オプションとなっているRMIの廃止された部分です。RMIアクティベーションは、継続的なメンテナンスの負担を課します。RMIの他の部分は非推奨になりません。