<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"><br>
We’re not trying to sell or not sell anything. Different features may have different tradeoffs, and anyone is free to consider them and choose whether to use a feature or not. Every single Java program running on a version of the JDK after 8 is making extensive use of modules already — in fact, the entire JDK is built around them — so it’s pretty hard to kill. It’s started doing its job of protecting the integrity of the JDK. In fact, the value that modules’ integrity functionality has already delivered to the ecosystem so far has been enormous, but due to its “deep infrastructure” nature, not everyone realises that, and that’s perfectly fine. The work on integrity, however, is not complete but here we are working on it in our usual careful and gradual manner. <br>
</blockquote><div><br></div><div>When I wrote "stop using the module system" I'm obviously talking about the application itself being modular. I would have expected that you also believe that it would be better, if applications were modular. Given that I assumed from what you wrote that you regret the fact that modules were not added on day 1 (in which case there would only be modular apps most likely). Yet, this JEP just motivates people away from modules.</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"><br>
-cp is a flag (even with ‘lib/*’), and the same work done to automate the classpath could be applied to this flag as well.<br>
<br></blockquote><div><br></div><div>Definitely not. Because while you can write `-cp 'lib/*'`, you can't just write `--enable-native-access='*'` which makes them worlds apart from each other. Also, I'm not sure how you would automate the application of `--enable-native-access` arguments? Because the classpath you can easily do so, since build tools offer you a simple way to enumerate your dependencies, but what way do I have to enumerate the module names requiring native access during the build automatically?</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">
<br>
What we’re proposing to deliver first is a warning (BTW, the classpath currently, as it has ever, *does* cause a crash at runtime if the library configuration is incorrect). <br>
<br></blockquote><div><br></div><div>The classpath being wrong is not very realistic (unless you are doing something horribly wrong), because the classpath doesn't need complete manual maintenance. That is, you care about your direct dependencies, and transitive will be collected automatically. Of course, libraries might not be backward compatible which has the potential to make version conflict resolution non-trivial, but then it is not that the classpath is wrong, but that some library you are using (directly or not) is not well behaved, which is an entirely different kind of problem.</div><div><br></div></div></div>