<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. <br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
How do the build tools enumerate all those transitive dependencies?<br>
</blockquote><div><br></div><div>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).</div><div><br></div><div>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 <a href="https://docs.gradle.org/current/userguide/variant_model.html">https://docs.gradle.org/current/userguide/variant_model.html</a>). Maybe you should also discuss this possibility with Gradle folks.</div><div> </div></div></div>