5 ms·
Where it matters, you can just write that part in a low-level language and call out to that.
by kaba0 3y ago
Where it matters, you can just write that part in a low-level language and call out to that.
- yjftsjthsd-h 3y agoThus 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).
- pjmlp 3y agoOr use C#, Go, Rust instead, which is sadly a loss for Java. We are no longer in the Sun days, with Java being the answer for everything.
- bitcharmer 3y agoThis is incorrect. Native calls whether it's via JNI (even with CriticalJNINatives) or Panama still have a transition cost formerly referred to as gc locker. I'm in a field where performance is number one requirement. Removing unsafe is a terrible idea.
- _w1tm 3y ago> I'm in a field where performance is number one requirement. Removing unsafe is a terrible idea. Are you sure you should be using Java if your use-case is performance sensitive?
- iscoelho 3y agoJava today is used and works fine for many high performance applications.
- bitcharmer 3y agoYes, I have no doubt about it. You might be stuck in 1990s perception of Java like a good portion of HN commenters who haven't had any real experience with it in the last 10-20 years.
- kaba0 3y agoYes they have, but you can always just go a “scope” higher, and instead of doing a loop that calls out to FFI, you call out to a loop itself.
- bitcharmer 3y agoYou mean expedite whole chunks of logic to a different language, then make your build process much more complicated by having to maintain a completely new ecosystem and compiler infrastructure and make testing more cumbersome? Sorry, but this is just a bad advice.
- kaba0 3y agoIn the very very rare case you might need it, than I guess, yeah. But if it turns out to be a real problem, it might still be possible that they will add a way to disable checks with the foreign memory API. It would actually allow for a better user experience, you could do “debug” builds with extensive checking for correctness, which could be disabled via some flag.