I can say that in my bubble we reach out for Java, because of Spring, AEM and Android.
That is it, other use cases, have other programming stacks.
As such our native libraries are written in consideration to be consumed at very least, across .NET (P/Invoke, C++/CLI, COM), Java (JNI), nodejs (C++ addons), Swift.
So to move the existing development workflow from JNI to Panama, it must be an easy sell why we should budget rewrites to start with.
Also in regards to "hate", if all decisions were that great there wouldn't be needed to create a new library support group to help Java ecosystem actually move forward and adopt new Java versions, as I learned from JFokus related content.
You shouldn't! We're not trying to "sell" any rewrite from JNI to FFM. Since FFM is both significantly easier to use and offers better performance, most people would choose to write new interop code with FFM; that is an easy sell. But that's not to say that these benefits justify a rewrite of existing code, and we have no plan to remove JNI. JNI and FFM can coexist in same program (and even in the same class). However, we are about to place the same protections on JNI as those we have on FFM to ensure that Java programs are free of undefined behaviour by default, and that modules that may introduce undefined behaviour are clearly acknowledged by the application so that the application owners may give them closer scrutiny if they wish [1].
To elaborate just a bit more on what I wrote in my previous comment, to get a straightforward interop with C you need to place certain restrictions on the runtime which limit your ability to implement certain abstractions such as moving GCs and user-mode threads. Because native interop requires special care anyway due to native memory management, which makes it significantly more complex than ordinary code and so less suitable for direct exposure to application developers -- so it's best done by experts in the area -- and on top of that native calls in Java aren't common, we decided not to sacrifice the runtime in favour of more direct interop. As a result, native interop is somewhat more elaborate to code, but as it requires some special expertise and so should be hidden away from application developers anyway, we decided it's better to place the extra burden on the experts doing the interop rather than trade off runtime capabilities and performance. We think this is the better tradeoff for Java. Consequently, we have both compacting collectors and no performance penalty for native calls on virtual threads. Other languages made whatever tradeoffs they thought were right for them, but they did very clearly sacrifice something.
That is it, other use cases, have other programming stacks.
As such our native libraries are written in consideration to be consumed at very least, across .NET (P/Invoke, C++/CLI, COM), Java (JNI), nodejs (C++ addons), Swift.
So to move the existing development workflow from JNI to Panama, it must be an easy sell why we should budget rewrites to start with.
Also in regards to "hate", if all decisions were that great there wouldn't be needed to create a new library support group to help Java ecosystem actually move forward and adopt new Java versions, as I learned from JFokus related content.