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

[Ron Pressler]

> 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