> IMO it's worth keeping in mind that an "actually immutable" guarantee is pretty hard to enforce for value types without being willing to set aside performance, especially for interop.

Well, there's the issue of tearing for values beyond 64 bits, which users will need to accept to flatten those types (although it only occurs in the face of a race, i.e. a bug in the program, anyway), but Java's native interop is quite careful. As a general rule, Java code can manipulate "native" memory but doesn't hand out pointers to Java objects to native code (don't forget, we like our moving collectors).

Also, only a small minority of Java programs call native code outside of the JDK itself, and the new FFM API, which replaces JNI and is generally safer, separates safe and unsafe parts: https://openjdk.org/jeps/442. The unsafe parts require an opt in.

The goal -- which we're quickly approaching -- is that 1. no "integrity" rule will be possible to break without an explicit opt in (what we call "integrity by default"), even through native interop and 2. that only a small minority of programs (~1%) will need to opt out of integrity: https://openjdk.org/jeps/8305968