<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">I think a lot of people were unpleasantly surprised to discover that the<br>implementation of low-level libraries was a huge factor in preventing<br>upgrades from JDK 8 to 17 -- and would like to see the balance shift<br>away from library developers being able to silently get superpowers, and<br>towards users having the final say over those superpowers.<br></blockquote><div><br></div><div>As I mentioned before, doing so costs most people.</div><div>Are you really sure what you're saying is what many people need?<br></div><div>At least among the people I've come into contact with, no one really needs it.<br></div><div>Most people just need the high level library/framework to make the decision for them.<br></div><div><br></div><div>You are making a very dangerous decision, which will affect users widely.<br></div><div>Breaking encapsulation doesn't help security, high-level libraries can always hide details </div><div>by copying low-level libraries into their own modules, and users can always review all libraries recursively if needed.</div><div>So the only reason to break encapsulation is that you want to interfere with the Java ecosystem, </div><div>so you force all users to pay for it.<br></div><div>I really can't agree with such a decision, I think you have to collect opinions more widely before making such a decision.</div><div><br></div><div>Glavo</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 Tue, Aug 29, 2023 at 4:28 AM 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">On 8/28/2023 12:51 PM, Glavo wrote:<br>
> A deep dive into every library isn't necessary for everyone.<br>
> If lib1 trusts lib2 it depends on, then most users who trust lib1 don't <br>
> need to investigate lib2.<br>
> We shouldn't make the majority of people pay for a very small number of <br>
> needs.<br>
<br>
 From this JEP about restricting the use of JNI, and from the JEP about <br>
restricting the dynamic attachment of agents, I think a lot of people <br>
have become aware of the "superpowers" which some libraries have <br>
silently enjoyed. Superpowers that allow private methods in the JDK to <br>
be redefined at any time. Superpowers that allow native code to be <br>
invoked and then call back into Java with zero access control.<br>
<br>
I think a lot of people were unpleasantly surprised to discover that the <br>
implementation of low-level libraries was a huge factor in preventing <br>
upgrades from JDK 8 to 17 -- and would like to see the balance shift <br>
away from library developers being able to silently get superpowers, and <br>
towards users having the final say over those superpowers.<br>
<br>
Alex<br>
</blockquote></div>