Feedback about an experiment to embed Python interpreter with FFI API

[Maurizio Cimadamore]

On 15/01/2022 14:31, Maxim Karpov wrote:
> I'm not saying that FFI API is bad or useless, but command line 
> argument is (both harmful and useless). 
You keep saying things like "harmful" and "useless" when in reality 
there were 2-3 examples in this mailing list (some in this thread, some 
outside, which I've already linked at), which clearly signal that not 
everybody perceives the flag as useless/harmful. So, at least let's not 
try to paint everything with the same color.
> The whole discussion is about it. Also not everyone uses Tomcat which 
> performs some kind of "inversion of control" pattern: the Tomcat 
> starts first and then it loads applications. There are tons of use 
> cases where application is deployed standalone (Netty, Akka, JavaFX, 
> you name it). For Tomcat or spring-boot inconvenience may be not so 
> big, exactly because of an IoC pattern: you have to insert command 
> line argument just once and also it may employ some dynamic way to 
> discover bundles/modules that need such argument. For other 
> application (and especially for libraries) the effect is devastating.

Is the flag "devastating" in a library because a user that packages that 
library inside an application will have to specify a flag to make that 
library work?

The flip side of this argument is: how "devastating" it is if a 
previously packaged application with dependency A and B keeps running 
w/o any kind of "warning" if either A or B starts depending on native stuff?

Yet another flip side, is that enforcing module boundaries is made 
weaker by the mere existence of JNI code, which can happily bypass all 
boundaries, of all kinds (write to static final fields, access methods 
to otherwise inaccessible classes and modules). Note that this has very 
little to do with "calling native libraries", in a way.

There are clearly users which think one kind of "devastating" is better 
than the other (or even that one of the two kinds cannot even be 
classified as "devastating").

My reading on the comments we have received so far is that bigger 
frameworks and/or modularization-friendly libraries tend to view the 
flag under more positive light (to the point that some of these clients 
would like to see more flags of this kind). Non-modularized libraries 
and/or applications (esp. those distributed via executable jars/jnlp) 
tend to view the flag as something impractical, which does notihng for 
them. Clearly a balance will have to be struck somewhere.

I remain convinced that the best way forward is to give developers more 
options, at least initially. For clients who want the strict behavior, 
use the flag as today, and get errors when something access unsafe 
methods w/o permissions. For clients which are ok with a looser 
behavior, allow them to drop the flag, and issue runtime warnings 
instead, whenever a module accesses an unsafe method. At the same time, 
while we're in this transitional period, we can make improvements on how 
permissions are managed transitively, so as to reduce the number of 
modules which have to be granted access from the outset.

But I also believe that if our platform wants to have a coherent story 
for enforcing module-based safety (and we have recently made changes to 
make some of these checks stricter, see JEP 403[1]) we cannot continue 
to ignore the fact that JNI (and native code) allow you to keep 
bypassing any such checks.

[1] - http://openjdk.java.net/jeps/403