<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No, there’s some misunderstanding here. The “end user” from the perspective of the JDK is the application author/maintainer. It is not the end user of the Java *application*.<br></blockquote><div><br></div><div>Of course I know this, because you have said it many times.</div><div>When I said that I hope to declare relevant information in the module information of the main module, Alex replied like this:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>My question is why should we distinguish between the author of the main module and the packager of the program? <br></div><div>Is such an identity completely independent of developers really meaningful?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If the other methods were restricted but not JNI, those libraries will use JNI for that purpose.<br></blockquote><div><br></div><div>This reason would lead me to believe it if the same restrictions were not imposed on Panama.</div><div>I support more restrictions on JNI to move users to Panama, but I would like Panama to be available without JVM options.</div><div><br></div><div>I'm not saying there should be no restrictions at all. For features like this that is really needed by people, I wish it could be managed more finely.<br></div><div>This is what I want (3rd repetition):<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>1. Allows a module to declare that it wants native access:</div><div><br></div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">```java</div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>module org.glavo.mylib {</div><div>    requires native; // Check for permissions when loading</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>    // or</div><div>    requires static native;  // Check for permission when calling a restricted method</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>}</div><div><br></div><div>2. Allows a module with native access enabled to grant permissions to other modules:</div><div><br></div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">```java</div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>module org.glavo.myapp {</div><div>    requires native;<br></div><div>    requires org.glavo.mylib;</div></div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">    opens native to org.glavo.mylib;</div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">}</div></div></div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span class="gmail-im"><div><br></div><div>3. If the main module requires native access, it is allowed without the --enable-native-access.</div><div><br></div></span><div>4. Allows users to declare restricted methods. </div><div>    This will prevent code from masking its true intent through low-level libraries like JNA/JNR.</div></div></div></div></div></div></div></div></blockquote></blockquote><div><br></div><div>I think future I/O should be limited in a similar way, since users can use it to break integrity as well. </div><div>For example, using /proc/pid/mem can bypass the restriction and write directly to memory.</div><div><br></div><div>I know you have some descriptions in the "future work", but you are now preparing to modify the default behavior of the program.<br></div><div>Even just printing a warning is not harmless, it is urging the user to go somewhere.<br></div><div>So please don't let them be "future work", they should be "dependencies".<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">-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></blockquote><div><br></div><div>In theory, build tools could do this, but they haven't done so yet. It sounds like you want the Java community to do this? </div><div>Then I must remind you that if it is not the OpenJDK team but the Java community that does this, then the future development direction will not be in your control.<br></div><div>As I said in another email, this will cause irreparable damage to the integrity.<br></div><div><br></div><div>I like --add-opens the way it is now because it gives everyone enough negative feedback to keep people away from it.<br></div><div>But if the community does this, the vigilance effect of --add-opens will be greatly reduced, and more people may no longer think that breaking module encapsulation is a super power.<br></div><div>Therefore, I hope that FFI, I/O, these superpowers that people really need, should not be treated in the same way.<br></div><div><br></div><div>Glavo</div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 3, 2023 at 1:48 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 2 Sep 2023, at 14:51, Michał Kłeczek <<a href="mailto:michal@kleczek.org" target="_blank">michal@kleczek.org</a>> wrote:<br>
> <br>
> <br>
> 1. I was talking about social issues - seem to me they would be the same if you tried to enforce SecurityManager<br>
<br>
The social aspect is certainly one of the most interesting and challenging parts, and the main reason why we’re moving so cautiously.<br>
<br>
> 2. I am not convinced that it really works as well as advertised by OpenJDK team. For example: you ignored my question about dynamically loaded modules - how are they handled by these command line flags?<br>
<br>
That's in the JEP.<br>
<br>
— Ron<br>
<br>
<br>
<br>
<br>
</blockquote></div>