Java 15の新機能は何ですか？

隠しクラス、封印されたクラス、テキストブロック、レコード、およびEdDSA：JDK15には多くの価値があります。



私の好きな表現の1つが言うように、Java15には豊富なチョコレートの良さがたくさんあります。新しいバージョン（2020年9月15日リリース）には、JDKの改善を目的とした14の重要な変更（JEP）が含まれています。この記事では、JEPに含まれる情報に基づいて、新製品の概要を簡単に説明します。



14JEPは5つのグループに分けることができます。より詳細な調査については、それぞれのドキュメントを参照してください。



息を呑むような新機能：

• JEP 339：エドワーズカーブデジタル署名アルゴリズム（EdDSA）
• JEP 371：隠されたクラス

既存のJavaSE標準機能への追加：

• JEP 378：テキストブロック
• JEP 377：ZGCガベージコレクター
• JEP 379：シェナンドア-低ポーズのガベージコレクター

従来のJavaSE機能の改善：

• JEP 373：廃止されたDatagramSocketAPIのオーバーホール

私たちは新製品を楽しみにしています：

• JEP 360：封印されたクラス（プレビュー）
• JEP 375：instanceofのパターンマッチング（2番目のプレビュー）
• JEP 384：エントリー（第2ドラフト）
• JEP 383：外部メモリアクセスAPI（2番目のインキュベーター機能）

サポートの削除と終了：

• JEP 372: Nashorn JavaScript Engine
• JEP 374:
• JEP 381: Solaris SPARC
• JEP 385: RMI

,

エドワーズカーブデジタル署名アルゴリズム（JEP 339）。私は、Edwards-Curveデジタル署名アルゴリズム（EdDSA）が私の暗号化の知識を少し超えていることを最初に認めます。さて、私はそれについて何も知りません。ただし、このJEPは、プラットフォームに依存しないEdDSAの実装として設計されており、既存のC実装であるECDSAよりもパフォーマンスが優れています。



JDKのドキュメントによると、EdDSAは、JDKの既存のスキームに比べていくつかの利点がある最新の楕円曲線署名スキームです。



実装目標：

1. このJEPの主な目的は、内標準として署名方式を実現することであるRFC 8032。ただし、新しいスキームはECDSAに置き換わるものではありません。
2. - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
3. , . .

今、あなたは私よりも多くを知っています。 EdDSAについて説明しているJavaMagazineの記事をお楽しみに。



非表示クラス（JEP 371）は、他のクラスのバイトコードから直接呼び出すことができないクラスです。これらは、実行時にクラスを動的に作成し、リフレクションメカニズムを介して間接的に使用するフレームワークで使用することを目的としています。動的に生成されたクラスは限られた時間しか必要とされない可能性があるため、静的に生成されたクラスの存続期間中それらを保持すると、メモリフットプリントが不必要に増加する可能性があります。



動的に生成されたクラスも検出できません。そのようなクラスを名前で見つけることは、静的に生成されたクラスの単なる実装の詳細であるという目的を損なうため、有害です。



非表示クラスのリリースは、開発者が非標準API sun.misc.Unsafe :: defineAnonymousClassの使用を停止するための基礎を築きます。Oracleは、将来、このクラスを削除する予定です。

既存のJavaSE標準への追加

Project Amberからのテキストブロック（ JEP 378）は、 JDK13と14の2つの暫定バージョンの後にようやくリリースされました。それらの作成の目的は、Javaで複数行の文字列リテラルを宣言して使用することの難しさを軽減したいという開発者の願望でした。



テキストブロックは、予測可能な方法で文字列を自動的にフォーマットしますが、それだけでは不十分な場合は、開発者がフォーマットを引き継ぐことができます。予備機能の2番目のバージョンでは、新しい行とスペースを処理するための2つの新しいエスケープシーケンスが導入されています。たとえば、\ <line-terminator>は、新しい行の文字の挿入を明示的に抑制します。



以前は、1行の長いテキストを印刷するには、次のように記述する必要がありました。





\を使用すると、コードが読みやすくなります。





\ sエスケープシーケンスは、末尾のスペースが削除されるのを防ぐことができます。したがって、次のテキストは3行を表しており、各行は正確に5文字で構成されています（中央の行の緑色に対応し、\ sはすでに5文字含まれているため、使用されていません）。





ZGCガベージコレクター（JEP 377）は、実験的な機能としてJDK11で導入されました。現在、正式なステータスを取得しています。 ZGCは、並列のNUMA対応のスケーラブルなガベージコレクタであり、ガベージコレクションの待ち時間が短くなります（マルチテラバイトのヒープでも10ミリ秒未満）。 Oracleによってテストされた平均休止時間は、1ミリ秒未満であり、最大は2ミリ秒未満です。図1は、Java並列ガベージコレクターG1とZGCを、ZGC一時停止時間が10倍に増加した状態で比較しています。





図1.ガベージコレクタの一時停止時間の比較



ただし、多くのワークロードでは、G1（これはまだデフォルトです）がZGCよりもわずかに速い場合があります。また、わずか数百メガバイトのような非常に小さなヒープの場合、G1も高速になる可能性があります。したがって、独自の負荷を使用して独自のテストを実行し、使用するガベージコレクターを確認することをお勧めします。



重要：ZGCは実験的ではなくなったため（OracleOpenJDKビルドおよびOracleJDKに含まれています）、-XX：+ UnlockExperimentalVMOptionsを使用してアクティブ化する必要はありません。



シェナンドア（JEP 379）一部のOpenJDKビルドで使用できるガベージコレクターの別のバリアントです。JDK 12以降、実験的です。現在、ZGCと同様に、XX：+ UnlockExperimentalVMOptionsは必要ありません。

従来のJavaSE機能の最新化

非推奨のDatagramSocketAPI（JEP 373）を作り直しました。このJEPは、java.net.DatagramSocketおよびjava.net.MulticastSocket APIの古い、保守が困難な実装を、保守とデバッグが容易な、よりシンプルで最新の実装に置き換えるため、これは基本的に一部のジュラ紀コードのリファクタリングと考えてください。 ProjectLoom仮想ストリームを操作します。



古いAPI（JDK 1.0以降）を使用するコードが多数あるため、廃止された実装は削除されません。実際、新しいJDK固有のシステムプロパティjdk.net.usePlainDatagramSocketImplは、APIリファクタリングが回帰テストで問題を引き起こす場合、または場合によっては、非推奨の実装を使用するようにJDKを構成します。

新製品を楽しみにしています

封印されたクラス（JEP 360）。 ProjectAmberで作成された最初のプレプロダクションバージョン。封印されたクラスとインターフェースは、それらの拡張または実装を他のクラスに制限します。どうしてそれが重要ですか？開発者は、特定のクラスまたはインターフェイスの実装を担当するコードを管理したい場合があります。封印されたクラスは、スーパークラスの使用を制限するためのアクセス修飾子よりも宣言的な方法を提供します。例えば：





クラスを封印する目的は、どのサブクラスが許可されているかをクライアントコードに知らせることです。結局のところ、クラス（またはインターフェイス）の元の定義が完全に網羅的であると予想され、開発者がそれを制御不能に拡張することを許可しない場合があります-明示的に指定されたクラスのみが可能です。



封印されたクラスにはいくつかの制限があります。

• 封印されたクラスとその許可されたサブクラスは、同じモジュール内にある必要があります。名前のないモジュールで宣言されている場合は、同じパッケージに配置する必要があります
• 許可されるすべてのサブクラスは、封印されたクラスを直接拡張する必要があります
• , , , — final, sealed nonsealed ( )

instanceofのパターンマッチング（JEP 375）。 2番目のプレビューは、ProjectAmberからの別の開発です。機能の最初の暫定バージョンはJava14であり、それに比べて変更はありません。



目標は、instanceof演算子のパターンマッチングを通じてJavaを改善することです。これにより、プログラム内の一般的なロジック、つまりオブジェクトからのコンポーネントの条件付き抽出をより簡潔かつ安全に表現できます。例として、MalGuptaの優れた記事「Java14でのinstanceofのパターンマッチング」を参照してみましょう。



エントリー（JEP 384）、2番目のドラフト。レコードは、不変データの透過的なキャリアとして機能するクラスです。新しいJEPには、コミュニティフィードバックに基づく説明が含まれており、ローカルクラスとインターフェイスのいくつかの新しい追加形式がサポートされています。エントリーもプロジェクトアンバーから来ています。



レコードは、値の単純な集計を表すオブジェクト指向の構成です。したがって、プログラマーが拡張可能な動作ではなく、不変のデータのモデリングに集中できるようにします。レコードは、equalsやaccessorsなどのデータ駆動型メソッドを自動的に実装します。エントリは、名目上の型指定や移行の互換性など、長年のJavaの原則も保持します。つまり、不変のデータを含むクラスのコーディングと読み取りが容易になります。



外部メモリアクセス（JEP 383）は、JavaプログラムがJavaヒープの外部の外部メモリに安全かつ効率的にアクセスできるようにするAPIの2番目のインキュベーターバージョンです。目標は、java.nio.ByteBufferとsun.misc.Unsafeの置き換えを開始することです。これは、Javaと他のAPI間の通信を改善するPanamaプロジェクトの一部です。



JEPは、このイノベーションの必要性を次のように適切に説明しています。



外部メモリへのアクセスに関して、開発者はジレンマに直面しています。ByteBufferAPIなど、安全であるが制限された（おそらく効率の低い）パスを選択する必要があるのか​​、それともセキュリティ保証を放棄し、危険でサポートされていない安全でないAPIを採用しますか？



このJEPは、外部メモリにアクセスするための安全で保守が容易で効率的なAPIを導入しています。外部メモリアクセスの問題に的を絞ったソリューションを提供することにより、開発者は既存のAPIの制限や危険から解放されます。また、新しいAPIはJITの最適化を念頭に置いてゼロから設計されているため、パフォーマンスも向上します。

削除とサポートの終了

これらの決定はどれも物議を醸すものであってはなりません。



Nashorn JavaScriptエンジンの削除（JEP 372）。このエンジン、そのAPI、およびjjsツールはJava11で非推奨になりました。さようならを言う時が来ました。予約済み



ロックの無効化と削除（JEP 374）は、HotSpot JVMで使用されていた古い最適化手法を削除して、チェックされていないロックに関連するオーバーヘッドを削減します。このロックにより、これまで従来のロック方法に比べてパフォーマンスが大幅に向上しましたが、過去に見られたパフォーマンスの向上は、今日ではそれほど明白ではありません。最新のプロセッサでアトミック命令を実行するコストは低下しました。



冗長なロックは多くの複雑なコードをもたらし、この複雑さにより、Java開発チームが同期エンジンに大幅な変更を加えることができなくなりました。ロックを無効にし、再度有効にするのはプログラマーに任せることで、Java開発チームは、将来のリリースでロックを完全に削除するのが賢明かどうかを判断したいと考えています。



SolarisおよびSPARCポートの削除（JEP 381）。この場合、SolarisオペレーティングシステムおよびSPARCアーキテクチャに固有のすべてのソースコードが削除されます。これ以上言うことはありません。



後でアンインストールするためにRMIアクティベーションを除外します（JEP 385）。 Java 8でオプションであったリモートメソッドの呼び出しの廃止された部分を削除することにより、Javaを簡素化します



。RMIアクティベーションの使用が削減されます。 Javaチームは、Javaチームを使用して新しいアプリケーションが作成されたという証拠はなく、RMIアクティベーションを使用している既存のアプリケーションはほとんどないという証拠があります。さまざまなオープンソースコードベースを検索したところ、それに関連するAPIについてはほとんど言及されていませんでした。外部で生成されたRMIアクティベーションエラーの報告は数年間ありません。



Javaプラットフォームの一部としてRMIアクティベーションをサポートするには、継続的なメンテナンスコストがかかります。これにより、RMIが複雑になります。RMIの残りの部分に影響を与えることなく、RMIのアクティブ化を削除できます。これを削除しても、Javaの開発者の価値は低下しませんが、JDKの長期的な保守コストは削減されます。

結論

Java 15は6か月のリリースサイクルを継続し、ほとんどの開発者に役立つ中規模のリリースです。