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

Glavo zjx001202 at gmail.com
Tue Aug 29 00:49:33 UTC 2023


After a few hours of arguing and thinking, I suddenly noticed a horrible
thing:
The --enable-native-access option is weakening the warning effect of
options that break integrity.

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.

Is it a good thing to see more and more behaviors as breaking integrity and
requiring users to add corresponding options?
I don't know. But there's no question that if normal applications can't
avoid using integrity-breaking options,
users won't continue to think those options are dangerous.

As you can see, I strongly disagree with the design of the
--enable-native-access option.
I think if it is released in Java 22, it will irreparably damage the
integrity of the Java platform.
I hope it can be revisited and not let it abuse people's vigilance about
breaking integrity.

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230829/482b9105/attachment.htm>


More information about the jdk-dev mailing list