
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><blockquote type="cite"><div>On Oct 9, 2023, at 8:51 AM, Maurizio Cimadamore <maurizio.cimadamore@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">In the current world, there is _no way_ for applications (e.g. pure Java ones) to guarantee that memory safety is not going to be compromised by any of their 3rd, 4th or 5th party dependencies. We would like to change that.<span class="Apple-converted-space"> </span></span></div></blockquote></div><br><div>But the proposed solution means there is no way for applications to guarantee that they won’t crash at runtime because</div><div>some nth level dependency tries to load native code.</div><div><br></div><div>The concern is that there appears to be a strong temptation to make this transitory solution permanent without solving the issue of</div><div>"<font color="#000000"><span style="caret-color: rgb(0, 0, 0);">the lack of a mechanism to propagate the native access permissions from a module to its dependencies”.</span></font></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0);"><br></span></font></div></body></html>