[External] : Re: The definition of `requires`

[Alex Buckley]

On 12/20/2024 11:18 AM, David Lloyd wrote:
> 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.

(I will continue to speak in terms of modules, because there's really no 
need to speak in terms of artifacts.)

There are certainly rules of substitutability that apply to the 
declaration of "replacement" modules (e.g., M @ 2.0 replacing M @ 1.0). 
One rule is not adding `requires` clauses, as you noted, since it could 
create a cycle in the overall graph. A more interesting rule, I think, 
is not adding `requires transitive` clauses, because they could cause a 
consumer module to experience a split package. And of course, not 
removing any `requires transitive` clauses, since they're the way that 
consumer modules gain access to Java APIs.

In the case of "replacement" modules for de jure standards like the 
{Java, Jakarta} EE Platform (c.f. javax.servlet-api), I would expect the 
social mores of the standards body to prevent an implementer from 
unhygienic behavior such as adding `requires transitive 
com.megacorp.proprietary.api;` to a replacement module.

In the case of "replacement" modules for de facto standards -- "log4j 
1.x ... is a widely used library but with known security problems, so a 
replacement (e.g. reload4j) is provided instead" -- I would expect basic 
competence and conservatism from the developers of the "replacement" 
modules. If you're creating a "replacement" module for log4j, then the 
onus is on you to not cause problems when your module is resolved as 
part of a larger graph on the user's machine. The rules of hygiene for 
Java modules are just an extension of the well known binary 
compatibility rules for Java classes, methods, etc.

Alex

> 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