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

[David Lloyd]

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

> On 12/20/2024 12:48 PM, David Lloyd wrote:
> > A replacement library (or even an original library) might be
> > obligated to change one of *its* implementation dependencies (like a
> > utility library) due to security problems of this sort, and since it
> > is an implementation detail, it would not be natural to expect any
> > user to consider that the third library's having a different API/
> > package set could introduce some new hygiene problem. We've always
> > considered it to be a natural property of encapsulation for the
> > consumers of A to not have to worry about what's going on with C in
> > an A->B->C scenario (or its presence or absence).
>

When you say that M should "not have to worry about what's going on with

C", I think you mean that _even if C exports all its classes and even if
> M arranges to consume C_, some additional mechanism should provide
> _isolation_ for C, such that M's code cannot access C's code.
>
> Such isolation would open the door to replacing C by D -- a module with
> different bits, and different dependencies, but the same name and
> exports as C. D and all of its dependencies would be outside the worry
> range of M, just as C was.
>

It would also open the door to replacing C with E: a module with different
bits, dependencies, *and* name and exports, as a part of upgrading B to a
new version, without breaking A.

Not only that, but if M decides it needs C - or it needs something that
needs C - you are not necessarily locked into the problem that A and B must
agree on a version of C, if there is an isolation mechanism. Version
convergence can be a very challenging problem when dealing with hundreds or
thousands of modules. Shading with package relocation would be a
traditional workaround for this kind of problem, but it brings troubles of
its own.

Managing a set of available modules in a container to a user base is itself
a kind of API, in that you want to restrict its surface area (aka coupling
surface) as much as possible. The JDK can use accessibility for this
purpose without encountering these issues, because it comprises either code
that originates in OpenJDK, or third-party modules that have been
package-relocated. A container or other extensible run time environment
will often use third-party libraries internally which are not intended to
be a part of the surface area of available modules and should be isolated
from the user if possible.

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