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

[Attila Kelemen]

>
> 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.
>
>
> I don't think this is the case. Instead I think there is a lot of
> potential for a much better story. Modules lend themselves to doing a lot
> more at build time and setting things up for simple/fast checks at startup
> (think post resolution checks).  It's not hard to think about fail fast if
> a module requires the "restricted methods or native code" capability that
> has not been granted. Combing a set of modules at link time also has a
> potentially interesting story when using jlink to create an application
> that has an initial/main module. In that case, you can think about checking
> capabilities (or whatever term is introduced) at build/link time.
>

 I'm a bit confused, because I don't think your response is related to the
quoted text, but I'll try my best.

I was referring to the fact that it is easier to opt-out for a
non-modularized app from this JEP (I mean to avoid warning now / error
later), than for a modularized app which creates a perverse incentive to
avoid creating modularized apps. As far as I understand Ron (what he wrote
in an email sent after your email), then the current position is that he
(and whoever else he represents) is not convinced that people who would
modularize their application mind the additional difficulty. Since I can't
exactly provide a proof to the contrary (just have my experience, which is
obviously inaccessible to you), I will leave it at that for now.

As for "fail fast": That would be great, but that is another of my issue
that - in its current state of the JEP - it is not possible, because that
would require the future work section, which I consider to be too important
to leave it for the undefined future (so important that I think without it
this JEP carries some danger with it). And the phrasing "we may explore
ways" in the JEP doesn't sound like a commitment either. This is because
without fail fast behaviour what is expected from users? The assumption of
the JEP that a user is unsure about the native usage within his/her app
(which for example is true for me, because I had my share of nasty
surprises because of it). However, this person now has to list all the
modules using native using modules. How is he/she supposed to do that? Run
the app, if it fails (for now prints warnings), then add the command line
option, and try again until the problem stops? But even after doing so, the
user can never be fully confident that the app will never have a surprise
native call based on some rare to trigger condition (and rare trigger did
happen to me in practice).

As for "link time" module choice: It is an interesting option which I
actually did not consider, so I have to think about its implications more.
But regardless, it does not affect the option of making opt-out from this
JEP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230904/8ad54a90/attachment-0001.htm>