Javaに欠けている機能：5年後

原文(投稿日：2020/04/03)へのリンク

約5年前、私は他の言語の機能のアイデアの概要をまとめた記事を書いたが、その中でJavaに役立つと感じたものがあった。それ以来、多くのことが起こった - 当時、Java 8は新たに作られたばかりのリリースだったが、最新のバージョンはJava 14になった。

それぞれの機能を順番に見ていき、それがJavaに追加されたのか、現在進行中なのか、それとも現在予定されていないのか現在の状態を見ていこう。

Reified generics

私の元々の予測では、Reified genericsは除外されていた。私は、Project ValhallaがJVMを一から作り直すという野心を持っているとは予知できなかった。

Project Valhallaの主な目標は

• JVMのメモリレイアウトの振る舞いを最新のハードウェアのコストモデルに合わせる。
• ジェネリクスを拡張して、プリミティブ、値、さらには voidを含むすべての型の抽象化を可能にする。
• 既存のライブラリ、特に JDK は互換性を持って進化させ、これらの機能を十分に活用できるようにする。

この記述の中に潜んでいるのは、「値」という隠された意味のある言葉であり、これが今日のインラインクラスとして知られる機能へと発展した。

このようにして、Reified genericsとプリミティブの特殊化は、Javaの書き方と実行の方法を根本的に変えることを約束する、はるかに大きなプロジェクトに組み込まれた。

深い低レベルの変更が行われているにもかかわらず、プロジェクトチームの目標は、既存のJavaアプリケーションへの混乱を最小限に抑え、独自のコードでValhallaの機能を使用する開発者に簡単な明確な意思表示のあるアプローチを提供することにある。

Valhallaは未完成であり、いつ実現されるかについての公式ロードマップはまだないことに注意が必要だ。

評決：進行中（Project Valhallaの一環として）

符号なし算術

この機能をサポートする可能性については、Javaの歴史の中で何度も議論されてきた。しかし、導入には多くの複雑なことがある。

例えば、Javaの型システムの中で符号の属性をどのように表現すべきか、JVMのバイトコードレベルで可視化すべきかどうかという問題がある。

これらの問題は満足のいく同意に達していない。そのため、Javaはいまだに符号なし算術を含んでいない。そして、Project Valhallaの注目すべき点の一つは、符号なし算術のサポートを含んでいないことだ。

評決：考慮されていない

配列のための長い索引

Javaの配列は、その設計上の単純な事実によってサイズが制限されている。それは索引としてはintしか受け付けない。これは、配列が2の31乗の要素に制限されていることを意味する（intは符号付きであることを覚えておいてください）。これはおおよそ20億の要素だ。

当初想定されていたように、int の代わりに long を使うことで、開発者はより大きな配列を作成したり操作したりできるようになる。しかし、元の「Missing Features」の記事以来、この分野におけるコミュニティの焦点は、オフヒープに保存された大規模な配列への容易なアクセスを提供する方向にシフトしている。

これにはいくつかの理由があるが、Java以外のライブラリ（機械学習やその他の数値の重いアプリケーションを含む）との相互運用が容易であることも重要な理由の一つだ。しかし、大規模なオンヒープ配列がどれほど有用なのかという疑問もある。巨大な数GBの配列は、Javaヒープに出入りする際に多大なコピーコストがかかり、JVMのガベージコレクタに深刻な頭痛の種となる可能性がある。

これらの理由から、大規模配列は主にオフヒープでのサポートの文脈で考えられており、そのコンセプトはProject Panamaの中で開発中の機能に組み込まれた。

評決：進行中（Project Panamaの一環として）

より表現力豊かなimport構文

import構文の範囲を拡大したり、型の別名を導入したりすることは、たとえローカル（またはファイルスコープされた）レベルであっても、深刻な試みは行われていない。

評決：考慮されていない

コレクション定数

Java 9ではインタフェース上の静的メソッドが追加され、コレクションにファクトリメソッドが含まれるように更新された。これらはJavaではコレクション定数の役割を果たしている。

var ls = List.of(1,2,3);

ファクトリが定数の役割を果たしているので、この変更ではコレクションインタフェースの新しい実装も導入された。これらの実装は不変なコレクションだ。なぜならば、既存の可変なコレクション（ArrayListなど）を再利用することは、これらの値が定数であるかのように振る舞うべきだというプログラマの期待に反していたからだ。

言語構文に新しい定数を直接導入するなど、より押しつけがましい解決策は追求されなかった。

評決：実現済

代数データ型

Javaの代数データ型は実現中だ。この機能は、型システムへの2つの主要な追加機能で構成されている：RecordsとSealed型、およびパターンマッチングと同様に実質的に新しい構文だ。

Java 14は、これらの2つの側面をプレビュー版として提供している。具体的に言うと、Javaでの中でtuplesと本質的に名付けられたRecordsと、パターン・マッチングの初期コンポーネントだ。

パターンマッチングの入門編を構成する新機能は、Javaのパターンの最初の方式であるinstanceofパターンと、スイッチ式の標準化版だ。

これらのうちの2つ目は、Scalaプログラマがよく知っているmatch式と同様の方法で、最終的に一般的なパターンマッチングを導入できるようにするための足場となる。

この機能が完全に提供されるまでには、まだ多くのステップがある - Recordsとパターンはまだプレビューのみだ。Recordsの分解を可能にするためにinstanceofパターンを拡張したJEP 375を含む更なるJEPは、パターンマッチングを全体として肉付けするために必要とされる。

Java 14の到着時点では、JEP 375とSealed 型を導入したJEP 360の両方を含む主要なJEPは、特定のJavaバージョンを対象としていない。

具体的なロードマップがないにもかかわらず、代数的データ型とパターンマッチングメカニズムの全体が、次のLTSリリースである2021年9月のJava 17に間に合うように標準化された形で提供される可能性が高い。

評決：進行中（Project Amberの一環として）

構造的な型付け

Javaの型システムはJava 8から多少進化したが、実際には一般的な構造型付けへの大きな動きはなかった。例えば、Recordsを設計する際には、構造的な型付けは明示的に拒否され、Recordsを公称型にすることが好まれた。

これは、型に与える名前には力と重要性があり、Java Recordsはそのコンポーネントの数や型だけではなく、それ以上のものによって定義されるという考えを強めている。

構造的な型付けに似たものがJavaで漠然と見え続けているマイナーな場所の一つは、JavaのNon Denotable型だ。これらは本当に元々2015年の一部で議論されていた実例の延長線上にある。

その例では、構造型(Object + <いくつかのメソッド>)のように見えるものを構築している。しかし、値を代入する変数の型として使用できるNon Denotable型なので、単一の式の中でしか使用できない。

Java 10 以降、この言語には、代入の一般的な表現を減らすために varを使用する型推論の拡張形式がある。この能力を使用して、この方法で型に定義された追加のメソッドを呼び出すスコープを拡張できる。ただし、型推論が行われるメソッドに制限される。var が推測する特殊な型は、Non Denotable なため、メソッドの境界を越えて正確に伝搬できない。

実際には、これらの特殊なケースは真の構造型付けではないし、導入する意図もない。名前や公称型へのJavaのデザインの魅力があまりにも強すぎる。

評決：検討されたが却下された

Dynamic call sites

過去5年間でinvokedynamicの使用が大幅に拡大したが、それはJDKの中と少数の技術的に洗練された外部ライブラリの中に限られている。

元記事で述べられているように、「Java言語には汎用的なinvokedynamic call sitesを作成するためのキーワードなどの構築物がない」ことに変わりはない。

Dynalink ライブラリを拡張してこの役割を担うことができるという提案は、決して実現しなかった。実際、Dynalinkを生成したNashorn Javascriptの実装自体が現在では非推奨とみなされ、Java 15からは省略される可能性がある(Dynalink 自体は残るが)。

MethodHandles APIを介してDynamic call sitesを利用するライブラリは、2020年には少し使いやすくなっているものの、ほとんどのJavaプログラマの手の届くことはない。

ランタイムの問題をあまり起こさない柔軟な動的呼び出しと、説得力のある言語レベルの使用法のバランスを見つけることの難しさは、少なくとも当分の間は、あまりにも大きすぎることだと証明されている。

評決：考慮されていない

何を見逃した？

また、ここ5年は、元記事では予想もしていなかったプロジェクトやトレンドがいくつも出てきている。この中で一番大きいのは、おそらく

• Project Valhallaの範囲と広がり
• Project Amber
• Javaの新しいリリースモデル
• GraalとGraalVM
• Kotlinの台頭

いくつかの例をピックアップすると

Project Valhallaは2014年に開始されたが、その間に勢いを増し、何年もの間でかなり大きく拡大してきた。それは、Javaがこれまで見てきた中で最も野心的で最大の変化となった。ValhallaはJavaプラットフォームのあらゆる面を修正することを約束する。それは、メモリと値がVM内で表現される方法から、型システムとジェネリクスを経て、ライブラリレベルと言語構文に至るまでだ。

このプロジェクトは、Javaを現在および将来のハードウェアの状態に合わせ、パフォーマンスや一筋縄ではいかないその他の改善を提供することを目的としている。代わりに、Valhallaは、Javaプラットフォームの状態を、現在の位置（局所的な最大値と考えることができる）から、今後数十年のプラットフォームの基礎となるのに適した場所に移動させることを目指している。

独自の研究は常に予測するのは難しいので、それはおそらく驚くべきことではないが、Graalの台頭はまた私を驚かせた。基本的な考え方は、他の多くの説得力のある概念と同様に、一度把握してしまえば非常にシンプルだ。

Javaの通常のJITコンパイラはC++コードで書かれており、JVM内の特別な専用スレッドで実行される。Graalはシンプルなアイデアから始まる。代わりに、JITコンパイラがJavaで書かれていて、そのコンパイラのスレッドが実際にJavaインタプリタの2番目のコピーを実行しているとしたらどうだろうか？

インタプリタモードのJITコンパイラは、現在のJITと同じくらいの能力を持っていて、どんなクラスファイルでもマシンコードにコンパイルできる。既存のC++コンパイラよりも遅いと予想すべきだが、挙動に違いはなく、性能だけに違いがあるだろう。

この考えを論理的な結論に持っていくと、これはインタプリタモードのJITがJIT自身を構成するクラスファイルをコンパイルできることを意味する。一度温まってしまえば、それは自分自身を置き換えられ、ネイティブJITと同じ性能で実行できた。

この興味をそそるアイデアは、新技術の主要なクラスの出発点となることが判明した。その中には、Javaのネイティブコンパイル(AOT)や、多くの異なる言語を実行できる新しい多言語仮想マシン(GraalVM)が含まれている。

結論

Javaプラットフォームは、この5年間で洗練され、多くの新しい言語やVM機能が提供されたり、開発中であったりして成長してきた。現在の傾向が続くと仮定すると、コミュニティは、Java 17（2021年9月の予定）で利用可能になる標準化された機能のセットに最も関心を持っている可能性が高い。

これは2014年に独自の観測を行った際に存在したJavaとは大きく異なるものになるだろう。そして、いくつかの機能が提供されるが、それは明らかに、他のいくつかの他の人が到着する可能性は低いと思われ、他の人は非常に異なる形で実現されているように見える。私たちは次の5年がJava言語とプラットフォームに何をもたらすのか、特に今すぐには予測できない部分を楽しみにしている。

著者について

Ben Evans氏は、JVMパフォーマンスの最適化を行うjClarity社の共同創業者だ。LJC (ロンドンJUG) の主催者であり、JCP 実行委員会のメンバーでもあり、Java エコシステムの標準化を支援している。 Ben氏はJavaチャンピオンだ。また3度のJavaOneロックスター・スピーカーに選ばれている。「The Well-Grounded Java Developer」、新版の「Java in a Nutshell」、「Optimizing Java」の著者だ。彼はJavaプラットフォーム、パフォーマンス、アーキテクチャ、同時実行性、起動など関連トピックについての定期的な講演を行っている。Ben氏は、講演、教育、執筆、コンサルタントとしての仕事をすることもある。詳細はお問い合わせください。