News for hackers. Stuff that matters.
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by yjftsjthsd-h on Wednesday January 17, 2024 @01:48AM (#39024123)
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.

Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by kaba0 on Wednesday January 17, 2024 @03:50AM (#39025084)
But 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.
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by yjftsjthsd-h on Wednesday January 17, 2024 @03:51PM (#39033273)
Copying is safer but bad performance, so I'm not sure how that helps here?
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by eptcyka on Wednesday January 17, 2024 @02:47AM (#39024591)
FFI boundaries are inherently unsafe regardless of language.
Re:JEP Draft: Deprecate memory-access methods in sun.misc.un... by pron on Wednesday January 17, 2024 @05:33AM (#39025953)
You 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).