3 ms·
Thus bringing us back to the same unsafety with extra steps and glue required; what did we gain from this? Edit: Unless you FFI to Rust / Ada / formally verifi
by yjftsjthsd-h 3y ago
Thus bringing us back to the same unsafety with extra steps and glue required; what did we gain from this?
Edit: Unless you FFI to Rust / Ada / formally verified C, in which case perhaps we can claw back the performance and safety at the cost of a lot more dev work.
- eptcyka 3y agoFFI boundaries are inherently unsafe regardless of language.
- kaba0 3y agoBut more “distance” between the two might be better, like, copying some value-like objects and doing the operation on that and copying back the result is much safer, than passing pointers between the two worlds. And this change might push the balance a bit to this side.
- yjftsjthsd-h 3y agoCopying is safer but bad performance, so I'm not sure how that helps here?
- pron 3y agoYou don't need FFI -- you could reach for JDK internals if you conclude you must; all that requires is a flag. What we gain from this is that the vast majority of programs using Unsafe will gain safety with the new supported APIs and will not lose performance. Also, FFI to Rust will buy you nothing. Safe Rust performs the same bound checks as Java while unsafe Rust would be just as unsafe as using JDK internals. If you want to prove the safety of unsafe code in some other unsafe language, you might as well do the same for unsafe Java code using JDK internals (it would probably even be easier).