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

[David Lloyd]

On Mon, Dec 23, 2024 at 11:50 AM Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 12/23/2024 7:08 AM, David Lloyd wrote:
> > 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.
>
> Layers let you have multiple versions of C and B. One layer can have
> class loaders that load an A->B->C configuration, while another layer
> has class loaders that load an upgraded A->B'->E configuration.
>

Sure, but that's not really what I'm asking for (you'd then have two As in
one system, which is pretty different from the original scenario). If I
have A->B at build time, then it should be possible to use A in a run time
system that has A->B->C or A->B->D or A->B->E without A having to know or
care what B's dependencies are; furthermore, it should be possible for A to
bring its own C or D or E without fearing conflicts with transitive
dependencies of B (a big part of classical "JAR hell"). This is where the
current system seems deficient. Layers can only take you so far, because of
two constraining factors: the hierarchical nature of layers which does not
seem to suit all (or most) of the ecosystem, and that a parent layer
apparently cannot hide modules from a child layer.

This fulfills one of the requirements for the module system:
>
> https://openjdk.org/projects/jigsaw/spec/reqs/#isolated-dynamic-configurations
>
> A layer is an abstraction that combines class loaders and module
> declarations in order for the JVM to enforce accessibility and thereby
> provide encapsulation. See
> https://www.youtube.com/watch?v=QnMDsI2GbOc&t=1848s.
>
> But if C and E don't want encapsulation, because they export all their
> public classes, then having C and E in different layers doesn't buy you
> anything beyond what you get with different class loaders. I understand
> the kind of isolation you're looking for, but we never claimed that
> layers would provide it.
>

Recognizing that the original design goals did not encompass this scenario,
why not consider the enhancement? Are these requirements considered a
closed book at this point?

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