The definition of `requires`

[David Lloyd]

On Fri, Dec 20, 2024 at 12:58 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> We understand that if `requires M;` ends up resolving the module M @ 1.0
> (because a build system happened to make M @ 1.0 observable), then the
> module graph could look different than if M @ 2.0 is resolved. M @ 2.0
> can of course express different dependences than M @ 1.0. Notice that in
> this paragraph, I have spoken in terms of modules, not in terms in JAR
> files or paths.
>
> Accordingly, it is legitimate to view the module name specified by
> `requires` as not indicative of a particular JAR file. That is, not
> indicative of an "actual artifact".


Great, that matches my understanding, thanks.

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.

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241220/8077e107/attachment.htm>