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

[Glavo]

You keep emphasizing "end user", trying to prove that you are giving more
power to the end user.
Is this real? It doesn't look like it. You are just forcing more
obligations on them.

Is --enable-native-access really giving the end user more control? Mostly
not.
In most cases, the actual control is always in the hands of the developer,
--enable-native-access just forces the end user to sign their name on the
agreement, even if they don't want to read it.
If they don't sign this agreement, the program will crash at random moments.
Does this forced-signed agreement have any practical significance other
than helping developers shirk their responsibilities?
If the end user really wants to audit all dependencies, this can be done
even without the --enable-native-access option.
Declaring these in module-info can also aid in review.

Can --enable-native-access make the behavior of the program more
transparent? I'm not sure, but I guess not.
Library authors can hide implementation details by simply bundling
dependencies into their own modules using tools like shadow jar.
This is a great idea and has no downsides other than having a hundred
duplicate dependencies in different packages in my program.
That's it, --enable-native-access has no advantage in making a program's
behavior transparent over exposing its behavior in module-info,
and may instead force library authors to hide implementation details in
other ways.

Can --enable-native-access prompt the end user that the program may break
integrity?
I think this is the only reason I can agree with.
But it's no better than the `-Dforeign.restricted=permit`, if for that
reason alone.

As stated above, I completely disagree with the reasons you gave. I think
it will cause more problems than it solves.

First, it will definitely cause a lot of program crashes due to not adding
JVM options correctly.
Some may be due to lack of familiarity with the library, some may be due to
forgetting,
and some may be due to the startup script not being updated correctly along
with the program.
In any case, we cannot avoid it. It may cause more damage in reality than
the breach of integrity it avoids.

I've spoken many times about the complexity that having to use JVM options
brings to small programs, so I won't repeat it here.
What I want to point out here is that there is currently no standardized
way to pass JVM options between dependencies in the Java ecosystem.
The current mainstream way is through documentation. However, if you do
decide to impose --enable-native-access restrictions on FFI,
then this will push the community to pass this information in the POM or
Gradle Module Metadata and have the JVM options automatically generated by
the build tool.
This may seem fine, but the community will care more about user convenience
and less about integrity and other things you care about.
If you let the community do it, they might allow libraries to declare that
they require --add-opens/--add-exports in a similar way.
Library authors will no longer be so careful to avoid breaking integrity,
which would cause irreparable damage to integrity.

I want to know if you collected enough user opinions before making such a
major decision?
Not only the opinions of senior programmers at individual top companies,
but also the opinions of programmers in small companies are also important.
I went to ask many Java programmers for their opinion on this decision.
Most of them feel that this is a stupid decision, and the rest feel that
this will be their reason to abandon Java.
Although this is just a local survey, I think it is representative to a
certain extent.
I hope you will think twice before you act.

Glavo

On Tue, Aug 29, 2023 at 11:57 PM Glavo <zjx001202 at gmail.com> wrote:

> 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/20230831/772349f8/attachment.htm>