<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2024 at 12:58 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">We understand that if `requires M;` ends up resolving the module M @ 1.0 <br>
(because a build system happened to make M @ 1.0 observable), then the <br>
module graph could look different than if M @ 2.0 is resolved. M @ 2.0 <br>
can of course express different dependences than M @ 1.0. Notice that in <br>
this paragraph, I have spoken in terms of modules, not in terms in JAR <br>
files or paths.<br>
<br>
Accordingly, it is legitimate to view the module name specified by <br>
`requires` as not indicative of a particular JAR file. That is, not <br>
indicative of an "actual artifact".</blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Great, that matches my understanding, thanks.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>I believe that the implication here would be that in addition to ensuring compatibility at a class/package level, the authors of the replacement (run time) artifact would have to be exceedingly careful to not depend on any new or different modules (compared to the original), else a cycle could be introduced at run time that didn't exist at compile time. The `requires` of a module are therefore an implicit part of compatibility/substitutability even if consumers of that module are not directly aware of what they are. This can be challenging when the graph comprises modules from many third parties, which is very often the case, because every participant in the ecosystem has to agree to this rule to be 100% safe. Though I doubt 100% could be reached just because, to use your version example, introduction of new features may require other new third-party modules to realize them.</div></div></div><span class="gmail_signature_prefix"><div><span class="gmail_signature_prefix"><br></span></div>-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>