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

Attila Kelemen attila.kelemen85 at gmail.com
Tue Aug 29 17:00:32 UTC 2023


>
>
> The main module is not the user. The user is the person who develops,
> maintains, or otherwise "owns" the application. The main module is part
> of the application. The point of the JEP is to let the user, outside the
> application, acknowledge the risk arising from use of JNI inside the
> application (whether in the main module or six levels down).
>
>
The main module is not simply a random part of the application. That it
is the entry point. It is not that different from its start script in this
regard. So, if you somehow don't consider the main module the user, then
you might as well not consider anything the user. That is, whoever is at
the top level will be made aware. And if that is not enough, then how come
the JVM arguments are enough when the script starting is some kind of top
level entity (an entry point as well like the main module, but simply in
another language) and thus a "user" by your standards?

If you are thinking of apps like a Spring boot app (I have to admit I
heavily biased since I hate SB from the bottom of my heart), then either SB
will not provide this in its main module (which would be the correct
decision), or if it just randomly does (which wouldn't be too surprising
since SB doesn't give a crap about horrible things happening without your
knowledge) then by using SB you opt-in to the "I don't care what my app
does" (which you do anyway with SB). And even if you are super worried
about this, there is a middle ground here: If the main module doesn't just
set a flag, but explicitly lists the modules with native requirements (like
in my original proposal). In this case, SB won't really have much chance,
because it can't know what you will use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230829/97a9e88d/attachment-0001.htm>


More information about the jdk-dev mailing list