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

[Maurizio Cimadamore]

On 24/09/2021 04:53, Samuel Audet wrote:
> I think your main point is that the "application packager has no way 
> to be notified when _something_ changes in the dependencies of his/her 
> application", which sounds reasonable, but I don't see when that would 
> be a problem. Could you elaborate on this scenario? In my book, 
> "application packagers" are also programmers, so they already do 
> things like test applications in multiple environments anyway (with 
> and without sudo-like permissions), so I think that any changes in the 
> dependencies would easily show up at that stage. Do you have a 
> counterexample in mind? 

The counterexample I have in mind is auditing. If you distribute a 
binary in the wild, you probably want to be very careful not only about 
what yout application does, but also whether your code has dependencies 
on libraries which might do something strange. From the perspective of 
the distributor, any native access (whether direct, or indirect) counts: 
if a bad native access in a 5-th level dependency compromises the 
application, the application as a whole will be considered "at fault".

Nevertheless, your point is valid: the distinction between a developer 
deploying a test on X and an "application packager" is subtle, and I get 
that, in the former case, the restrictions imposed by the mechanism we 
have now can be perceived as overly strict.

No matter how you look at it, I think it's a hard thing to balance - as 
soon as you make some sort of escape hatch available via command-line 
and/or environment (for the developer use case), it is hard then not to 
lose all the benefits for the auditing-like use cases.

That said, the feedback in this thread will be taken into account, and 
we will consider minor tweaks to the existing mechanism which will 
provide for a smoother transition from JNI to Panama, as well as to 
reduce friction in the cases you mention.

Maurizio