Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Attila Kelemen]

>
> I can’t follow this logic. You use modules if you want a finer grained
> control over integrity, not coarser grained, because you want to know what
> each of them can do *individually* so you can gain better maintainability,
> better security, and maybe someday better performance.
>

The logic is simple: There are a lot of people who don't care if their app
uses native calls, and don't like this JEP. These people want the simplest
way to turn off the potential warning / error. The simplest way to turn it
off is to not modularize your application (because then you can turn it off
with a single parameter or even manifest entry). Therefore it just follows
that these people are motivated to not modularize their application. That
is, this JEP creates a perverse incentive.


> However, as I’ve said before, a way to inherit native access permissions
> is something we could consider if configuring native access for modules
> ends up being a problem in practice, something that the proposed warning
> will help us determine. How many libraries requiring native access an
> application uses is also a factor. Who knows? Maybe we would want to offer
> a way to allow native access to all modules. But we don’t design solutions
> to problems that may not exist. To know more, we’ve presented a JEP that
> emits a warning and offers a simple mechanism to disable it, which
> hopefully will let us learn what if any changes to that simple mechanism
> are required.
>

I'm worried that this might cause long lasting damage, because it instills
an extra irrational fear into people. Something that was done by
modularization of the JDK, where I believe the JDK did the minimal amount
of necessary pain (too bad the JDK didn't recognize that 3rd party
libraries would have the same need as they do not have the option to
strongly protect themselves). Now it is often a nightmare to convince
people to upgrade to new JDK versions, because people are just terrified.
This is quite silly of course, because the same people are a lot easier to
convince to upgrade other dependencies despite the fact that the JDK has a
far better track record in being backward compatible than almost all
libraries, and the issues caused by the modularization of JDK are
basically long gone. So, I'm just worried that you will feed into this fear
from which there will be no easy way out.


> How do the build tools enumerate all those transitive dependencies?
>

I'm not sure what you mean by this question. Every library records their
own direct dependency, and the build tool can just traverse this graph (the
edges are either defined in *.pom or *.module files).

However, this made me think a little, and there is an extra reason to
prioritize the "future work" section (the "we may explore ways" in the JEP
doesn't exactly show commitment to it). The extra incentive is that, if
libraries could (or even mandated) to formally declare their native usage,
then this information could be used by the build to pick different variants
of the same dependency (one using native calls, one pure Java). I don't
have much hope for Maven in this area, but Gradle already naturally
supports attribute based variant selection (see
https://docs.gradle.org/current/userguide/variant_model.html). Maybe you
should also discuss this possibility with Gradle folks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230902/20ce820c/attachment-0001.htm>