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

[Samuel Audet]

We can still do auditing at test time and even after everything's been
deployed in the wild, for example, something like this:
https://developer.android.com/guide/topics/data/audit-access

That said, it is best to catch as many errors as possible as early as
possible, and if I understand correctly what you're saying now, this is
what this experiment is all about...

Samuel

On Fri, Sep 24, 2021, 18:46 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> 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
>
>
>
>
>