<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2024 at 4:48 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">On 12/20/2024 12:48 PM, David Lloyd wrote:<br>
> A replacement library (or even an original library) might be<br>
> obligated to change one of *its* implementation dependencies (like a<br>
> utility library) due to security problems of this sort, and since it<br>
> is an implementation detail, it would not be natural to expect any<br>
> user to consider that the third library's having a different API/<br>
> package set could introduce some new hygiene problem. We've always<br>
> considered it to be a natural property of encapsulation for the<br>
> consumers of A to not have to worry about what's going on with C in<br>
> an A->B->C scenario (or its presence or absence).<br> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">When </span>you say that M should "not have to worry about what's going on with</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
C", I think you mean that _even if C exports all its classes and even if <br>
M arranges to consume C_, some additional mechanism should provide <br>
_isolation_ for C, such that M's code cannot access C's code.<br>
<br>
Such isolation would open the door to replacing C by D -- a module with <br>
different bits, and different dependencies, but the same name and <br>
exports as C. D and all of its dependencies would be outside the worry <br>
range of M, just as C was.<br></blockquote><div><br></div><div><span style="font-family:arial,helvetica,sans-serif">It would also open the door to replacing C with E: a module with different bits, dependencies, *and* name and exports, as a part of upgrading <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">B to a new version</span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">, without breaking A.</span></span><br class="gmail-Apple-interchange-newline"></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Not only that, but if M decides it needs C - or it needs something that needs C - you are not necessarily locked into the problem that A and B must agree on a version of C, if there is an isolation mechanism. Version convergence can be a very challenging problem when dealing with hundreds or thousands of modules. Shading with package relocation would be a traditional workaround for this kind of problem, but it brings troubles of its own.</div></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Managing a set of available modules in a container to a user base is itself a kind of API, in that you want to restrict its surface area (aka coupling surface) as much as possible. The JDK can use accessibility for this purpose without encountering these issues, because it comprises either code that originates in OpenJDK, or third-party modules that have been package-relocated. A container or other extensible run time environment will often use third-party libraries internally which are not intended to be a part of the surface area of available modules and should be isolated from the user if possible.</div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>