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.
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.
Alex
