|
|
|
|
|
|
by kevingadd
1034 days ago
|
|
|
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. At any point if you make the raw bytes accessible to someone, even if it's just to copy them somewhere, it becomes possible to mutate an immutable value and users will eventually take advantage of it, if only because they came up with a really good reason why they need to (like for example, initializing readonly values in a deserialization function). I don't think .NET could have ever adopted true immutability for structs because the rules would be so easy to break. There are "readonly" fields but they're at best a railing to keep you from falling off - there are trivial ways to bypass those protections. I do think immutability can be a valuable property though so it's cool to see the Java folks doing the hard work to execute on it. |
|
|
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