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

[Attila Kelemen]

>
>
> 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.
>

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.


>
> -cp is a flag (even with ‘lib/*’), and the same work done to automate the
> classpath could be applied to this flag as well.
>
>
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?


>
> 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).
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230901/6435f4f3/attachment.htm>