<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>
The main module is not the user. The user is the person who develops, <br>
maintains, or otherwise "owns" the application. The main module is part <br>
of the application. The point of the JEP is to let the user, outside the <br>
application, acknowledge the risk arising from use of JNI inside the <br>
application (whether in the main module or six levels down).<br>
<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div></div></div>