FFM (Foreign Function and Memory API) Goes Final

Some years ago, I wrote a custom JNI wrapper over libuv [0] for a Java&#x2F;Kotlin project I was working on. It’s mind-blowing how much work it took to get cross-compilation and everything else working. That said, as someone who’s been writing C code for years, it wasn’t the worst experience I’ve had; it was mostly just tedious.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;1791-labs&#x2F;carlie">https:&#x2F;&#x2F;github.com&#x2F;1791-labs&#x2F;carlie</a>

For those of you, like me, who stumbled around looking for a link to something actually <i>definitive</i>:<p>JEP 454: Foreign Function &amp; Memory API <a href="https:&#x2F;&#x2F;openjdk.org&#x2F;jeps&#x2F;454" rel="nofollow noreferrer">https:&#x2F;&#x2F;openjdk.org&#x2F;jeps&#x2F;454</a>

I’m looking forward to be able to memory-map an entire large file without having to split it up into 2gb segments, and to be able to reliably unmap it when done. So many hacks to work around this lack of functionality today…

I&#x27;m not a Java dev, so forgive me if I misunderstand it, but is this basically just a different API for calling C functions? Java already was able to do so was it not? How does this improve on it?

Well this might be a fun one to search for when you need to learn the new API at work...

I have misgivings about making interop with native code easier.<p>In the node, python, and ruby ecosystems, native code dependencies are a horrorshow of brittle builds. The amount of my life that has been wasted on stupid build issues is significant (damn you nokogiri).<p>The JVM has been a relative sea of tranquility. The ecosystem is so large, and JNI so unpleasant, that everything important has been built JVM-native. Builds just work, even when you walk away for two years.<p>I don&#x27;t want native code in my projects, and I fear this will encourage it.