Be wary: --enable-native-access is breaking integrity

[Glavo]

The means to be able to break the abstraction of the dependency hierarchy
are unconventional.
I don't think all the reasons you have given so far are enough to justify
using this unconventional means.
I hope you will use these means more carefully, abuse of them will weaken
their warning effect.

Glavo

On Tue, Aug 29, 2023 at 5:15 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 29 Aug 2023, at 01:49, Glavo <zjx001202 at gmail.com> wrote:
> >
> > Integrity-breaking options such as --add-opens warn users that they are
> working in an unusual way.
> > This is a strong warning that users should use a safe alternative and
> should try not to use this option.
> >
> > But --enable-native-access is different.
> > In practice, FFI is very commonly used and cannot be abandoned for a
> foreseeable long time.
> > --enable-native-access will be the only way to enable FFI, which means
> that a lot of normal applications
> > will have to use integrity-breaking options for a long time.
> > This is a red flag, which means that users will be less vigilant about
> breaking integrity.
>
> Are you saying that Java developers are able to learn the difference
> between, say, VarHandle and Unsafe but not between --enable-native-access
> and --add-opens? Yes, there are some differences. Unsafe is in a
> suspiciously-named package and VarHandle is not while the two flags are
> just flags (and perhaps we should have named add-opens `unsafe.add-opens`
> but that ship has sailed). But I think that the main difference is that
> --enable-native-access is simply new, which means that Java developers will
> have to learn what it means, just as they do with any new feature.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230829/ccd11397/attachment.htm>