<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">Why? Is it important for users to include actual native access in `org.glavo.mylib` or `org.glavo.mylib.linux`?</div><div dir="ltr">In order to facilitate debugging? But wouldn't it be better to describe these details in module info?</div><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><div dir="ltr">As the application developer, I'm the programmer at the end, please allow me </div><div dir="ltr">to enable native access for other modules via module info. End users are </div><div dir="ltr">probably not programmers, so why let them know these details?</div><div dir="ltr">I think the developer of the main module has the right to decide.<br></div><div dir="ltr"><br></div><div dir="ltr">As the library developer, please allow me to enable native access for other </div><div dir="ltr">modules via module info. Why do I have to expose my implementation details to </div><div dir="ltr">all users through other channels? </div><div dir="ltr">You've forced some implementation details to be public behavior that needs to ensure compatibility,</div><div dir="ltr">but why? Security and transparency are just excuses to lie to yourself.</div><div dir="ltr">Under such coercion, I only want to copy all the libraries I rely on into my own modules,</div><div dir="ltr">so that they become implementation details again. Does your coercion make any sense?</div><div dir="ltr">I don't see any point in it, I think its only function is to force developers away.</div><div dir="ltr"><br></div></div><div dir="ltr"><div dir="ltr">I am very opposed to such a design that breaks the package. Therefore, I am </div><div dir="ltr">against promoting such a semi-finished product to mature functions.</div></div></div><div dir="ltr"><br></div><div>Glavo</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 Thu, Aug 24, 2023 at 11:05 PM Alex Buckley <<a href="mailto:alex.buckley@oracle.com">alex.buckley@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">The entire point is to make the end user aware of the need for native <br>
access by something (probably six dependency levels deep) in their <br>
application.<br>
<br>
The majority of applications do not need native access, but where native <br>
access is needed, it is fundamentally uncheckable and unsafe (as <br>
described in the JEP), hence the desire to have the user acknowledge it. <br>
Yes, we are asking the user to acknowledge an implementation detail of a <br>
library they've never heard of. This keeps the community's attention <br>
focused on the small number of libraries which, unlike those which use <br>
only standard supported Java APIs, are likely to be the cause of <br>
breakage on newer JDK releases.<br>
<br>
Alex<br>
<br>
On 8/24/2023 7:50 AM, Glavo wrote:<br>
> We need a way for modules that are enabled native access to pass this <br>
> permission,<br>
> otherwise this will force the library to have to expose the <br>
> implementation details to the user.<br>
> <br>
> Just for now, I think the --enable-native-access option is really weird.<br>
> It works with JPMS, but we can't describe it through module info.<br>
> I wish I could describe these things in module info instead of command <br>
> line arguments,<br>
> --enable-native-access should just be an escape hatch like <br>
> --add-exports/--add-opens.<br>
> <br>
> Glavo<br>
> <br>
> <br>
> <br>
> On Thu, Aug 24, 2023 at 10:03 PM Maurizio Cimadamore <br>
> <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a> <mailto:<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>>> <br>
> wrote:<br>
> <br>
> <br>
> On 24/08/2023 14:47, Volker Simonis wrote:<br>
> > I think the changes we are talking about here are much to fundamental<br>
> > for the Java platform to hide them in the API documentation of a<br>
> > package.<br>
> <br>
> I think I've already explained how the plan is to move restricted<br>
> methods out of the FFM package javadoc.<br>
> <br>
> As to the modifier idea - I think whatever arguments you make for<br>
> restricted methods also holds for preview API methods. We have been<br>
> previewing APIs for a number of years, and we have developed several<br>
> concepts that we can reuse here. In what way are restricted methods<br>
> more<br>
> attention-deserving than preview API methods?<br>
> <br>
> (And, no, I don't think we should add _two_ modifiers :-) )<br>
> <br>
> Maurizio<br>
> <br>
</blockquote></div>