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
