Hacker News Reader

Comment by kaba0 | Hacker News Reader

Where it matters, you can just write that part in a low-level language and call out to that.

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.

FFI boundaries are inherently unsafe regardless of language.

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.

Copying is safer but bad performance, so I'm not sure how that helps here?

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).

This 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.

> 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?

Java today is used and works fine for many high performance applications.

Yes, 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.

Yes 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.

You 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.

In 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.

You forgot that the deployment also got more complicated.

Or 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.

Reply on news.ycombinator.com