saying that java interop doesn’t matter much feels weird to me as the whole scala ecosystem is tremendously dependent on java standard library, either in original or reimplemented (api-compatible) form.
initial java value types pull request is being reviewed https://github.com/openjdk/jdk/pull/31120 and the nullness markers JEP draft: Null-Restricted Value Class Types (Preview) JEP draft: Null-Restricted and Nullable Types (Preview) will be follow-ups sometime in the future. even though it says It is not a goal (at this time) to apply the language enhancements to the standard libraries, it can be assumed that in the future java standard library will get sprinkled with nullness markers, as they are designed to be backwards compatible like java generics.
additionally, JSpecify nullness design FAQ | JSpecify says:
OpenJDK has been participating in JSpecify, and we are in regular communication about the prospects for a longer-term language feature.
so we can probably expect similar challenges in interop with either jspecify or with future java nullness markers.
one thing that would be silly if nullness markers are poorly approximated is losing jvm optimizations. since there are no official nullness-marker based optimizations yet to test, it’s hard to come up with examples and benchmarks, but java in recent years gained some high performance stuff that can depend on small details (like whether a var handle is strictly static and immutable, etc). such high performance stuff is obviously under project valhalla, but also project panama (foreign memory, ffi, vector api that implemented portable simd implementation for huge speedups in certain scenarios).