Will we need to use the --enable-native-access option to enable JNI in the future?

[Pedro Lamarão]

Em seg., 20 de set. de 2021 às 10:45, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> escreveu:


> Now, I think both arguments can be turned on their heads; let's not
> think about existing code that wants to migrate from JNI to Panama -
> let's focus on _new_ code instead. If you write bindings for a C library
> post Java 17, it is much more likely that you will find that JEP 412 (+
> jextract) gives you all you want. Will you be put off by extra command
> line flags? I don't think so - if your application requires native
> libraries, you will likely need flags (e.g. java.library.path) anyway.
> Will you be put off by the fact that JNI doesn't share the same
> restriction? Well, no - since you opted into Panama from the beginning,
> so JNI is most likely in your rearview mirror.
>

Let me offset the balance by contributing my expectation, which fits the
above description.
Our shop does "security" in the sense of operating security modules, in
particular hardware security modules.
Currently, the value we obtain from Java's superior tooling is diminished
by the cost of maintaining JNI code.
The "other choice" would be to use a language that, albeit with inferior
tooling, offers improved "native interop".
This equation is going to change significantly, in our perception, when
Panama is complete.
The inconvenience of some command line option which must be put in some
runtime configuration file is negligible in our engineering equation.

-- 
Pedro Lamarão
https://www.prodist.com.br
Securing Critical Systems
Tel: +55 11 4380-6585

Antes de imprimir esta mensagem e seus anexos, certifique-se que seja
realmente necessário.
Proteger o meio ambiente é nosso dever.
Before printing this e-mail or attachments, be sure it is necessary.
It is in our hands to protect the environment.