Hacker News Reader

Comment by bitcharmer | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com