<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 Mon, Dec 23, 2024 at 11:50 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 12/23/2024 7:08 AM, David Lloyd wrote:<br>
> It would also open the door to replacing C with E: a module with <br>
> different bits, dependencies, *and* name and exports, as a part of <br>
> upgrading B to a new version, without breaking A.<br>
> <br>
> Not only that, but if M decides it needs C - or it needs something that <br>
> needs C - you are not necessarily locked into the problem that A and B <br>
> must agree on a version of C, if there is an isolation mechanism. <br>
<br>
Layers let you have multiple versions of C and B. One layer can have <br>
class loaders that load an A->B->C configuration, while another layer <br>
has class loaders that load an upgraded A->B'->E configuration.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Sure, but that's not really what I'm asking for (you'd then have two As in one system, which is pretty different from the original scenario). If I have A->B at build time, then it should be possible to use A in a run time system that has A->B->C or A->B->D or A->B->E without A having to know or care what B's dependencies are; furthermore, it should be possible for A to bring its own C or D or E without fearing conflicts with transitive dependencies of B (a big part of classical "JAR hell"). This is where the current system seems deficient. Layers can only take you so far, because of two constraining factors: the hierarchical nature of layers which does not seem to suit all (or most) of the ecosystem, and that a parent layer apparently cannot hide modules from a child layer.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This fulfills one of the requirements for the module system: <br>
<a href="https://openjdk.org/projects/jigsaw/spec/reqs/#isolated-dynamic-configurations" rel="noreferrer" target="_blank">https://openjdk.org/projects/jigsaw/spec/reqs/#isolated-dynamic-configurations</a><br>
<br>
A layer is an abstraction that combines class loaders and module <br>
declarations in order for the JVM to enforce accessibility and thereby <br>
provide encapsulation. See <br>
<a href="https://www.youtube.com/watch?v=QnMDsI2GbOc&t=1848s" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=QnMDsI2GbOc&t=1848s</a>.<br>
<br>
But if C and E don't want encapsulation, because they export all their <br>
public classes, then having C and E in different layers doesn't buy you <br>
anything beyond what you get with different class loaders. I understand <br>
the kind of isolation you're looking for, but we never claimed that <br>
layers would provide it.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Recognizing that the original design goals did not encompass this scenario, why not consider the enhancement? Are these requirements considered a closed book at this point?</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>