2024/12/12

Null-Restricted Typeとオブジェクト初期化の変更
 で、ValhallaのValue Classってどうなったの？ その3

このエントリーをはてなブックマークに追加

本エントリーはJava Advent Calendarの12日目です。昨日はmackey0225さんのイレイジャってなんじゃ？でした。

 

Project Valhallaを紹介するエントリーも3回目になりました。

本エントリーではNull-Restricted Type(Null非許容型)について紹介していきます。いわゆるNon-Nullです。

Null-Restricted Typeに関するJEPは2つありますが、現状はドラフトなので番号がついていません。

 

Null非許容型にまつわる小史

Javaの開発者であれば誰もが1度は遭遇したことがあるNull Pointer Exception例外ですが、これを防ぐための取り組みが行われてきました。

ここではOpenJDKおよびJCPによる標準APIでの取り組みについて簡単に紹介します。

 

型アノテーションを使ったDefect Detection

変数にNullを許容するかしないかをアノテーションで修飾する取り組みは、多くライブラリやフレームワークでも導入されてきました。

たとえば、IntelliJ IDEAの設定で[Compiler]の項の1つに[Add runtime assertions for notnull-annotatedmethods and parameters]があり、その[Configure annotations...]をクリックすると、どのライブラリ/フレームワークのアノテーションを使用するか選択できます(下図参照)。

 

この設定ダイアログを見ると、AndroidやJakarta EEなどが@NonNullアノテーションもしくは@NotNullアノテーションを導入していることが分かります。

たとえば、メソッド引数にnullを禁止したいのであれば、次のように書けます。

    String readContext(@NonNull String filename) throws IOException {
        ...
    }

 

ところが、このアノテーションだと書けないことがあります。たとえば、リストの要素にnullを許さない場合はどうでしょう。これを解決するためにJava 8で導入されたのが、型アノテーション(JSR 308 Annottations on Java Type)です。

型アノテーションは型に対してアノテーションで修飾します。たとえば、リストの要素にnullを許さないという場合は次のように記述できます。

    List<@NonNull String> texts = ...;

 

そして、この型アノテーションを使用してNull非許容性を表そうとしたのが、JSR 305 Annotations for Software Defect Detecctionです。

このJSRのスペックリードはFindBugsの作者のBill Pughだったのですが、Bill Pughに連絡がとれなくなり、JSRも中断してしまいました。ご存じの方もいらっしゃると思いますが、FindBugsの開発が停滞してしまったのもこの頃です。

同様にJSR 308の型アノテーションを使って@NonNullを表そうとしたのが静的解析ツールのChecker Frameworkなのですが、こちらもそこまで流行らず...

うまく活用すればよかったのですが、標準にならなかったのが痛かったのが型アノテーションを使ったNull非許容性でした。

 

Optional

OptionalもJava 8で導入されました。

Optional自体はNull許容性を表すというよりは、値の有無を扱うために使われるクラスです。

しかし、値がないことをnullで表す場合が多かったため、Optionalを使うことでnullの使用を避けることができました。

ところが、Optional型を使ったとしても次のように書けてしまうのが...

    Optional<String> option = null;

 

つまり、値の有無を扱うことはできても、自分自身のNull非許容性は表せないのです。

 

ということで、Null非許容性を表すための取り組みはあったものの、成功したとはいえないのがJavaの現状でした。

 

Null-Restricted Type/Nullable Type

さて、Project ValhallaのNull-Restricted Typeです。

今までのNullに対する取り組みは、ソフトウェアの堅牢性を高めるためのものでした。これに対しValhallaのNull-Restricted Typeはパフォーマンス向上のためという大きな違いがあります。

前回、説明したValueクラスの平坦化やスカラー化は、行われるためのいくつかの条件があります。そのうちの1つが、値にnullが入らないことです。

Valueオブジェクトはプリミティブ型のようにふるまいますが、プリミティブ型の変数にはnullが値として入ることがありません。もし、平坦化やスカラー化で値を埋め込む時にnullが入るかもしれないのであれば、それを示すためのフラグなどが必要になります。しかし、それではせっかくの最適化の効果が低くなってしまいます。

なので、nullを許さないというのが最適化の条件になっているわけです。

 

ただし、Null非許容性はValueクラスでなくても有用です。そこで、Value Classとは独立して仕様を策定しようというのがJEPのNull-Restricted and Nullable Typesです。

そして、ValueクラスのNull非許容性はNull-Restricted Value Class Typesで仕様策定されます。

 

Null-Restricted Type/Nullable Typeの書き方

Null非許容/Null許容型の変数は次のように記述します。

    // null非許容
    String! nonnullText = "...";

    // null許容
    String? nullableText = "...";

 

他の言語でもNon-NullとNullableに!と?を使うことが多いので、理解しやすいですね。!と?はnullnessマーカーと呼ばれます。

nullnessマーカーはジェネリクスの型パラメータでも使用することができます。

    // null非許容
    class Foo<T!> { ... }

    // null許容
    class Bar<T?> { ... }

    // null非許容
    Foo<String!> foo = ...;

    // null許容
    Bar<String?> bar = ...;

 

!や?を指定していない型は未指定(Unspecified)です。未指定、つまり従来の型については仕様を変更していないので、nullが入ることもあります。実質的には?と未指定は同じような動作になりますが、型としては異なります。

また、nullnessの型を変換することもできます。Foo!をFoo?に代入するようなwide変換はOKです。しかし、Foo?をFoo!に代入するようなnarrow変換の場合、コンパイル時に警告が出るようです。

ただし、このJEPに対応するEalry Accessがないので、実際にどのような警告が出るのか、実行させるとどうなるのかなどは、よく分かりません。キャストすればいいのか、nullチェックをした後でないと代入できないのかなどは、Early Accessが出たら確かめてみたいと思います。

 

配列の初期化

Null-Restrictedな変数は、変数の宣言時に初期化を行う必要があります。ただし、クラスのフィールドであれば、コンストラクターやイニシャライザーでも初期化できます。

ここで困るのが配列です。要素も含めて初期化する必要があるからです。

たとえば、"a", "b", "c"を要素に持つString!の配列であれば、次のように書けます。

    String![] texts = new String![] { "a", "b", "c" };

では、初期値として""で埋めた、長さ10の配列はどうでしょう。また、配列のインデックスを使った初期化はどうでしょう? もちろん、Stream APIを使えば書けますが、それではちょっとおおげさですね。

現状のJEPのドラフトでは以下の書き方が提案されていますが、あくまでも現状であり、文法については変わる可能性も高いのですが、とりあえずこういうことが書けるようなことが考えられています。

    String![] texts1 = new String![10] { "" };
    String![] texts2 = new String![10] { i -> "s" + i };

 

この他にもメソッドをオーバーロードする場合、nullnessの違いだけではオーバーロードできないなど、いろいろとルールがありますが、実際にやってみないと具体的にどのようになるのかがJEPだけではよく分からないことが多々あります。

Early Accessが出て、JEPもドラフトではなく正式なものになったら、再度取り上げてみたいと思います。

 

オブジェクト初期化の変更

クラスのフィールドがNull-Restrictedな型の場合、宣言時に初期化するか、コンストラクターもしくはイニシャライザーで初期化する必要があります。

では、次に示すコードは実行したらどのようにふるまうでしょう。

フィールドの初期化ははまりどころが多いので、よくクイズになるところですね。Javaのクイズといえば、JavaOneの名物セッションだったJoshua BlochとNeal GafterによるJava Puzzlersです。

短いコードを提示して実行したらどうなるかを4択で選ぶというセッションなのですが、彼らのウィットに富んだセッションはさくらばもとても影響を受けています。

ということで、ここでもJava Puzzlersをまねて、実行したらどうなるかを4択で選んでみてください。

class Cat {
    String meow = "Meow";

    Cat() {
        meow = ((Lion)this).roar;
    }
}

class Lion extends Cat {
    final String roar;

    Lion() {
        roar = "Roar";
    }
}

public class DoLionMeow {
    public static void main(String... args) {
        System.out.println(new Lion().meow);
    }
}

選択肢は以下の4つ

  1. Meow
  2. Roar
  3. null
  4. 例外発生

 

ちなみに、Meowはネコの鳴き声(ニャーオ)で、Roarはライオンの鳴き声(ガオー)です。

このDoLionMeowクラスでは、Lionオブジェクトを生成して、そのスーパークラスであるCatクラスのフィールドのmeowを表示させています。

Catクラスのコンストラクターでは、サブクラスのLionのroarをmeowに代入しています。roarはLionのコンストラクターで"Roar"を代入しています。

 

さて、どうでしょう。

答えは 3. の null です。

 

それほど難しくはないですよね。

roar変数はfinalなので一度しか初期化できません。しかし、実際には初期化する前の状態があり、その時の値はnullになります。

そして、Lionクラスのコンストラクターでは省略されていますが、super()をコールしているということです。つまり、Lionクラスのコンストラクターは省略しないで記述すると、次のようになります。

    Lion() {
        super();
        roar = "Roar";
    }

 

このため、roarを初期化する前にCatクラスのコンストラクターがコールされてしまい、初期化されていないroarにアクセスしてしまっているということです。

初期化していないのでroarの値はnullになり、meowに代入するので、結果的にnullが表示されてしまいます。

 

ここで重要なのはfinal変数でも、初期化前の状態にアクセスできてしまうということです。もし、meowの型がString!だったらどうでしょう。nullはとらないはずなのに、実際はnullになってしまうのは問題です。

これを解決するために、オブジェクトの初期化を変更するというのがJEP 492: Flexible Constructor Bodiesです。

JEP 492はProject Valhallaではなく、Javaの言語仕様をアップデートするProject Amberで策定されています。Value ClassやNull-Restricted Typeとは独立に仕様策定できるので、Value Classにさきがけてアップデートしてしまおうということなのかもしれません。

JEP 492はJava 24で3rd Previewになっているので、次のLTSのJava 25に標準で取り込まれる可能性が高いです。

 

Lionクラスのように今までのコンストラクターは、必ず先頭でスーパークラスのコンストラクターを呼び出していました。デフォルトコンストラクター以外のコンストラクターをコールするのであれば、明示的にsuper(...)をコールする必要がありますが、デフォルトコンストラクターであれば記述を省略できます。

このため、スーパークラスからはサブクラスの初期化していないフィールドにアクセスできてしまいます。

そこで、JEP 492ではsuper(...)をコールする前にフィールドの初期化を行えるように言語仕様を変更しています。

 

とはいえ、super(...)をコールする前にどういう処理でもできるわけではありません。たとえば、thisは使うことはできません。他にもルールはありますが、要するにフィールドの初期化以外の処理をsuper(...)の前に記述しないということが重要です。

また、デフォルトコンストラクターのsuper()を省略した場合は、現在の使用と同じくコンストラクターの先頭でコールされます。

 

さて、DoLionMeowクラスで"Roar"を出力させるためには、Lionクラスのコンストラクターを次のように記述すればよいことが分かります。

    Lion() {
        roar = "Roar";
        super();
    }

 

ただし、JEP 492はPreview JEPなので、コンパイルや実行する時にはオプションの--enable-previewが必要です。

 

ところで、前述したJava Puzzlersのセッションではフィールドの初期化に関するパズルは必ず1問は出題される頻出分野だったのですが、JEP 492が導入されるとそれらのパズルは通用しなくなってしまいますね。まぁ、どちらにしろずっと昔の話なので、どうでもいいといえばどうでもいいのですけど。

 

最後に

3回に渡ってValue Classに関連したトピックを紹介してきました。

Value Classを作成するのは簡単ですが、最適化されることを考慮して使う必要があります。

サイズが小さいことと、フィールドがNull-Restrictedであることが最適化の条件です。このように考えると、Recordクラスで記述していたデータで、サイズが小さければValue Classにするというのがいいと思います。

とはいうものの、いつからValue Classが使えるようになるのかはまだまだ分かりません。Project Valhallaが発足して10年。ここまで待ったのですから、もうちょっとだとは思いますが気長に待ちましょう！

投稿者 Yuichi Sakuraba 時刻: 0:07
ラベル: ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)