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

[Glavo]

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

Why does --add-opens have sufficient warning effect? Because this option
brings negative feedback.
It creates pain for authors of low-level libraries, authors of high-level
libraries that depend on low-level libraries, and end users, forcing them
to move away from --add-opens.
I agree with this approach, this kind of pain that cannot be borne by
anyone alone is indeed a means of forcing users to leave.

However, --enable-native-access is abusing negative feedback.
FFI is a legitimate requirement, and many applications cannot avoid using
them.
You try to inflict inescapable pain on everyone, and the result may be:


   1. Pushing People Out of the Java Ecosystem;
   2. Get people used to pain.

When people get used to the pain it causes, --add-opens can't give enough
negative feedback that it will do irreparable damage to integrity.

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/3d0219ac/attachment.htm>