博士

やあ、ロボ子。今日はREST APIにおけるJavaのnull問題について話すのじゃ。

ロボ子

博士、よろしくお願いいたします。REST APIでnullが問題になるのは、具体的にどのような状況でしょうか？

博士

例えば、HTTPのPATCHメソッドで部分更新をする時じゃ。更新されないフィールドと、明示的にnullを設定されたフィールドを区別できないのじゃ。

ロボ子

なるほど。更新しない場合はフィールドを省略しますが、nullを設定したい場合も同じように省略してしまうと、区別がつかないということですね。

博士

そうじゃ！　それから、クエリパラメータでのフィルタリングも同様じゃ。パラメータが省略された場合と、明示的にnullに設定された場合の区別がつかないのじゃ。

ロボ子

パラメータを省略した場合と、nullを設定した場合で、サーバー側の処理が変わってくる可能性があるということですね。

博士

Javaでは、nullが「値の欠如」と「null値そのもの」の両方を表してしまうのが原因なのじゃ。PythonやJavaScriptでは、この辺りがもう少し明確になっているのじゃ。

ロボ子

PythonのNoneや、JavaScriptのundefinedとnullの違いですね。JavaのOptional型では解決できないのでしょうか？

博士

Optionalはnullを許可しないから、欠如の表現には使えないのじゃ。そこで、Omittableというモナドを導入すると、値または値の欠如を表現できるようになるのじゃ！

ロボ子

Omittableですか。それは初めて聞きました。具体的にどのように使うのでしょうか？

博士

Omittableは、nullを特別な値として扱わず、nullも通常の値として表現できるのじゃ。JSpecifyのnull許容アノテーションと組み合わせると、欠如とnull許容を明確に区別できるのじゃ！

ロボ子

なるほど。@Nullableや@NonNullといったアノテーションと併用することで、より安全なAPI設計ができるようになるということですね。

博士

そう言うことじゃ！　将来的には、Java自体がnull許容を型レベルで表現できるようになるかもしれないのじゃ。そうなれば、もっと安全になるのじゃ。

ロボ子

Javaの進化に期待ですね。ところで博士、Omittableを使うと、コードが少し複雑になりそうですが、パフォーマンスへの影響はないのでしょうか？

博士

ふむ、そこはトレードオフじゃな。安全性を取るか、パフォーマンスを取るか…　でも、ロボ子！　安全なコードはバグが少ないから、結果的に開発効率が上がって、パフォーマンスも良くなる…かもしれないのじゃ！

ロボ子

なるほど、長期的に見ればプラスになる可能性もあるということですね。勉強になりました、博士！

博士

どういたしましてじゃ！　ところでロボ子、nullPointerExceptionって、どんな時に出るか知ってるか？

ロボ子

nullPointerExceptionは、nullのオブジェクトに対してメソッドを呼び出したり、フィールドにアクセスしようとした時に発生しますね。

博士

正解！　…って、知ってるかーい！　まるで、私がnullみたいな扱いじゃないか！